Tre modi per fare il backup di un database Supabase, e cosa manca

Chi costruisce su Supabase prima o poi si fa la stessa domanda, di solito circa una settimana dopo il lancio e quasi sempre alle due di notte: se rompo qualcosa, riesco a riavere i miei dati?

La risposta dipende interamente da quale delle tre strade hai preso, e a ciascuna sfugge qualcosa che le altre due coprono.

Quale dovrei usare?

Attiva quello che ti dà il tuo piano Supabase, poi tieni una copia da un'altra parte. Sono due lavori diversi, e fare solo il primo è esattamente l'errore che questo articolo esiste per evitare.

Il backup del pannello ti protegge dai tuoi stessi errori. Una copia che tieni tu ti protegge dal perdere l'account: un pagamento fallito, un progetto sospeso, una password che non riesci a recuperare. Sono disastri diversi e chiedono risposte diverse.

Cosa contiene davvero un backup

Le tue tabelle, le tue righe, i tuoi indici e le tue funzioni, e le tue regole di Row Level Security, cioè le policy che decidono chi può leggere cosa, non solo le tabelle a cui si applicano. Tutto qui.

Quello che non contiene è tutto ciò che nel database non è mai stato:

Quella su cui la gente inciampa è Storage. Ogni avatar, ogni PDF caricato, ogni immagine aggiunta dai tuoi utenti vive nell'archiviazione a oggetti, non nel database: il database tiene solo il percorso di ogni file. Ripristina un backup del database in un progetto vuoto e ti ritrovi una tabella piena di link a file che non ci sono.

Strada 1: il pannello di Supabase

La più facile, e quella che quasi tutti dovrebbero attivare per prima. Supabase fa backup giornalieri sui piani a pagamento, e il ripristino a un momento preciso è disponibile come extra se ti serve tornare a un minuto esatto invece che alla mezzanotte scorsa.

In cosa è brava: va avanti senza di te, è completa, e ripristinare sono pochi clic in un'interfaccia invece di un comando da azzeccare sotto pressione.

Cosa le sfugge: la copia vive dentro l'account. Se il progetto viene sospeso, se la carta registrata non passa o se perdi l'accesso al login, i backup stanno dietro la stessa porta della cosa che proteggevano. È un'uscita di sicurezza dentro l'edificio.

Inoltre sul piano gratuito non c'è affatto, ed è lì che si trova la maggior parte delle app appena lanciate.

Il piano su cui sei decide se questa cosa ce l'hai o no, e verificarlo richiede due minuti.

Strada 2: pg_dump sulla tua macchina

Supabase è Postgres, quindi lo strumento standard di Postgres funziona. pg_dump scrive tutto il database in un file che tieni tu.

pg_dump "postgresql://…la tua stringa di connessione…" \
  --clean --if-exists --no-owner \
  --file backup-2026-08-09.sql

In cosa è brava: è gratis, è completa, il file è tuo, e puoi ripristinarlo in un progetto nuovo di zecca su un altro account. Delle tre strade è l'unica che sopravvive alla perdita di tutto il resto.

Cosa le sfugge: succede solo quando te ne ricordi. Non è un dettaglio tecnico, è tutto il difetto. Il dump sul tuo portatile porta la data dell'ultima volta che ci hai pensato, e il giorno in cui ti serve non è mai un giorno in cui ci stavi pensando.

C'è un secondo problema, più silenzioso: un dump non provato è una supposizione. Un file scritto mentre una migrazione era applicata a metà, o troncato in silenzio perché è caduta la connessione, sembra identico a uno buono fino al giorno in cui provi a usarlo.

Strada 3: backup gestiti

Qualcos'altro prende la copia secondo un calendario, la mette via fuori dal tuo account e controlla che la copia sia vera prima di considerarla fatta. Quest'ultima parte è quella che conta davvero.

È quello che fa Reeve Care: diverse copie al giorno a seconda del piano, cifrate e conservate fuori dal tuo account Supabase, ognuna verificata contando quello che è uscito rispetto a quello che è entrato. Un backup conta come fatto solo una volta verificato, ed è per questo che la data mostrata nel pannello è quella dell'ultima copia verificata e non dell'ultimo tentativo.

Il compromesso onesto: costa, ed è un servizio in più nel tuo stack. Se sei abbastanza disciplinato da tenere la strada 2 con un calendario vero e provare i ripristini, non ti serve.

L'intero ciclo è illustrato nella pagina dei backup Supabase: la copia che esce da Supabase, la verifica che segue e il pulsante che la rimette a posto.

Hai mai fatto un ripristino?

Questa domanda decide se hai un backup o un file che nessuno ha mai aperto. Un dump che nessuno ha riletto è una supposizione sul futuro, e il momento in cui scopri che era sbagliata è il momento in cui ti serviva che fosse giusta.

Una prova di ripristino non deve essere drammatica. Crea un nuovo progetto Supabase, caricaci dentro il tuo backup più recente, apri l'app puntata a quel progetto e controlla che ci sia una riga che riconosci. Mezz'ora, una volta a trimestre. Se il ripristino fallisce, lo hai scoperto un martedì pomeriggio invece che nel mezzo di un disservizio.

Se vuoi l'elenco più ampio delle cose da controllare su un'app appena lanciata, la checklist di sicurezza in 10 minuti copre i backup insieme al resto, e la guida alla sicurezza di Supabase ripassa cos'altro resta comunemente aperto.

Cosa fare questa settimana

Da leggere dopo: se davi per scontato che l'annulla del tuo builder coprisse anche i dati, la cronologia delle versioni non è un backup è il primo da leggere. Poi: il tuo database è privato quanto le chiavi che gli stanno davanti, e quali chiavi API sono sicure nel frontend parla di quella che aggira ogni regola che imposti.