Strategie Essenziali per il Backup di MySQL: Scegliere l'Approccio Giusto per i Tuoi Dati

La tua strategia di backup di MySQL è valida solo se puoi ripristinare da essa sotto pressione. Un file di dump, un'istantanea del filesystem e un backup fisico risolvono diversi problemi di recupero, quindi la scelta giusta dipende dalla dimensione dei tuoi dati, dalla tolleranza ai tempi di inattività e dalla quantità di dati che puoi permetterti di perdere.

Perché i Backup di MySQL Necessitano di un Piano di Ripristino

I backup ti proteggono da più di un semplice guasto del disco. Ti aiutano anche a recuperare da bug dell'applicazione, distribuzioni errate, cancellazioni accidentali, ransomware e interruzioni regionali.

Inizia con due obiettivi:

RTO: Quanto tempo può rimanere inattivo il database mentre lo ripristini?
RPO: Quanti dati recenti puoi perdere?

Ad esempio, un piccolo wiki interno può tollerare un mysqldump notturno e un ripristino di un'ora. Un sistema di produzione degli ordini potrebbe aver bisogno di backup fisici più i log binari per poter recuperare fino a un secondo specifico prima di una DELETE errata.

Backup Logici con `mysqldump`

I backup logici esportano schema e dati come SQL. Sono portatili e facili da ispezionare, ma possono essere lenti da creare e ancora più lenti da ripristinare su database di grandi dimensioni.

Esegui il backup di un database:

mysqldump -u tuo_utente -p nome_del_tuo_database > file_backup.sql

Esegui il backup di tutti i database:

mysqldump -u tuo_utente -p --all-databases > backup_tutti_database.sql

Esegui il backup di tabelle specifiche:

mysqldump -u tuo_utente -p nome_del_tuo_database tabella1 tabella2 > backup_tabelle_specifiche.sql

Includi routine, eventi e trigger quando il tuo schema dipende da essi. I trigger sono inclusi per impostazione predefinita nell'uso tipico di mysqldump, ma rendere esplicita l'intenzione nel tuo runbook di backup aiuta i revisori a notarlo.

mysqldump -u tuo_utente -p --routines --events --triggers nome_del_tuo_database > database_con_programmi.sql

Ripristina in un database esistente:

mysql -u tuo_utente -p nome_del_tuo_database < file_backup.sql

Per carichi di lavoro pesanti su InnoDB, aggiungi --single-transaction in modo che il dump legga un'istantanea coerente senza blocchi lunghi sulle tabelle:

mysqldump -u tuo_utente -p --single-transaction --routines --events nome_del_tuo_database | gzip > file_backup.sql.gz

Evita di usare --single-transaction come unica protezione di coerenza se fai affidamento su tabelle non transazionali come MyISAM. Quelle tabelle necessitano di un diverso piano di blocco o istantanea.

Backup Fisici per Database Più Grandi

I backup fisici copiano i file di dati di MySQL invece di ricostruire il database come SQL. Di solito sono più adatti per set di dati di grandi dimensioni perché il tempo di ripristino è più vicino alla copia dei file e all'applicazione dei log di recupero.

Le opzioni comuni includono:

Istantanee del filesystem o del volume cloud, coordinate in modo che i dati di MySQL siano coerenti in caso di crash o coerenti a livello di applicazione.
Percona XtraBackup, uno strumento open source ampiamente utilizzato per backup fisici a caldo di dati InnoDB compatibili con MySQL.
MySQL Enterprise Backup, lo strumento di backup commerciale di Oracle per distribuzioni MySQL Enterprise.

Crea un backup completo con XtraBackup:

xtrabackup --backup --target-dir=/percorso/del/backup/completo --user=tuo_utente --password=tua_password

Prepara il backup prima del ripristino:

xtrabackup --prepare --target-dir=/percorso/del/backup/completo

Ripristina dopo aver fermato MySQL e spostato la vecchia directory dei dati:

systemctl stop mysql
mv /var/lib/mysql /var/lib/mysql.prima-del-ripristino
mkdir /var/lib/mysql
xtrabackup --copy-back --target-dir=/percorso/del/backup/completo --datadir=/var/lib/mysql
chown -R mysql:mysql /var/lib/mysql
systemctl start mysql

Questo esempio presuppone un nome di servizio e una directory dei dati in stile Debian. Controlla la documentazione del tuo pacchetto, immagine contenitore o database gestito prima di eseguire i comandi di ripristino.

Log Binari e Ripristino Point-in-Time

I backup ti dicono da dove puoi ripristinare. I log binari ti aiutano a riprodurre le modifiche dopo quel backup, che è ciò di cui hai bisogno per il ripristino point-in-time.

Abilita la registrazione binaria su MySQL auto-gestito con l'impostazione log_bin appropriata per la tua versione e pacchetto. Quindi esegui il backup dei log binari in un luogo separato dal server del database.

Quando ripristini, in genere:

Ripristina l'ultimo backup completo o incrementale valido.
Usa mysqlbinlog per riprodurre i log binari fino all'ora o alla posizione target.
Fermati prima dell'istruzione errata se stai recuperando da un errore dell'operatore.

Scegliere la Giusta Strategia di Backup

Usa una semplice regola decisionale:

Database piccoli: inizia con mysqldump automatizzato, compressione, archiviazione fuori sede e test di ripristino regolari.
Database medi: aggiungi backup dei log binari per poter recuperare a un punto nel tempo.
Database grandi o critici per l'azienda: usa backup fisici, backup incrementali dove supportati, log binari, monitoraggio e un'esercitazione di ripristino documentata.

Non scegliere solo in base alla velocità del backup. La velocità di ripristino è più importante durante un incidente.

Pratiche di Backup Che Contano Davvero

Automatizza il lavoro di backup, ma testa il ripristino manualmente fino a quando il processo non diventa noioso. Archivia i backup fuori sede, crittografa i backup sensibili, monitora i fallimenti dei lavori e mantieni la conservazione abbastanza a lungo da rilevare corruzione silenziosa o cancellazioni accidentali scoperte giorni dopo.

Documenta anche l'ordine esatto di ripristino. Durante un'interruzione reale, il tuo futuro te stesso non dovrebbe dover indovinare quale backup completo, backup incrementale e intervallo di log binari appartengono insieme.

Conclusione

Scegli il metodo di backup che corrisponde al tuo obiettivo di ripristino. mysqldump va bene per database piccoli e ripristini portatili. I backup fisici si adattano a sistemi più grandi. I log binari colmano il divario quando hai bisogno di un ripristino point-in-time. Qualunque cosa tu scelga, un backup non conta finché non lo hai ripristinato con successo in un ambiente di test.