Come fare il backup del database della tua app (e ripristinarlo davvero)

Per fare il backup del database della tua app, esporta il database in un file secondo una pianificazione (per Postgres lo strumento standard è pg_dump), conserva le copie in un posto separato dal database e ripristinane periodicamente una in un database vuoto per verificare che funzioni. Fai un backup extra subito prima di ogni modifica rischiosa. Il backup del codice, che sia un repository GitHub o un export, non include i tuoi dati.

Questa guida è pensata per chi gestisce una piccola app e vuole smettere di preoccuparsi di perderla. Usa Postgres negli esempi, perché la maggior parte delle app create con l'AI usa questo database, ma i principi valgono per qualsiasi database.

Cosa deve coprire un backup

Un'app è più del suo database. Sappi quale parte protegge ciascun backup.

I dati sono la parte che non puoi ricreare. Il codice si può riscrivere e le impostazioni si possono reinserire; gli ordini dei tuoi clienti no.

Passo 1: decidi quanto puoi perdere

Due domande definiscono il tuo piano di backup:

• Quanti dati recenti puoi permetterti di perdere? Se fai un backup al giorno e il database si guasta di sera, perdi le modifiche di quella giornata. Per un'app hobby va bene. Per un'app che riceve ordini potrebbe non bastare.
• Per quanto tempo l'app può restare non disponibile durante il ripristino? Un database piccolo si ripristina in pochi minuti. Uno grande può richiedere molto di più, e conviene saperlo prima di averne bisogno.

