mysqldump Backup: Coerenza e Ripristino MySQL/MariaDB

Quando si parla di gestione di database, il backup non è solo una buona pratica, è un requisito operativo fondamentale. Un’interruzione del servizio può costare migliaia di euro all’ora Gartner e, senza un backup affidabile, il ripristino diventa un’impresa quasi impossibile. MySQL e MariaDB, essendo tra i database relazionali più diffusi, richiedono strategie di backup robuste e, soprattutto, coerenti. Molti amministratori si affidano a mysqldump per la sua semplicità e versatilità, ma conoscerne le opzioni avanzate è cruciale per evitare spiacevoli sorprese.

mysqldump è lo strumento a riga di comando per eccellenza per creare backup logici di database MySQL e MariaDB. Genera un set di istruzioni SQL che possono essere eseguite per ricreare il database o i database originali. La sua forza sta nella capacità di esportare sia la struttura (schema) che i dati, rendendolo ideale per migrazioni, ripristini da disastro e test su ambienti di sviluppo. Tuttavia, la sua efficacia dipende interamente da come viene utilizzato, in particolare per garantire la coerenza transazionale.

Versioni di riferimento: MySQL 8.0 · MariaDB 11.2 · documentazione consultata a novembre 2026

mysqldump o backup fisico: quando basta un dump

La scelta tra un backup logico con mysqldump e un backup fisico (come quelli offerti da Percona XtraBackup o gli snapshot a livello di filesystem) dipende dallo scenario. I backup fisici sono spesso più veloci per database molto grandi e permettono un ripristino point-in-time più granulare, ma richiedono maggiore complessità e spazio. mysqldump è la scelta ideale quando:

• Il database non è estremamente grande (fino a qualche decina di GB).
• Hai bisogno di un backup portabile, facilmente ripristinabile su versioni diverse di MySQL/MariaDB o su altri sistemi operativi.
• Vuoi escludere o includere tabelle specifiche, o modificare i dati prima del ripristino.
• Non puoi permetterti tempi di blocco prolungati per l’applicazione.

Per database più grandi o con requisiti di RTO (Recovery Time Objective) e RPO (Recovery Point Objective) molto stringenti, un approccio ibrido o l’uso di strumenti di backup fisico può essere più appropriato. Tuttavia, per la maggior parte degli ambienti di piccole e medie dimensioni, mysqldump offre un equilibrio eccellente tra semplicità e affidabilità.

Backup coerente senza bloccare le tabelle

Il problema principale di un backup non coerente si manifesta quando il database è in uso. Se mysqldump legge le tabelle mentre sono in corso operazioni di scrittura, i dati esportati potrebbero non riflettere uno stato transazionalmente consistente. Questo è particolarmente vero per i motori di storage non transazionali come MyISAM. Per i motori transazionali come InnoDB (il default in MySQL e MariaDB), la soluzione è l’opzione --single-transaction.

Quando usi --single-transaction, mysqldump avvia una transazione isolata prima di iniziare l’esportazione. Questo significa che tutti i dati letti durante il dump rifletteranno lo stato del database al momento dell’inizio della transazione, garantendo la coerenza senza bloccare le operazioni di scrittura sul database. È fondamentale che tutte le tabelle coinvolte siano di tipo transazionale (InnoDB).

mysqldump --single-transaction --routines --triggers --events appdb | gzip > appdb_$(date +%F).sql.gz

Questo comando esegue il dump del database appdb in modo transazionalmente coerente. L’output viene poi compresso con gzip e salvato in un file il cui nome include la data corrente. Questo è il comando base che userò spesso come esempio per i backup di un singolo database. Leggi anche: logrotate: Configurare Rotazione Log su Linux

Attenzione: --single-transaction non funziona con le tabelle MyISAM o con tabelle che non supportano le transazioni. Se il tuo database contiene tabelle MyISAM, queste verranno bloccate con un LOCK TABLES per garantire la coerenza, il che potrebbe causare un breve downtime. È sempre consigliabile convertire le tabelle MyISAM in InnoDB quando possibile.

Includere procedure, trigger ed eventi

Un backup non è completo se include solo i dati e la struttura delle tabelle. Molti database moderni fanno ampio uso di oggetti come stored procedure, funzioni, trigger ed eventi programmati. Se questi non vengono inclusi nel backup, il database ripristinato potrebbe non funzionare correttamente o perdere funzionalità critiche.

mysqldump offre opzioni specifiche per includere questi oggetti:

• --routines: include le stored procedure e le funzioni definite dall’utente.
• --triggers: include i trigger associati alle tabelle.
• --events: include gli eventi schedulati.

È una buona pratica includere sempre queste opzioni quando si esegue un backup completo di un database applicativo, a meno che non si sia assolutamente certi che il database non ne faccia uso o che questi oggetti possano essere ricreati separatamente. Senza di essi, il ripristino potrebbe lasciarti con un’applicazione che non trova la logica di business necessaria per operare.

Backup di tutti i database

In un ambiente server che ospita più database, potrebbe essere necessario eseguire un backup completo di tutti i database presenti. mysqldump lo permette con l’opzione --all-databases.

