Sauvegarde et restauration

1. Introduction

Combien de fois vous est-il arrivé de perdre des données et de vous rendre compte que vous n’aviez aucun moyen de les récupérer ? C’est l’aléa de tout administrateur qui n’a pas pris le temps de mettre en place une politique de sauvegarde adéquate. En effet, certains estiment qu’ayant mis en place une réplication entre deux serveurs MariaDB ils se sont mis à l’abri de la perte ou de la corruption de données, mais il n’en est rien. Une mauvaise manipulation sur l’un des serveurs et ils peuvent tout perdre. Alors ne faites pas comme eux...

De la même façon, on ne peut pas être sûr de récupérer ses données tant que l’on n’a pas testé la procédure de restauration. Avoir sauvegardé ses données est une bonne chose, mais si la procédure de restauration n’a pas été correctement testée et validée, cela ne vous servira pas à grand-chose. Ce chapitre a pour but de vous familiariser avec les concepts inhérents à la sauvegarde et de vous enseigner les différents moyens disponibles vous permettant d’aboutir à une solution qui vous conviendra.

Pensez à sauvegarder vos fichiers de configuration. Le comportement de votre base de données risque de complètement changer (performances, génération des fichiers binaires...) si vous n’utilisez pas les mêmes paramètres après restauration que lors de la sauvegarde. Ceci peut aussi être le cas de la configuration des systèmes de fichiers. Par exemple, sous Linux, vous avez la possibilité de désactiver la mise à jour des dates d’accès (paramètre mtime pour ext2/ext3) aux fichiers de la base de données qui sont inutiles pour son bon fonctionnement. Vous l’aurez compris, dans la mesure du possible, sauvegardez les parties de votre environnement qui ont une influence sur le fonctionnement de votre base de données. Ainsi lors de la restauration, vous éviterez les mauvaises surprises.

La fréquence de vos sauvegardes, la durée de rétention des journaux binaires (binlogs) et la fréquence de synchronisation de vos fichiers de sauvegarde sur des serveurs...

1. Import/export manuel

MariaDB permet d’exporter le résultat d’une requête dans un fichier, qui sera stocké sur le serveur, à la condition que l’utilisateur possède le privilège FILE. Cette méthode est plus rapide pour importer/exporter le contenu d’une table qu’une sauvegarde SQL, car il n’est pas nécessaire d’interpréter ou de générer les ordres SQL.

Pour cela, vous disposez de la commande SELECT ... INTO OUTFILE qui respecte le format suivant :

SELECTcol1,col2,... INTO OUTFILE'nom_de_fichier' 
FIELDS TERMINATED BY chaine1 OPTIONNALY ENCLOSED BY chaine2  
LINES TERMINATED BY chaine3 FROM nom_de_table;
 

avec :

Ainsi, la requête suivante exporte toutes les données de la table actor :

mysql> SELECT * FROM actor INTO OUTFILE '/var/tmp/actor.txt';  
Query OK, 200 rows affected (0.02 sec)
 

Lorsque la commande est terminée, on retrouve le contenu de la table dans le fichier /var/tmp/actor.txt, les valeurs étant séparées par des tabulations et les valeurs NULL étant remplacées par \N. La taille et le format du fichier actor.txt permettent une manipulation plus simple que la sortie SQL que l’on aurait obtenue avec mysqldump.

En effet, sous UNIX/Linux, vous pouvez utiliser des commandes système basées sur des expressions régulières pour compter un nombre d’occurrences :

$ awk -F"\t" '/PENELOPE/ {print $2}' /var/tmp/actor.txt |uniq 
-c  
    4 PENELOPE
 

Ou modifier un prénom :

$ sed -i 's/PENELOPE/JENNY/' /var/tmp/actor.txt  
$ grep -c JENNY /var/tmp/actor.txt  
4
 

Avec la sortie de mysqldump, vous auriez eu besoin d’ouvrir le fichier d’export et de le modifier manuellement, ou de désactiver...