Effettuare il backup di uno o più database Mysql è un compito facilmente eseguibile con il tool mysqldump. Basta dargli in pasto qualche parametro, e il backup è pronto. Ad esempio, per effettuare il backup di DB1, DB2 e DB3:
mysqldump -u UTENTE -pPASSWORD --databases DB1 DB2 DB3 | gzip > mysql.sql.gz
Il comando creerà un archivio .gz contenente il dump in formato .sql dei vostri database. Però, c'è un problema: se volete eseguire mysqldump mentre tutti i servizi sono operativi, quindi ad esempio, su un server di produzione attualmente in uso di un sito web, lanciare il comando mysqldump implicherà un serio rallentamento, se non uno stato di blocco, di tutti i servizi che utilizzano mysql.
Per ovviare a questo problema, c'è la soluzione: bisogna lanciare mysqldump senza lock sulle tabelle.
Il comando qui di seguito vi permetterà di lanciare un dump completo di mysql senza particolari problemi su un server di produzione attualmente attivo e in uso, anche se dovesse avere un load molto elevato.
nice -15 mysqldump -u UTENTE -pPASSWORD --skip-add-locks --compact --quick --lock-tables=false --databases DB1 DB2 DB3 | gzip > mysql.sql.gz
Ho personalmente testato il tutto su un VPS Debian da 16GB di RAM, Quad Core, con doppio SSD, lanciando mysqldump su un database di circa 30GB di dati con circa 500 milioni di righe. Il risultato è stato un dump completo in 65 minuti, che non ha assolutamente comportato il blocco dei servizi attivi.
Questo perchè, oltre alle direttive --skip-add-locks e --lock-tables=false ho anche aggiunto --compact --quick ( meno output verboso sul dump ) e soprattutto ho usato nice, che è un semplice tool che modifica la priorità del processo che segue. La priorità di nice va da -20 ( urgentissimo ) a +19 ( fallo quando riesci ). Con nice -15, quindi, andiamo a dare molta meno priorità al processo di mysqldump, che verrà eseguito proprio quando non c'è null'altro da fare a livello di risorse del sistema.
Per finire, un'ultimo consiglio. I backup, in generale, *non* dovrebbero essere mantenuti e conservati sulla macchina principale, quella dalla quale abbiamo eseguito il backup. Il senso del backup è sempre lo stesso: se si rompe tutto sulla macchina A, devo possedere una macchina B che mi faccia da disaster recovery. Quindi, prendete l'abitudine di spostare i vostri backup verso altre macchine remote, meglio se siano preposte solo a contenere backup.
Il comando per inviare un file ad un server remoto, via SSH, è molto facile e potete integrarlo all'interno dei vostri script .sh preposti ai dump e backup ( leggere la nota in fondo alla guida )
sshpass -p 'PASSWORD' scp -l 3000 /file/del/backup UTENTE@SERVER_REMOTO:/directory/destinazione/
Con questo parametro, inviamo al SERVER_REMOTO il file /file/del/backup all'interno della cartella /directory/destinazione usando UTENTE, PASSWORD per l'accesso. In più, con la direttiva -l 3000 passata a scp, impostiamo un limite in kbit/s per l'invio del dump. Molto utile sui server di produzione, dove non bisogna assolutamente saturare la banda di upload.
Attenzione: il comando qui sopra deve essere utilizzato *solo* in fase di test dei sistemi di backup. A regime, bisogna *sempre* usare un fattore di autenticazione a chiave pubblica / privata nell'utilizzo dei tool via SSH come ad esempio scp. Ripeto, è assolutamente sconsigliato usare sshpass se non per testare i sistemi usando un comando veloce e mnemonico.
