La maggior parte delle applicazioni (specie quelle web) utilizzano come backend un database.

Il database più diffuso in ambito opensource è MySQL forse perché fa parte del mitico quartetto LAMP o semplicemente perché all’epoca era il dbms più veloce della storia… Chissà quale sarà il futuro di MySQL, ma in questo post è meglio parlare del presente.

Di solito chi ha a che fare con MySQL e vuole salvare i preziosi dati contenuti al suo interno, effettua un backup del database (o dei databases) e salva il dump da qualche parte.
Nulla da eccipere a questo modus operandi.
Ma se il db è grande quanto spazio occupa un backup? Quanto tempo ci si impiega a fare un dump?
Mi è capitato che durante un backup di MySQL l’utilizzo delle risorse schizzasse alle stelle e quindi mi sono messo alla ricerca di un sistema di backup degno di chiamarsi tale e la soluzione è stata ZRM fro MySQL.
Zmanda Recovery Manager (ZRM) for MySQL è un tool che permette di:

• effettuare backup incrementali o full
• avere una gestione centralizzata dei backup
• ricevere notifiche via e-mail, RSS ed HTML sull’esito dei backup
• effettuare backup compressi e criptati
• ripristino dei backup in modo facile
• …e molto altro ancora!

Per altri features ed informazioni consiglio di leggere il WiKi.

In questo primo post vedremo come configurare un backup di un server MySQL che si trova sulla stessa macchina dove risiede MySQL. Ovviamente il backup potrà essere salvato su una partizione NFS o su una chiavetta USB ma in sostanza ZRM e MySQL sono sulla stessa macchina.Nel prossimo articolo vedremo come fare un backup di un server MySQL remoto.

Procediamo con l’installazione, ovviamente su Debian.
Nei repository Debian non c’è il pacchetto (eresiaaaa!) ma dal sito possiamo scaricare il comodissimo .deb:

http://www.zmanda.com/download-zrm.php

Basta selezionare l’ultima release (ad oggi la 2.2) e nella pagina successiva possiamo fare il download del pacchetto  mysql-zrm-client_2.2.0_all.deb.

Prima di installarlo abbiamo bisogno di alcuni software a corredo: perl-DBI e perl-XML-parser.

Installiamo:

apt-get install libxml-parser-perl libdbd-mysql-perl

Se tutto è andato a buon fine installiamo ZRM con:

dpkg -i mysql-zrm_2.2.0_all.deb

Adesso abbiamo ciò che ci serve, ma per fare i backup incrementali abbiamo bisogno che MySQL scriva il suo utilissimo logbin.
Per abilitare questa opzione, basta editare /etc//mysql/my.cnf e decommentare:

log_bin                 = /var/log/mysql/mysql-bin.log
expire_logs_days        = 10
max_binlog_size         = 100M

Adesso il file va salvato e si deve riavviare il server MySQL.

I file di configurazione si trovano nella directory /etc/mysql-zrm, andiamo a vedere cosa c’è dentro:

• mysql-zrm.conf
• mysql-zrm-release
• mysql-zrm-reporter.conf
• RSS.header

Di vitale importanza sono i .conf, perché mysql-zrm-release ci dice che versione abbiamo e RSS.header è autoeplicativo, serve per l’RSS generato dal sistema di backup.

Dentro la directory /etc/mysql-zrm possiamo creare una nuova directory e dentro copiare i .conf appena illustrati.
Ciò ci permette di avere vari set di backup che hanno delle configurazioni proprie ed in più ereditano quelle presenti sotto /etc/mysql-zrm.
Esempio pratico: se tutti i database hanno la password di root identica possiamo specificare username e password nel file /etc/mysql-zrm/mysql-zrm.conf e non nel file mysql-zrm.conf presente nella directory del set.

Passiamo dalla teoria alla pratica.
Voglio fare in modo che venga fatto un backup di svariati server che hanno in comune:

• la password di root di MySQL
• la directory di destinazione dove salvare i file
• il tipo di backup
• uso di routines e quindi il backup delle stesse
• la directory dove sono salvati i logbin di MySQL
• la directory temporanea
• l’indirizzo e-mail sul quale riceve le notifiche
• il tipo di report
• il path dove salvare i report html
• la URL dal quale consultare i report html
• il path da dove prendere l’header per l’RSS

