Sauvegarde et restauration

Introduction

En administration système, la perte de données n’est pas une question de « si », mais de « quand ». Qu’elle soit due à une défaillance matérielle, à des bogues logiciels ou à des erreurs humaines, la perte de données critiques peut avoir des conséquences catastrophiques. C’est pourquoi la sauvegarde et la restauration font partie des compétences les plus importantes pour administrer une base de données.

Dans ce laboratoire, vous allez réaliser une simulation complète de « reprise après sinistre ». Vous commencerez avec une base de données fonctionnelle, vous la sauvegarderez, vous la supprimerez pour simuler un sinistre, puis vous la restaurerez à l’aide de la sauvegarde.

Vous apprendrez à :

• créer une sauvegarde logique avec l’utilitaire mysqldump ;
• simuler une panne catastrophique en supprimant une base de données ;
• restaurer la base de données dans son état initial à partir de votre fichier de sauvegarde.

Une sauvegarde logique contient des instructions SQL capables de recréer le schéma et les données. Elle se distingue d’une sauvegarde physique, qui copie les fichiers bruts de la base de données. Ces deux approches existent, mais les sauvegardes logiques sont plus faciles à lire et à comprendre pour les débutants.

Cette distinction est importante, car chaque type de sauvegarde répond à des besoins légèrement différents. Les sauvegardes logiques sont portables et lisibles par l’être humain, tandis que les sauvegardes physiques sont généralement plus proches du moteur de stockage et des mécanismes internes de restauration.

Créer une sauvegarde

Commencez par vérifier que la base de données contient bien des données à sauvegarder. Une base de données nommée app_db a été préalablement remplie avec des données utilisateur.

Affichez les données actuelles :

sudo mysql -e "SELECT * FROM app_db.users;"

Vous devriez voir une liste d’utilisateurs : Alice, Bob et Charlie.

Vous allez maintenant créer une sauvegarde logique avec l’outil mysqldump. Une sauvegarde logique exporte essentiellement un fichier texte contenant toutes les instructions SQL, telles que CREATE TABLE et INSERT, nécessaires pour reconstruire votre base de données à partir de zéro.

Le fichier de sauvegarde n’est donc pas un bloc binaire mystérieux. Il s’agit généralement d’un script SQL qui pourra être exécuté ultérieurement sur un serveur de bases de données afin de reconstruire le schéma et les données.

Exécutez la commande suivante pour enregistrer la base de données dans un fichier nommé backup.sql :

sudo mysqldump app_db > ~/project/backup.sql

Décomposition de la commande :

• mysqldump : l’utilitaire utilisé pour exporter le contenu d’une base de données ;
• app_db : la base de données à sauvegarder ;
• > : l’opérateur de redirection Linux, qui envoie la sortie de la commande vers un fichier ;
• ~/project/backup.sql : le chemin du fichier de destination.

Vérifiez que le fichier de sauvegarde a bien été créé :

ls -l ~/project/backup.sql

Vous pouvez également afficher le début du fichier pour voir les instructions SQL qu’il contient :

head -n 20 ~/project/backup.sql

Simuler une perte de données

Passons maintenant à la partie la plus risquée. Pour tester votre plan de restauration, vous avez besoin d’un sinistre. Vous allez simuler la suppression accidentelle de la base de données de production.

Avertissement : la commande ci-dessous supprime définitivement les données. Dans un environnement de production réel, vous ne l’exécuteriez que si vous étiez absolument certain de vouloir détruire les données.

Cette étape destructive est incluse, car une sauvegarde n’a de valeur que si vous pouvez prouver que la restauration fonctionne après une perte réelle. Une stratégie de sauvegarde qui n’est jamais testée reste une simple supposition.

Supprimez la base de données app_db :

sudo mysql -e "DROP DATABASE app_db;"

Vérifiez que le sinistre s’est produit en essayant d’accéder à la base de données :

sudo mysql -e "USE app_db;"

Vous devriez voir l’erreur suivante : ERROR 1049 (42000): Unknown database 'app_db'.

Cela confirme que la base de données a disparu. S’il s’agissait d’un véritable serveur de production sans sauvegarde, la situation serait très problématique.

Restaurer la base de données

Heureusement, vous disposez du fichier backup.sql. Vous pouvez l’utiliser pour restaurer les données.

Cependant, mysqldump exporte par défaut uniquement le contenu de la base de données, et non la commande permettant de créer la base de données elle-même. Comme vous avez supprimé entièrement app_db, vous devez d’abord créer une base vide qui accueillera les données.

Ce détail aide les débutants à comprendre précisément ce qui a été sauvegardé. Les sauvegardes ne sont pas des instantanés magiques de tout le système, sauf si la commande utilisée et ses options incluent explicitement les éléments concernés.

Créez la base de données vide :

sudo mysql -e "CREATE DATABASE app_db;"

Importez les données depuis votre fichier de sauvegarde :

sudo mysql app_db < ~/project/backup.sql

Décomposition de la commande de restauration :

• sudo mysql : se connecte au serveur de bases de données ;
• app_db : indique à MySQL la base de données cible à utiliser ;
• < : l’opérateur de redirection d’entrée Linux. Il lit le contenu du fichier et le transmet à la commande mysql, comme si vous le saisissiez au clavier.

Si la commande s’exécute sans afficher de message, cela signifie généralement qu’elle a réussi.

Le processus de restauration consiste essentiellement à transmettre de nouveau les instructions SQL au serveur. Autrement dit, la restauration correspond souvent à la réexécution contrôlée des instructions enregistrées dans la sauvegarde logique.

Vérifier la restauration des données

La dernière étape, et la plus importante, de tout plan de sauvegarde est la vérification. Le fait que la commande de restauration ne produise pas d’erreur ne garantit pas que les données sont correctes. Vous devez les contrôler.

Il s’agit de l’une des habitudes opérationnelles les plus importantes dans le travail d’administration des systèmes : la réussite ne signifie pas simplement que « la commande s’est terminée ». Elle signifie que « l’état du système est correct après l’exécution ».

Interrogez à nouveau la table users :

sudo mysql -e "SELECT * FROM app_db.users;"

Critères de réussite :

Vous devriez voir les données initiales :

+----+---------+---------------------+
| id | name    | email               |
+----+---------+---------------------+
|  1 | Alice   | alice@example.com   |
|  2 | Bob     | bob@example.com     |
|  3 | Charlie | charlie@example.com |
+----+---------+---------------------+

Si Alice, Bob et Charlie apparaissent, vous avez réussi à restaurer les données après le sinistre.

Résumé

Dans ce laboratoire, vous avez réalisé un cycle complet de reprise après sinistre. Vous avez appris à :

• Sauvegarder : exporter une base de données dans un fichier avec mysqldump ;
• Détruire : simuler une perte de données avec DROP DATABASE ;
• Restaurer : importer un fichier de vidage SQL avec la redirection d’entrée < ;
• Vérifier : confirmer l’intégrité des données restaurées.

Les sauvegardes régulières constituent votre première protection contre la perte de données. Dans un environnement réel, vous devriez automatiser ce processus et tester fréquemment vos restaurations.