Mysqldump n’est pas un outil de backup

sauvegarde-restauration-mysql1-730x411La sauvegarde d’une base de données mySQL est une tâche basique… ou plutôt devrait être une tâche basique. Le problème est que les outils fournis par mySQL dans la version Open Source du SGBD sont (très) insuffisants.

La sauvegarde utilisée par la plupart des administrateurs mySQL est un script SQL généré au travers de l’outil mysqldump. Une commande type de mysqldump est

Le premier avantage de ce mode de sauvegarde est qu’il est “humainement lisible”, on peut donc en extraire les parties qui nous intéressent pour d’autres sujets. Ce script a également l’avantage d’être la plupart du temps utilisable sur d’autres SGBD et est peu dépendant de la version de mySQL utilisée.

Il a cependant de gros désavantages

Génération du fichier de sauvegarde

La génération du fichier est couteuse en terme de performances pour le serveur mySQL en particulier lorsque celle-ci est volumineuse. Corollaire du précédent, si la génération du fichier prend plusieurs minutes / heures, on arrive à un fichier non consistant, toutes les tables n’ayant pas été sauvegardées en même temps.

Comme mysqldump envoie la commande de désactiver les Foreign Keys pour un futur import, on se retrouve avec une base de données corrompue.

Stockage du ficher de sauvegarde

On parle rarement de ce sujet, et pourtant cela me parait être à elle-seule une raison suffisante d’oublier ce mode de sauvegarde : la sécurité du fichier.

Quelque soit la finesse des droits que vous avez placé dans votre application et sur la base de données mySQL, votre fichier SQL est en plain text, lisible par n’importe qui. Si il est envoyé en FTP non crypté, s’il est accessible en HTTP ou s’il est stocké sur un CD, vos données sont récupérables. Si le contenu de votre base est une suite d’articles postés sur internet, ce n’est pas un gros problème, mais si vous y avez stocké des informations client, ou bien pire, il est temps de se préoccuper de l’endroit où naviguent vos fichiers SQL…

Évidement, le fichier est du SQL et est non compressé, à minima, il faudra donc y ajouter un gzip pour ne pas consommer de l’espace inutilement (et puis c’est plus facile pour l’embarquer sur une clé USB – cf point précédent 😉 )..

Restauration

On touche ici le point le plus sensible de la sauvegarde : on ne peut pas parler de sauvegarde sans parler de restauration. On le sait tous, j’enfonce des portes ouvertes, et pourtant…

J’ai eu l’occasion il y a plusieurs mois, dans le cadre de la migration d’un serveur, de devoir restaurer la sauvegarde mySQL d’une base de 40 Go. Heureusement que ce n’était pas une récupération après un sinistre ! il a fallu plusieurs jours (oui, JOURS) pour récupérer la base. J’ai pris le fichier SQL, je l’ai saucissonné pour le rendre plus digeste, j’ai tenté les autocommit = false (sur innoDB), etc, etc…

J’ai donc dit et redit à qui voulais bien l’entendre et je profite de cette chronique pour le redire : une sauvegarde doit permettre une restauration dans le MINIMUM de temps. Idéalement, le fichier de sauvegarde doit être utilisable “en l’état” pour relancer une base de données.

Cahier des charges d’un outil de backup de base de données

Ma conclusion intérmédaire de la définition d’un outil de sauvegarde de base de données en quelques points :

    1. Doit permettre de générer un fichier de sauvegarde en minimisant à tous prix l’impact sur les bases de données de production
    2. Doit utiliser un format de stockage compact qui permet de maintenir la sécurité des données
    3. Doit permettre une restauration rapide avec le minimum d’opérations

Force est de constater que mysqldump n’est pas un outil de backup puisqu’il ne satisfait aucune des conditions que j’estime “basiques”.

Heureusement, il y en a de vrais ! (suite bientôt)