Detto questo avremo che il file /etc/mysql-zrm/mysql-zrm.conf conterrà (nel mio caso, mi raccomando personalizzate i parametri) questo:

backup-mode=logical
destination=/mnt/nfs/mysql-zrm
routines=1
mysql-binlog-path="/var/log/mysql"
tmpdir=/tmp
mailto="info@ideafactory.it"
html-reports=backup-status-info,backup-performance-info
html-report-directory=/var/www/mysql-zrm/reports/
webserver-url=http://backup.ideafactory.it/reports/html/
rss-header-location=/etc/mysql-zrm/

Adesso mi creo il file di configurazione per il set che chiamerò ”silver”  e quindi creerò la directory /etc/mysql-zrm/silver ed il file mysql-zrm.conf al suo interno conterrà (ripeto: nel mio caso!) :

comment=Silver
backup-level=0
all-databases=1
user="root"
password="superpasswordsegreta"
retention-policy=7D
host="localhost"
port=3306
socket=/var/run/mysqld/mysqld.sock

Ci siamo. Proviamo ad eseguire un backup di prova con:

mysql-zrm-scheduler --now --backup-set silver

Ovviamente a me il set si chiama silver…

Prima di spiegare i vari comandi penso sia il caso di illustrare i parametri di configurazione.
Maggiori dettagli si trovano nel capitolo dedicato ai parametri dell’ottimo manuale di ZRM.

Il set “silver” fa un backup completo (backup-level=0) di tutti i database (all-databases=1)  presenti sul server locale infatti ho chiamato il set silver proprio come il server così rende l’idea che il backup è di tutti i database presenti.

Adesso proviamo a dare un backup incrementale.

Non serve editare il file di configurazione del set, perché se passiamo il parametro da linea di comando backup-level=1 viene ignorato quello presente nel file di configurazione. Proviamo:

mysql-zrm-scheduler --now --backup-set silver --backup-level=1

Non vengono fuori errori? Avete ricevuto la comoda e-mail?

Adesso è il caso di fare qualche strage al database e provare a fare un ripristino ma prima vediamo un report dei backup effettuati con il comodo comando:

mysql-zrm-reporter --show backup-status-info

Sotto forma tabellare comparirà un comodissimo riassunto che qui non riporto per motivi di formattazione ma è ben visibile nella documentazione.

Bene, facciamo fuori un database! L’ho appena fatto con un DROP DATABASE…!

Adesso vediamo come ripristinarlo.

La prima domanda è “che backup ho del set a cui apparteneva il defunto database?” La risposta viene da qui:

mysql-zrm-reporter -show restore-info --where backup-set=silver

Dalla lista scelgo il backup corretto è con un semplice:

mysql-zrm --action restore --backup-set silver --source-directory /mnt/ibm/mysql-zrm/silver/20100325214251

Abbiamo riportato in vita il db defunto partendo dallo snapshot posizionato nella directory illustrata dal report!

Se abbiamo cancellato 2 database e ne vogliamo ripristinare solo uno? Beh le opzioni offerte sono molteplici e la guida sul recovery presente nella documentazione ci mostra comandi per risolvere anche i casi disperatissimi!

Fin ora abbiamo visto come fare un backup e come ripristinarlo, una volta scelta la policy più appropriata alle nostre esigenze è il caso di schedulare i backup:

mysql-zrm-scheduler --add -interval daily --start 08:00 --backup-set silver --backup-level 0
mysql-zrm-scheduler --add -interval daily --start 14:00 --backup-set silver --backup-level 1
mysql-zrm-scheduler --add -interval daily --start 19:00 --backup-set silver --backup-level 1

Con questi 3 semplici ed esplicativi comandi ho detto al mio nuovo amizo ZRM di fare 3 backup:

1. il primo alle 8.00 di mattina ed è un full backup
2. il secondo alle 14.00 ed è di tipo incrementale
3. il terzo alle 19.00 ed è sempre incrementale

Le opzioni sono svariate ed accontenteranno tutti. Una domanda sorge spontanea: ma i backup vecchi quando vengono cancellati? Questo viene deciso dal parametro retention-policy, presente nel file di configurazione.

Per questo primo episodio dedicato a ZRM è tutto, spero di aver stimolato la vostra voglia di backup e la curiosità nello spulciare le mille opzioni di questo indispensabile software.