Fare il backup di un database non è come fare il backup di una cartella di documenti. Un database in funzione modifica di continuo i suoi file, tiene parte dei dati in memoria e scrive in più punti contemporaneamente. Copiare quei file con un normale programma di sincronizzazione mentre il server lavora produce spesso una copia incoerente, che al momento del bisogno non si avvia o contiene dati corrotti. Servono strumenti e metodi specifici.
Due famiglie di backup
Il dump logico
Un dump logico esporta il contenuto del database come istruzioni SQL o in un formato proprio dello strumento: la creazione delle tabelle, poi i dati, poi indici e vincoli. Gli strumenti più noti sono pg_dump per PostgreSQL e mysqldump per MySQL e MariaDB.
pg_dump --format=custom --file=gestionale_2025-03-10.dump gestionale
Questi strumenti leggono i dati in modo coerente: anche se il database continua a ricevere modifiche, il dump rappresenta lo stato in un unico istante. Per MySQL con tabelle InnoDB l'opzione --single-transaction serve proprio a ottenere questa coerenza senza bloccare le scritture.
Vantaggi del dump logico:
- è portabile tra versioni diverse del database e tra sistemi operativi;
- si può ripristinare anche solo una tabella;
- è leggibile e verificabile.
Svantaggi: su database grandi richiede molto tempo sia per crearlo sia, soprattutto, per ripristinarlo, perché gli indici vanno ricostruiti da zero.
Il backup fisico
Un backup fisico copia i file del database così come sono sul disco, usando strumenti che sanno gestire la coerenza: per PostgreSQL pg_basebackup, per MySQL soluzioni come Percona XtraBackup o MySQL Enterprise Backup, oppure le istantanee dei volumi coordinate con il database.
Vantaggi: è molto più veloce da ripristinare su grandi volumi e permette il ripristino a un istante preciso. Svantaggi: è legato alla versione del database e all'architettura, e di solito si ripristina tutto o niente.
Il ripristino a un istante preciso
Un backup notturno protegge fino alla notte precedente. Se alle 16 qualcuno cancella per errore una tabella, con il solo dump si perdono tutte le modifiche dalla mezzanotte in poi.
I database registrano ogni modifica in un registro sequenziale: in PostgreSQL è il write-ahead log (WAL), in MySQL il binary log. Archiviando questi registri in modo continuo accanto a un backup fisico di base, si può ricostruire il database in qualsiasi momento: si ripristina il backup di base e si riapplicano le modifiche registrate fino, per esempio, alle 15:59, un minuto prima dell'errore. Si chiama point-in-time recovery.
| Esigenza | Soluzione adatta |
|---|---|
| Database piccolo, perdita di un giorno accettabile | Dump logico giornaliero |
| Ripristino rapido di un database grande | Backup fisico |
| Perdita massima di pochi minuti | Backup fisico più archiviazione continua dei registri |
| Recuperare una singola tabella | Dump logico, anche come complemento |
Due numeri da decidere prima
Prima di scegliere gli strumenti conviene fissare due obiettivi, con chi usa i dati:
- RPO (Recovery Point Objective): quanti dati si è disposti a perdere, misurati in tempo. Un'ora? Un giorno?
- RTO (Recovery Time Objective): quanto tempo può restare fermo il servizio durante il ripristino.
Un RPO di 24 ore si ottiene con un dump notturno. Un RPO di cinque minuti richiede l'archiviazione continua dei registri. Un RTO breve su un database grande esclude il solo dump logico.
Una replica non è un backup
Molti sistemi hanno un server di replica che riceve in tempo reale ogni modifica dal principale. È ottimo per la continuità del servizio se il server principale si guasta, ma replica anche gli errori: una tabella cancellata sul principale viene cancellata sulla replica una frazione di secondo dopo. La replica protegge dai guasti dell'hardware, non dagli errori umani né dai programmi difettosi.
Provare il ripristino
Un backup mai ripristinato è un'ipotesi. I problemi più comuni emergono solo al momento del restore: file incompleti, permessi mancanti, estensioni non installate sul server di destinazione, password di cifratura dimenticate, tempi molto più lunghi del previsto.
Una prova periodica dovrebbe:
- ripristinare il backup su un server separato, mai su quello di produzione;
- misurare il tempo impiegato e confrontarlo con l'RTO;
- controllare il numero di righe delle tabelle principali e alcuni valori noti;
- avviare l'applicazione sul database ripristinato, se possibile;
- annotare la procedura passo per passo, in modo che chiunque possa ripeterla.
Ripristinare automaticamente l'ultimo dump ogni notte su un server di prova ed eseguire qualche query di controllo è un modo economico per sapere ogni mattina che i backup funzionano.
Dove conservarli
Le copie devono stare fuori dal server del database e, almeno una, fuori dalla stessa infrastruttura. È buona pratica cifrarle, perché un dump contiene l'intero patrimonio di dati in un singolo file, e proteggere l'archivio da cancellazioni con copie non modificabili o credenziali separate: se chi attacca il server può cancellare anche i backup, i backup non servono.
In sintesi
- Copiare i file di un database in funzione non garantisce una copia coerente.
- Il dump logico è portabile e flessibile, il backup fisico è più rapido da ripristinare.
- L'archiviazione continua dei registri permette di tornare a un istante preciso.
- RPO e RTO vanno decisi prima di scegliere gli strumenti; una replica non sostituisce il backup.
- Il ripristino va provato regolarmente su un server separato, misurandone i tempi.
