Pubblicato originariamente nel 2013. Rielaborato il 23 ottobre 2026: questa revisione sostituisce le vecchie istruzioni.
Partire dall’obiettivo di recupero
Un file SQL non dimostra che un’applicazione sia recuperabile. Definisci quali dati servono e il contesto necessario a usarli: versione del database, struttura, configurazione e dipendenze.
L’articolo del 2013 riportava una password tra gli argomenti del comando. Questa revisione sostituisce quell’esempio: le credenziali non dovrebbero finire nella cronologia della shell o nella documentazione.
Tenere separate le credenziali
MariaDB può leggere un file di opzioni privato, accessibile soltanto all’account del backup. Tienilo fuori dalla cartella pubblica. Questo è un modello con segnaposto, non contiene credenziali reali:
mariadb-dump --defaults-extra-file=/percorso/privato/client.cnf \
--single-transaction --quick nome_database > backup.sql--defaults-extra-file deve essere il primo argomento. Proteggi anche il file SQL: può contenere dati personali e applicativi.
Capire la coerenza
--single-transaction è utile per tabelle transazionali come InnoDB. Non garantisce automaticamente la coerenza di altri motori e non sostituisce una valutazione delle operazioni in corso durante il dump.
Per ambienti eterogenei o modifiche di schema durante il backup serve una procedura adeguata al contesto.
Provare in un ambiente separato
Il test non deve sovrascrivere la produzione. Usa un ambiente distinto, verifica l’importazione e controlla le funzioni essenziali dell’applicazione, proteggendo i dati di prova.
Documentare l’esito
Registra cosa è stato salvato, quando e come. Una prova di recupero riuscita è più significativa di un comando di esportazione terminato senza errori.