mysqldump --single-transaction --all-databases > all.sql

Questo comando esporterà tutti i database (esclusi information_schema, performance_schema e altri database di sistema che di default non vengono inclusi). Anche qui, l’uso di --single-transaction è cruciale per mantenere la coerenza tra i diversi database, purché tutti utilizzino motori transazionali. L’output può essere indirizzato a un file compresso come visto prima.

Nel caso di MariaDB, lo strumento equivalente è mariadb-dump. Le opzioni sono quasi identiche a mysqldump.

mariadb-dump --single-transaction appdb > appdb.sql

Questo assicura che, indipendentemente dalla distribuzione (MySQL o MariaDB), il processo di backup sia standardizzato e affidabile. Leggi anche: Oracle Data Pump: Export e Import con expdp e impdp

Comprimere e ruotare i backup

I file di backup possono diventare molto grandi, specialmente per database con molti dati. La compressione è essenziale per risparmiare spazio disco e ridurre i tempi di trasferimento. gzip è lo strumento più comune per questo scopo e può essere facilmente integrato con mysqldump tramite una pipe.

mysqldump --single-transaction appdb | gzip > /var/backups/mysql/appdb_$(date +%F).sql.gz

La rotazione dei backup è altrettanto importante. Conservare troppi backup vecchi consuma spazio inutilmente, mentre conservarne troppo pochi riduce le opzioni di ripristino. Un approccio comune è mantenere 7 backup giornalieri, 4 settimanali e 12 mensili. Questo può essere gestito con logrotate o con script personalizzati che eliminano i file più vecchi. Leggi anche: Docker Spazio Disco: Prune, Log e Immagini Inutilizzate

Un output tipico di un backup compresso:

-rw-r----- 1 mysql mysql 1.2G Nov  6 10:30 appdb_2026-11-06.sql.gz

Ripristinare un database

Il vero valore di un backup si misura al momento del ripristino. Ripristinare un database da un file mysqldump compresso è un processo semplice ma che richiede attenzione.

gunzip < appdb_2026-10-15.sql.gz | mysql appdb

Questo comando decomprime il file di backup e lo passa direttamente al client mysql, che lo esegue sul database appdb. È fondamentale che il database appdb esista già, oppure che il file di dump contenga le istruzioni CREATE DATABASE. Se stai ripristinando un backup di --all-databases, non specificare un nome di database al client mysql.

Prima di un ripristino critico, assicuratevi di:

1. Avere spazio disco sufficiente: Il database ripristinato può occupare molto più spazio del file compresso.
2. Verificare la versione di MySQL/MariaDB: Problemi di compatibilità tra versioni diverse possono emergere durante il ripristino.
3. Disabilitare temporaneamente i trigger o le foreign key: In alcuni casi, per accelerare il ripristino o evitare errori di integrità, potrebbe essere utile disabilitare temporaneamente i controlli di integrità referenziale o i trigger, riabilitandoli alla fine.

Credenziali senza password in chiaro (option file)

Inserire le password direttamente negli script di backup è una pratica rischiosa per la sicurezza. Un’alternativa molto più sicura è utilizzare un option file, tipicamente ~/.my.cnf.

Crea o modifica il file ~/.my.cnf (nella home directory dell’utente che esegue il backup) con il seguente contenuto:

[client]
user=backup
password=la_tua_password_sicura

Successivamente, imposta i permessi corretti per il file, in modo che solo il proprietario possa leggerlo e scriverlo:

chmod 600 ~/.my.cnf

Ora, mysqldump e mysql leggeranno automaticamente le credenziali da questo file, senza che tu debba specificarle sulla riga di comando. Questo migliora notevolmente la sicurezza, riducendo il rischio che le password vengano esposte in log, nella cronologia della shell o in processi visibili.

Automatizzare con cron e verificare il risultato

L’automazione è la chiave per un processo di backup affidabile. cron è lo strumento standard su Linux per schedulare l’esecuzione di script a intervalli regolari. Un esempio di entry crontab per un backup giornaliero potrebbe essere:

0 2 * * * /usr/local/bin/backup_mysql.sh > /var/log/backup_mysql.log 2>&1

Lo script backup_mysql.sh conterrà tutti i comandi mysqldump e di rotazione. È cruciale che questo script:

• Gestisca gli errori: Controlli il codice di uscita di mysqldump e gzip.
• Generi log dettagliati: Registri l’esito del backup, le dimensioni del file, eventuali errori.
• Invii notifiche: In caso di fallimento, invii un’email o un alert a un sistema di monitoraggio. Leggi anche: Zabbix Agent 2: Installazione, Configurazione e Plugin

Un passaggio troppo spesso trascurato è la verifica del backup. Non basta che il file esista. È buona norma:

1. Controllare le dimensioni del file: Un file di backup insolitamente piccolo potrebbe indicare un errore.
2. Eseguire un gunzip -t: Verifica l’integrità del file .gz senza decomprimerlo completamente.
3. Ripristinare un campione: Periodicamente, ripristinare un backup su un ambiente di test per assicurarsi che sia valido e che il processo di ripristino funzioni. Questa è l’unica vera prova di un backup efficace.

