Dans une vie professionnelle passée, j’ai eu l’occasion de faire du développement Web (plateforme LAMP), et donc d’utiliser Mysql. Dans le poste que j’occupe actuellement, j’ai du à nouveau fricoter avec le moteur de base de données Mysql dans un premier temps et migration vers MariaDB depuis quelques mois déjà. Alors pourquoi MariaDB ? Tout simplement parce qu’avec le rachat de Sun par Oracle, les orientations que donne ce dernier concernant les logiciels open source ne sont pas en phase avec ma philosophie. Tout ce que je peux dire, c’est que ce basculement a été totalement transparent que ce soit pour les utilisateurs ou pour moi côté administration.

Rentrons dans le vif du sujet, j’ai donc développé une application client/serveur qui permet de gérer nos calculs de prix de revient et Mysql/MariaDB s’est imposé naturellement à moi sachant que l’alternative qui aurait pu être PostgreSQL est un domaine inconnu pour moi.

Au niveau du script que j’utilise, j’ai opté pour Xtrabackup édité par la société Percona. Je vais vous citer quelques points qui m’ont paru essentiels dans mon choix :

• Licence GPL
• permet les backups avec les bases InnoDB ou Myisam
• ne bloque pas les enregistrements et fait des sauvegardes à chaud des tables InnoDB
• effectue la sauvegarde sans « charger » le serveur
• …

Vous trouverez tous les avantages cités par Percona ici. La méthode que j’utilise est une méthode parmi tant d’autres mais elle me donne entière satisfaction, néanmoins, toutes vos remarques sont les bienvenues !

Le serveur est un serveur Debian 6.0 Squeeze qui est para virtualisé via OpenVZ. On ajoute les dépôts de Percona pour permettre l’installation de Xtrabackup :

deb http://repo.percona.com/apt squeeze main
deb-src http://repo.percona.com/apt squeeze main

On installe la clé pour le dépôt :

# gpg --keyserver  hkp://keys.gnupg.net --recv-keys 1C4CBDCDCD2EFD2A
... [some output removed] ...
gpg:               imported: 1

# gpg -a --export CD2EFD2A | apt-key add -

puis on met à jour ses dépôts et on installe le logiciel :

# apt-get update && apt-get install xtrabackup

Mon cahier des charges était simple :

• Sauvegarder les bases de données du lundi au vendredi inclus de 8 à 19h
• Ne garder que 3 jours de sauvegardes de bases

J’ai donc écrit mon script :

#!/bin/sh

#on purge les backups de plus de 3j
/usr/bin/find /root/backup_sql/mysql_hot_*.tar.gz -type f  -mtime +3 | xargs rm -f 

#on crée la sauvegarde des bases
/usr/bin/innobackupex-1.5.1 --defaults-file=/etc/mysql/my.cnf --user='root' --password='XXXX' --no-lock --stream=tar --slave-info /root/backup_sql | gzip - > /root/backup_sql/mysql_hot_`/bin/date +%m-%d-%Y-%H_%M`.tar.gz

Une petite explication sur les paramètres me parait judicieux :

• –defaults-file=/etc/mysql/my.cnf : permet de lire les options de votre fichier my.cnf dont Xtrabackup a besoin
• –user=’root’ –password=’XXXX’ : spécifie le login de l’utilisateur et le mot de passe qui sont utilisés pour effectuer la connexion au serveur
• –no-lock : permet de ne pas verrouiller les tables lors de la sauvegarde
• –stream=tar : permet de rediriger le flux standard vers un fichier tar ici
• | gzip – > /root/backup_sql/mysql_hot_`/bin/date +%m-%d-%Y-%H_%M`.tar.gz : permet de récupérer la sortie standard de l’option précédente pour la compresser à la volée dans un fichier .tar.gz et qui portera un nom du style mysql_hot_12-24-2010-11_00.tar.gz mentionnant ainsi la date ainsi que l’heure de sauvegarde (rappelez vous que j’effectue une sauvegarde toutes les heures)
• /root/backup_sql : lieu de sauvegarde en local des bases

Ces archives sont également dans la foulée poussées sur un NAS et sur le serveur de secours (ici MixMysql2). Le tout se fait via le cron :

# m h  dom mon dow   command
0       9-19    *       *       mon,tue,wed,thu,fri     /root/innobck.sh && rsync -e ssh -avz --delete-after /root/backup_sql/ root@172.20.1.60:/data/mixmysql/
10      9-19    *       *       mon,tue,wed,thu,fri     /usr/bin/scp /root/backup_sql/*.tar.gz  root@mixmysql2:/root/backup_sql/

Voilà pour la sauvegarde. Passons maintenant à la restauration de nos bases le cas échéant. Comme précédemment, j’ai créé un script de restauration qui effectue toutes les étapes nécessaires :

#!/bin/bash

if [ -z "$1" ]
  then
        echo "usage ./restore.sh nomdufichier a restaurer"
	exit;
fi

#Arret du serveur Mysql
echo "Arret du serveur Mysql"
/etc/init.d/mysql stop

#Renommage du rep des data de mysql && suppression d'une vieille restauration
echo "Renommage du repertoire de donnees Mysql"
rm -Rf /var/lib/mysql_old
mv /var/lib/mysql /var/lib/mysql_old

#Creation du rep data de mysql
echo "creation du repertoire mysql"
mkdir /var/lib/mysql

#Copie de l'archive dans le rep data Mysql
echo "Copie de l'archive a restaurer"
cp /root/backup_sql/$1 /var/lib/mysql

#Décompression de l'archive
echo "Decompression de l'archive"
cd /var/lib/mysql && tar xvzfi $1

#Chgt des droits Mysql
echo "Changement de droits des fichiers"
chown -R mysql:mysql /var/lib/mysql

#Effacement de l'archive dans le dossier data
echo "Purge de l'archive dans le dossier data de mysql"
rm -f /var/lib/mysql/$1

#Relance du serveur
echo "Relance du serveur"
/etc/init.d/mysql start

Le fichier est relativement bien commenter, il faut donc lancer la restauration en invoquant le script adéquat en lui passant en paramètre le nom de l’archive à restaurer :

# ./root/restore.sh mysql_hot_12-24-2010-11_00.tar.gz

Et voilà, le serveur est comme il était le 24/12/2010 à 11h00

Cette méthode est une méthode parmi tant d’autres mais c’est celle qui est en production chez nous. Je vous invite me donner vos retours bons ou mauvais du moment qu’ils sont constructifs. Pour aller plus loin, vous pouvez aller consulter la page officielle d’Xtrabackup sur le site de Percona.

Bonne sauvegarde !