Guide · Restauration
Tester la restauration : seule la preuve fait une sauvegarde
En bref : « sauvegarde réussie » signifie seulement que des données ont été écrites, pas qu'un système redémarrera à partir d'elles. Seul un test de restauration régulier et documenté montre si une sauvegarde tient ses promesses en cas d'urgence. Le plus fiable est qu'il s'exécute automatiquement.
Pourquoi les sauvegardes échouent en cas d'urgence
La plupart des restaurations ratées ont des causes peu spectaculaires qu'aucun message de réussite ne révèle :
- Un nouveau disque dur ou un nouveau volume n'a jamais été inclus dans la sauvegarde.
- La base de données a été sauvegardée en pleine écriture et ne démarre pas proprement.
- La clé d'une sauvegarde chiffrée est introuvable.
- Un dossier rétrécit depuis des mois sans que personne ne le remarque, parce qu'une application enregistre ses données ailleurs.
- La machine virtuelle démarre, mais reste bloquée sur un écran d'erreur.
- Plus personne ne sait dans quel ordre les systèmes doivent démarrer.
Ce que vérifie un bon test de restauration
| Niveau | Ce qui est vérifié | Ce que cela détecte |
|---|---|---|
| Données lisibles | Chaque objet stocké est lu et comparé à sa somme de contrôle | Données endommagées ou manquantes dans le store |
| Restaurable | La sauvegarde est entièrement restaurée dans une zone de test | Parties manquantes, mauvaises clés, espace insuffisant |
| Système de fichiers intact | Chaque système de fichiers est vérifié et monté | Sauvegardes incohérentes, partitions défectueuses |
| Contenu plausible | Chaque fichier est lu ; fichiers et volumes de données sont comptés et comparés au dernier test | Fichiers illisibles ou modifiés à l'insu de tous, zones qui rétrécissent, vides ou périmées |
| Aucune trace de rançongiciel | Les fichiers sont examinés à la recherche d'indices de chiffrement : contenu qui ne correspond pas à l'extension ou semble aléatoire, extensions typiques et demandes de rançon | Sauvegardes qui contiennent déjà des données chiffrées |
| Le système démarre | La machine virtuelle est démarrée dans un environnement isolé | Systèmes qui ne démarrent pas, écrans d'erreur |
| Le service répond | Un service comme l'annuaire, la messagerie ou la base de données accepte les connexions | Systèmes qui démarrent mais ne fonctionnent pas |
À quelle fréquence tester ?
Il n'y a pas de délai légal, mais des lois comme NIS2 et le RGPD exigent la vérification régulière des mesures. Ce qui a fait ses preuves :
- Quotidien à hebdomadaire : vérification des données stockées ; pour les gros stores, uniquement des données nouvellement ajoutées.
- Hebdomadaire : un échantillon, pour lequel quelques sauvegardes tirées au hasard sont entièrement restaurées et démarrées.
- Au moins une fois par an : un test des systèmes les plus importants dans le bon ordre, en mesurant le temps nécessaire pour qu'ils soient de nouveau opérationnels.
Plus important que la fréquence : chaque test doit être documenté (quand, quelle sauvegarde, quel résultat). Un test sans preuve ne compte pas lors d'un audit.
Tester sans risque pour l'exploitation
Une machine restaurée ne doit jamais communiquer avec le réseau réel : un second contrôleur de domaine ou serveur de messagerie portant le même nom peut causer de gros dégâts en pleine exploitation. Les restaurations de contrôle doivent donc se faire dans un environnement isolé, sans réseau ou dans un réseau dédié sans connexion vers l'extérieur. Les systèmes dépendants y démarrent dans le bon ordre, par exemple d'abord le contrôleur de domaine, puis le serveur de messagerie.
Comment AegisGrid l'automatise
Le serveur de sauvegarde AegisGrid exécute la restauration de contrôle comme un flux de travail, par exemple chaque samedi matin avec trois sauvegardes tirées au hasard : restaurer, vérifier les systèmes de fichiers en lecture seule et les monter, lire chaque fichier et le comparer au dernier contrôle, démarrer les machines virtuelles dans un environnement QEMU/KVM isolé, vérifier si elles affichent une image, écrivent sur leurs disques ou si leurs services répondent, puis faire le ménage. Le rapport de contrôle arrive par e-mail avec un feu tricolore par disque et par partition et des captures d'écran des machines démarrées ; chaque test est consigné avec son résultat dans le journal de preuves signé et dans le rapport mensuel.
Questions fréquentes sur le test de restauration
Suffit-il de vérifier les sommes de contrôle de la sauvegarde ?
Non. Un contrôle des sommes de contrôle montre que les données stockées n'ont pas changé. Seule une restauration prouve que la sauvegarde est complète et qu'un système en redémarre.
Une restauration de contrôle nécessite-t-elle un environnement de test dédié ?
Il faut de l'espace de stockage pour les données restaurées et, pour démarrer des machines virtuelles, un ordinateur avec virtualisation matérielle. Le serveur de sauvegarde AegisGrid intègre l'environnement isolé ; aucune infrastructure de test dédiée n'est nécessaire.
Peut-on aussi tester des sauvegardes chiffrées ?
Oui, le serveur qui effectue le test a besoin pour cela de la clé. Sans la clé restent possibles la vérification des données stockées, la réplication et le nettoyage.
Voyez une restauration de contrôle sur vos systèmes
Dans un projet pilote, nous restaurons vos sauvegardes à titre d'essai, avec rapport et captures d'écran.