Chapitre 1111 minIntermédiaire
Tester la restauration et superviser les sauvegardes
Par Josselyn C., prof de BTS SIO. Mis à jour le .
À la fin de ce chapitre, tu sauras
- choisir le niveau de test adapté à chaque élément ;
- mener un test de restauration pas à pas et le chronométrer ;
- vérifier l'intégrité d'une sauvegarde ;
- rédiger un compte rendu de test pour ton portfolio ;
- superviser les sauvegardes avec les bons indicateurs.
3 exercices corrigés
Un test de restauration consiste à restaurer réellement une sauvegarde, dans un environnement qui ne gêne pas la production, puis à vérifier que les données sont complètes et utilisables, et à mesurer le temps nécessaire. C'est la seule preuve qu'une sauvegarde fonctionne. L'ANSSI le formule simplement : les sauvegardes doivent être testées régulièrement, et une procédure de restauration du système d'information doit être rédigée et régulièrement mise en œuvre (R22). Ce chapitre montre les niveaux de test, la démarche pas à pas, la vérification de l'intégrité, le compte rendu à produire et la supervision quotidienne des sauvegardes.
Pourquoi une sauvegarde non testée ne vaut rien
Le rapport de sauvegarde affiche « succès », et pourtant la restauration échoue. Les causes sont toujours les mêmes :
- le périmètre est faux : un nouveau partage, une nouvelle base ou un nouveau serveur n'a jamais été ajouté à la tâche ;
- les fichiers ouverts n'ont pas été copiés, ou la base a été copiée dans un état incohérent ;
- la clé de chiffrement ou le mot de passe du dépôt n'existe plus que sur le serveur sinistré ;
- le support est abîmé : secteurs illisibles, cartouche démagnétisée, archive tronquée par un disque plein ;
- la chaîne incrémentale est cassée par un maillon supprimé trop tôt ;
- l'environnement a changé : l'application refuse une base restaurée d'une autre version, le pilote de la carte réseau manque sur le nouveau matériel ;
- la durée réelle de restauration dépasse largement le RTO, ce qu'on découvre le jour du sinistre.
Tous ces problèmes se découvrent en dix minutes lors d'un test, et en dix heures lors d'un sinistre.
Les niveaux de test
| Niveau | Ce qu'on fait | Fréquence indicative |
|---|---|---|
| Vérification automatique | Le logiciel relit ses données et vérifie les empreintes (vérification PBS, borg check, restic check, contrôle de santé Veeam) | Chaque semaine, voire chaque jour |
| Restauration de fichiers | Restaurer quelques fichiers ou un dossier tirés au hasard, dans un emplacement de test | Chaque mois |
| Restauration d'une base de données | Restaurer l'export dans une base de test et lancer quelques requêtes de contrôle | Chaque mois pour les bases critiques |
| Restauration d'une VM ou d'un serveur | Restaurer la machine entière dans un réseau isolé et vérifier qu'elle démarre et rend son service | Chaque trimestre, à tour de rôle |
| Restauration d'une application complète | Restaurer tous les composants (annuaire, base, serveur d'application) et vérifier le fonctionnement de bout en bout | Chaque année pour les applications critiques |
| Exercice de PRA | Dérouler le plan de reprise, avec les équipes, en chronométrant (chapitre 13) | Chaque année |
Les fréquences sont des repères : c'est le plan de sauvegarde qui les fixe, selon la criticité.
Mener un test de restauration pas à pas
- Fixer l'objectif. Quel élément, quel point de restauration, quel critère de réussite, quel temps maximal (le RTO).
- Préparer un environnement isolé. Une VM ou un dossier de test, un réseau isolé (un VLAN sans routage vers la production) pour une machine entière. Une copie d'un serveur restaurée sur le réseau de production provoque des conflits : même adresse IP, même nom, même compte machine dans l'annuaire.
- Restaurer en chronométrant. Note l'heure de début et de fin de chaque étape : récupération de la sauvegarde, restauration, redémarrage, reconfiguration.
- Vérifier. Avec une liste préparée à l'avance : nombre de fichiers, empreintes de fichiers témoins, ouverture de quelques documents, connexion à l'application, nombre de lignes de quelques tables, une opération métier courante (afficher une commande, ouvrir un ticket).
- Conclure. Réussi, réussi avec réserves, ou échoué. Comparer le temps mesuré au RTO.
- Documenter. Remplir le compte rendu (modèle plus bas) et le ranger avec le plan de sauvegarde.
- Corriger. Toute anomalie devient une action, avec un responsable et une date, puis un nouveau test.
- Nettoyer. Supprimer l'environnement de test : une copie restaurée contient des données de production, à protéger comme telles.
Vérifier l'intégrité des sauvegardes
Une empreinte (hachage) calculée au moment de la sauvegarde permet de prouver plus tard qu'un fichier n'a pas changé d'un seul bit.
# Au moment de la sauvegarde : calculer l'empreinte de l'archive et la garder à part
sha256sum glpi-2026-11-02.sql.gz > glpi-2026-11-02.sql.gz.sha256
# Plus tard : recalculer et comparer
sha256sum -c glpi-2026-11-02.sql.gz.sha256
# glpi-2026-11-02.sql.gz: OK
Le fichier d'empreinte ne doit pas être rangé au même endroit que la sauvegarde : un attaquant ou une corruption du support pourrait modifier les deux. Le fonctionnement des fonctions de hachage est expliqué dans le chapitre Fonction de hachage du cours Cryptographie.
Les logiciels qui dédupliquent intègrent ce contrôle : chaque morceau stocké est identifié par son empreinte, et la vérification relit les morceaux pour s'assurer qu'ils correspondent.
| Outil | Vérification |
|---|---|
| Proxmox Backup Server | Tâche de vérification planifiée sur le magasin de données ; état « vérifié » ou « échec » affiché pour chaque sauvegarde |
| BorgBackup | borg check (structure), borg check --verify-data (relit et vérifie toutes les données) |
| restic | restic check (structure), restic check --read-data-subset=10% (relit une partie des données à chaque fois) |
| Veeam | Contrôle de santé (health check) des sauvegardes, et SureBackup qui démarre les VM sauvegardées pour vérifier qu'elles fonctionnent |
| Windows Server Backup | Pas de vérification intégrée poussée : seule une restauration réelle prouve la sauvegarde |
Le compte rendu de test
Le compte rendu est la preuve que la commission de l'E5 attend, et la mémoire de l'équipe. Il tient en une page.
| Rubrique | Exemple chez Alvéa |
|---|---|
| Date et auteur | 4 novembre 2026, Inès Moreau (technicienne) |
| Objet du test | Restauration complète de la VM SRV-GLPI |
| Sauvegarde utilisée | PBS, magasin depot1, sauvegarde du 3 novembre 2026 à 21 h 00, état vérifié |
| Environnement | Nœud Proxmox de test, VLAN 999 isolé, sans routage |
| Déroulé et horaires | 14 h 02 début de la restauration ; 14 h 19 fin ; 14 h 22 VM démarrée ; 14 h 31 vérifications terminées |
| Vérifications | Connexion web à GLPI : OK ; ticket n° 2481 du 3 novembre présent : OK ; 1 247 matériels dans l'inventaire, conforme au rapport de la veille : OK ; connexion LDAP : impossible dans le VLAN isolé, attendu |
| Durée totale | 29 minutes, pour un RTO de 2 jours : conforme |
| Résultat | Réussi |
| Anomalies et actions | La procédure ne précisait pas l'agent QEMU à vérifier après restauration : procédure mise à jour |
| Prochain test | Février 2027 (SRV-FIC) |
Superviser les sauvegardes au quotidien
Les sauvegardes échouent régulièrement : disque plein, VM verrouillée, serveur éteint, mot de passe expiré, réseau coupé. Le danger n'est pas l'échec, c'est l'échec que personne ne voit. La supervision repose sur quelques indicateurs :
| Indicateur | Ce qu'il révèle | Seuil d'alerte typique |
|---|---|---|
| Âge de la dernière sauvegarde réussie, par élément | Une tâche qui ne tourne plus, même sans message d'erreur | Plus de 26 heures pour une sauvegarde quotidienne |
| Taux de réussite des tâches | La fiabilité globale | En dessous de 98 % sur le mois |
| Durée des tâches | Une fenêtre de sauvegarde qui déborde sur la journée | Fin après l'arrivée des utilisateurs |
| Volume sauvegardé | Une explosion (fichiers chiffrés) ou une chute (données supprimées, périmètre cassé) | Écart de plus de 50 % par rapport à la moyenne |
| Espace libre sur le stockage de sauvegarde | Le prochain échec annoncé | Moins de 20 % libre |
| Date du dernier test de restauration réussi | Le « 0 » de la règle 3-2-1-1-0 | Plus vieux que la fréquence prévue au plan |
L'âge de la dernière sauvegarde réussie est l'indicateur le plus utile : il détecte aussi la tâche supprimée ou désactivée, qui n'envoie plus aucun rapport, donc plus aucune erreur. Ces contrôles s'intègrent à l'outil de supervision (Zabbix et Grafana dans le labo SISR, Centreon ailleurs) présenté dans le cours Supervision.
Exercices
Exercice 1 sur 3 Préparer un test Réussi À revoir
Tu dois tester la restauration de la base PostgreSQL de l'ERP d'Alvéa à partir de l'export de la nuit. Rédige les étapes et au moins quatre vérifications concrètes.
Voir la réponseMasquer la réponse de l'exercice 1
Étapes : choisir l'export de la nuit et noter son heure ; vérifier son empreinte ; créer une base vide sur un serveur de test (createdb erp_test) ; restaurer (pg_restore -d erp_test …) en notant l'heure de début et de fin ; vérifier ; rédiger le compte rendu ; supprimer la base de test.
Vérifications possibles :
pg_restorese termine sans erreur ;- le nombre de lignes de quelques tables clés (commandes, clients, articles) correspond à celui relevé en production à l'heure de l'export ;
- la dernière commande enregistrée avant l'export est présente ;
- l'application ERP de test se connecte à la base et affiche une commande ;
- le temps de restauration mesuré est compatible avec le RTO de 4 heures, une fois ajoutées les autres étapes.
Tu avais trouvé ?
Exercice 2 sur 3 Un compte rendu à reprendre Réussi À revoir
Voici le compte rendu d'un stagiaire : « Test de sauvegarde du 12/10. J'ai vérifié dans la console que la sauvegarde de cette nuit était en vert. Résultat : OK. » Explique pourquoi ce n'est pas un test de restauration et liste ce qui manque.
Voir la réponseMasquer la réponse de l'exercice 2
Le stagiaire a seulement lu un rapport de sauvegarde : rien n'a été restauré, donc rien ne prouve que les données sont complètes et utilisables. Il manque : l'élément restauré et la sauvegarde utilisée ; l'environnement de test ; la restauration elle-même, avec les horaires et la durée ; les vérifications concrètes (fichiers ouverts, comptages, application qui fonctionne) ; la comparaison avec le RTO ; les anomalies et actions ; l'auteur et la date complète.
Tu avais trouvé ?
Exercice 3 sur 3 Indicateurs du mois Réussi À revoir
En octobre, Alvéa a exécuté 6 tâches de sauvegarde chaque nuit pendant 31 nuits. 9 exécutions ont échoué. La tâche de GLPI n'a plus produit aucun rapport depuis le 24 octobre, sans erreur.
- Calcule le taux de réussite des exécutions qui ont eu lieu, en supposant que les 8 nuits sans rapport de GLPI (du 24 au 31 inclus) n'ont rien exécuté.
- Quel indicateur aurait détecté le problème de GLPI dès la première nuit ?
Voir la réponseMasquer la réponse de l'exercice 3
- Exécutions prévues : 6 × 31 = 186. Exécutions qui ont eu lieu : 186 − 8 = 178. Réussies : 178 − 9 = 169. Taux de réussite : 169 ÷ 178 ≈ 94,9 %, sous le seuil habituel de 98 %. Rapporté aux exécutions prévues, il tombe à 169 ÷ 186 ≈ 90,9 %.
- L'âge de la dernière sauvegarde réussie de GLPI : la dernière date du 23 octobre au soir, et l'âge a dépassé le seuil de 26 heures dès la nuit du 24 au 25 octobre. Le taux de réussite seul ne voit rien, puisqu'une tâche qui ne tourne pas ne produit ni succès ni échec : c'est pourquoi on calcule aussi le taux sur les exécutions prévues.
Tu avais trouvé ?