Per la maggior parte delle piccole app un backup automatico giornaliero più uno manuale prima delle modifiche rischiose è un buon punto di partenza. Le app che trattano denaro o dati sanitari meritano backup più frequenti, oppure un database gestito con point-in-time recovery (la possibilità di ripristinare a qualsiasi momento, non solo all'ultimo backup).

Passo 2: verifica cosa fa già il tuo host

Molti fornitori di database gestiti eseguono backup automatici. Scopri:

• I backup sono attivi per il tuo piano, e con che frequenza vengono eseguiti?
• Per quanto tempo vengono conservati?
• Puoi ripristinare a un preciso istante, o solo a uno snapshot giornaliero?
• Puoi scaricare un backup, o solo ripristinarlo dentro il loro sistema?

I backup del fornitore sono utili, ma condividono con il database un punto di guasto unico: l'account. Se l'account viene chiuso, sospeso o il progetto eliminato, i backup possono andare persi insieme a tutto il resto. Per questo ti serve anche una copia tua.

Passo 3: crea un dump con pg_dump

pg_dump esporta un database Postgres in un file. Legge uno snapshot coerente, quindi l'app può continuare a funzionare mentre lui lavora.

Un comando tipico, che usa la stringa di connessione che la tua app ha già in una variabile d'ambiente:

pg_dump "$DATABASE_URL" --format=custom --no-owner --file=backup-2026-09-29.dump

Cosa fanno le opzioni:

• --format=custom scrive un file compresso che pg_restore può leggere, e ti permette di ripristinare in seguito una singola tabella. Usa --format=plain se preferisci un file .sql leggibile.
• --no-owner omette i comandi di proprietà, il che semplifica il ripristino in un database diverso.
• La data nel nome del file tiene separati i backup.

La versione di pg_dump deve essere uguale o più recente della versione di Postgres del database. Una versione più vecchia potrebbe rifiutarsi di funzionare.

Se costruisci con l'AI e non vuoi usare la riga di comando, puoi chiedere:

Crea un backup del database dell'app con pg_dump in formato custom, con la data di oggi nel nome del file. Non stampare la stringa di connessione né alcun segreto. Quando è pronto, dimmi il nome del file e la sua dimensione.

Passo 4: automatizza

I backup manuali vengono dimenticati. Automatizzali con ciò che la tua configurazione supporta:

• I backup pianificati del fornitore di database, se ne offre.
• Un job pianificato su un server o un servizio CI che esegue pg_dump e carica il file in uno storage.
• Un servizio di backup gestito che si collega al tuo database.

Qualunque scelta tu faccia, fai in modo che ti avvisi quando un backup fallisce. Un job che fallisce in silenzio per tre mesi è il classico incubo.

Passo 5: conserva copie altrove

La regola pratica è spesso chiamata 3-2-1: tre copie dei dati, su due tipi di storage diversi, con una copia fuori sede. Per una piccola app una versione pratica è:

• Il database attivo
• I backup automatici del fornitore
• I tuoi dump in uno storage separato, come un bucket di object storage in un altro account

Inoltre:

• Limita l'accesso. Un backup contiene i dati di ogni utente. Trattalo come il database attivo.
• Definisci una politica di conservazione. Ad esempio backup giornalieri per due settimane e mensili per un anno. Elimina i vecchi backup in modo deliberato, e ricorda che le leggi sulla privacy possono obbligarti a cancellare i dati personali su richiesta.
• Non committare mai i backup su Git. Un dump in un repository è una fuga di dati che aspetta solo di accadere.

Passo 6: verifica un ripristino

Un backup vale quanto il tuo ultimo ripristino riuscito. Almeno ogni pochi mesi, e dopo ogni modifica al processo di backup:

1. Crea un database nuovo e vuoto. Non ripristinare mai sopra quello attivo per fare la prova.
2. Ripristina l'ultimo backup al suo interno:

pg_restore --no-owner --dbname="$TEST_DATABASE_URL" backup-2026-09-29.dump

Per un file .sql semplice, usa invece psql "$TEST_DATABASE_URL" -f backup.sql.

1. Controlla che ogni tabella esista, confronta il numero di righe con il database attivo e guarda alcuni record recenti.
2. Avvia una copia dell'app puntata su quel database e prova ad accedere, se puoi.
3. Annota quanto tempo ha richiesto il ripristino. Quello è il tuo vero tempo di recupero.

Passo 7: fai un backup prima delle modifiche rischiose

Fai un backup fresco subito prima di:

• Eseguire una migrazione che elimina o rinomina colonne
• Importare dati in blocco
• Lasciare che un agente AI apporti grandi modifiche al modello dei dati
• Eliminare vecchi record

In un'app creata con l'AI, l'agente può cambiare la struttura delle tabelle come parte di una funzionalità. I checkpoint e il controllo di versione ripristinano il codice, ma non recuperano le righe eliminate. Un backup di trenta secondi prima di una modifica importante costa poco e ti protegge molto.

Errori comuni

• Pensare che Git o un export del codice siano un backup. Contengono il codice, non i dati.
• Non testare mai un ripristino. Molti backup si rivelano vuoti, parziali o illeggibili proprio quando servono.
• Conservare i backup nello stesso account del database. Un solo account compromesso o chiuso fa perdere entrambi.
• Dimenticare i file caricati. Il database memorizza il percorso del file; l'immagine vera sta nello storage.
• Lasciare segreti negli script di backup. Leggi la stringa di connessione da una variabile d'ambiente, mai dal testo dello script. Vedi come proteggere le chiavi API.

Backup e Mythex

I progetti Mythex possono avere un database Postgres dedicato, e i suoi dettagli di connessione vengono inseriti nello spazio di lavoro e nell'app pubblicata. La documentazione di Mythex non descrive una funzione di backup o ripristino del database, quindi pianificalo tu: chiedi all'agente di creare un dump, scaricalo e conservalo in un posto sicuro, soprattutto prima di grandi modifiche. Un export del progetto (Pro) contiene il codice, con segreti e node_modules esclusi; non contiene le righe del database. Vedi Database e Proprietà dei dati nella documentazione. Per saperne di più sul database stesso, leggi cos'è Postgres.

Checklist per il backup

• Deciso quanti dati puoi permetterti di perdere e per quanto tempo puoi restare fermo
• Verificato quali backup automatici offre il tuo host del database
• Il tuo dump gira su pianificazione e i fallimenti ti avvisano
• Copie conservate separatamente dal database, con accesso limitato
• Politica di conservazione scritta
• File caricati inclusi nei backup oltre al database
• Ripristino testato in un database vuoto, con numero di righe verificato
• Backup fatto prima di ogni modifica rischiosa

Domande