Errori comuni e troubleshooting

Errore o messaggio esatto	Causa	Soluzione
mysqldump: Got error: 1045: Access denied...	Credenziali di accesso errate o permessi insufficienti.	Controlla ~/.my.cnf per username/password, verifica che l’utente abbia i permessi SELECT, LOCK TABLES, SHOW VIEW, TRIGGER su tutti i database/tabelle da dumpare.
mysqldump: Error: 'Access denied; you need (at least one of) the PROCESS privilege(s) for this operation' when trying to dump triggers.	L’utente non ha il privilegio PROCESS necessario per dumpare i trigger.	Assegna il privilegio PROCESS all’utente di backup (GRANT PROCESS ON . TO 'backup'@'localhost';).
mysqldump: Error: 2002: Can't connect to local MySQL server through socket...	Il server MySQL non è in esecuzione o il socket è in una posizione inaspettata.	Verifica che il servizio MySQL/MariaDB sia attivo (systemctl status mysql). Controlla il percorso del socket in my.cnf e nella configurazione del client. A volte, specificare --host=127.0.0.1 risolve i problemi di socket.
mysqldump: Got error: 2013: Lost connection to MySQL server during query	Connessione persa durante un dump di grandi dimensioni.	Aumenta i valori di net_read_timeout, net_write_timeout, wait_timeout nel file my.cnf del server MySQL/MariaDB e riavvia il servizio. Aumenta anche max_allowed_packet se stai dumpando colonne BLOB/TEXT molto grandi.
ERROR 1007 (HY000) at line X: Can't create database 'appdb'; database exists	Tentativo di creare un database che esiste già durante il ripristino.	Se il database deve essere ricreato da zero, eliminalo prima del ripristino (DROP DATABASE appdb;). In alternativa, il dump può essere generato con --no-create-db se la creazione del database è gestita esternamente.

Domande frequenti

Posso usare mysqldump per un backup a caldo con MyISAM?

No, --single-transaction funziona solo con motori transazionali come InnoDB. Per le tabelle MyISAM, mysqldump userà LOCK TABLES, che bloccherà le scritture e alcune letture. Per un backup a caldo di MyISAM senza blocchi, dovresti considerare soluzioni di backup fisico o snapshot a livello di storage, ma è sempre consigliabile migrare a InnoDB per un’affidabilità transazionale superiore.

Quanto tempo impiega mysqldump su un database da 100GB?

Il tempo dipende da molti fattori: velocità del disco, I/O del server, complessità dello schema, numero di righe e carico sul database. Un database da 100GB può richiedere da pochi minuti a diverse ore. La compressione con gzip rallenterà l’esportazione ma ridurrà il tempo di trasferimento e lo spazio finale. Testa sempre i tempi nel tuo ambiente specifico.

È possibile fare un backup incrementale con mysqldump?

mysqldump crea backup logici completi. Non supporta direttamente backup incrementali o differenziali. Per ottenere backup incrementali, devi combinare mysqldump con il binlog di MySQL/MariaDB, oppure utilizzare strumenti come Percona XtraBackup che sono progettati per questo scopo. Il binlog permette il ripristino point-in-time dopo un backup completo.

Come posso escludere tabelle specifiche dal backup?

Puoi usare l’opzione --ignore-table più volte per escludere tabelle specifiche. Ad esempio: mysqldump appdb --ignore-table=appdb.log_table --ignore-table=appdb.temp_data. Questo è utile per escludere tabelle di log o di cache che non sono essenziali per il ripristino e che occuperebbero solo spazio nel backup.

Devo creare un utente MySQL dedicato per i backup?

Sì, è una pratica di sicurezza fondamentale. Crea un utente MySQL con il minimo set di privilegi necessari per eseguire il backup (principalmente SELECT, LOCK TABLES per MyISAM, SHOW VIEW, TRIGGER, PROCESS, EVENT e RELOAD per i binlog). Evita di usare l’utente root per i backup automatizzati, per limitare la superficie di attacco in caso di compromissione delle credenziali.

Conclusioni con takeaway operativi

La gestione dei backup di MySQL e MariaDB non deve essere un’operazione complessa o rischiosa. Adottando le pratiche corrette con mysqldump, puoi garantire la coerenza e l’affidabilità dei tuoi dati. I punti chiave da portare a casa sono:

• Priorità alla coerenza: Usa sempre --single-transaction per i motori transazionali.
• Backup completo: Non dimenticare --routines, --triggers e --events.
• Sicurezza delle credenziali: Utilizza l’option file ~/.my.cnf con permessi 600.
• Automazione e verifica: Schedula i backup con cron, comprimili e, soprattutto, testa periodicamente il processo di ripristino.

Un backup non testato è un backup inesistente. Dedica il tempo necessario a implementare e validare la tua strategia di backup: è l’assicurazione più importante per la continuità operativa dei tuoi servizi.

Fonti

• MySQL 8.0 Reference Manual – mysqldump
• MariaDB Knowledge Base – mariadb-dump
• Gartner: Data Loss Incidents

Aggiornato: novembre 2026