Le tableau de bord est vert. Les notifications arrivent chaque matin. L'espace occupé progresse normalement. Tout indique que les sauvegardes fonctionnent.
Puis vient le jour où il faut restaurer pour de bon. Et l'archive est incomplète — elle l'était depuis huit mois, sans qu'aucun indicateur ne le signale, parce qu'aucun indicateur ne mesurait cela.
Ce qu'un « succès » signifie réellement
Un job de sauvegarde en succès affirme une seule chose : le programme s'est terminé sans erreur. C'est tout. Il n'affirme pas que les bonnes données sont dedans, ni qu'elles en ressortiront intactes.
Quatre échecs silencieux couvrent la majorité des cas réels :
L'exclusion trop large. Un motif d'exclusion écrit pour ignorer les caches attrape aussi un répertoire de données. La sauvegarde se termine parfaitement, plus rapide qu'avant — ce qui passe pour une amélioration.
La base copiée à chaud. Sauvegarder les fichiers d'une base pendant qu'elle écrit produit une archive parfaitement valide contenant des fichiers mutuellement incohérents. Rien ne le signale avant la tentative de restauration.
La clé de chiffrement introuvable. Les archives sont chiffrées, c'est bien. La clé est stockée sur le serveur sauvegardé — c'est-à-dire précisément la machine que vous venez de perdre.
La rétention qui a mangé la bonne version. Une corruption survenue il y a six semaines, une rétention de trente jours : toutes les versions conservées contiennent déjà le problème.
Aucun de ces quatre cas ne produit d'erreur. Tous se voient à la première restauration — souvent trop tard.
Ce qui constitue un vrai test
Un test de restauration valable respecte trois règles.
Restaurer vers un emplacement neuf. Répertoire temporaire, conteneur jetable, machine de test. Restaurer par-dessus l'existant est à la fois risqué et moins probant : vous pouvez conclure au succès alors que les fichiers vérifiés étaient déjà là.
Vérifier le contenu, pas la présence. Un fichier tronqué existe. Un fichier vide existe. La vérification doit porter sur des empreintes comparées à celles de la source, ou sur un contrôle applicatif réel.
Vérifier l'exhaustivité. Comparez le nombre d'éléments attendus à celui restauré. C'est ce contrôle, et lui seul, qui révèle les exclusions accidentelles — le mode d'échec le plus courant et le plus discret.
Automatiser sans y passer ses semaines
Un test complet quotidien est irréaliste pour la plupart des installations. Un test partiel mais automatisé est parfaitement atteignable, et il capte l'essentiel du risque.
Le principe : chaque semaine, restaurer un échantillon dans un répertoire temporaire, comparer les empreintes à la source, vérifier le compte, nettoyer, et remonter le résultat dans la supervision comme n'importe quel autre indicateur.
Trois précautions rendent ce test réellement utile :
- Faire varier l'échantillon d'une semaine sur l'autre plutôt que de toujours tester les mêmes fichiers : sinon vous validez indéfiniment le même chemin.
- Inclure au moins un élément applicatif — une base restaurée doit démarrer et répondre à une requête, pas seulement exister.
- Traiter l'absence de résultat comme un échec. Un test qui ne s'exécute plus depuis trois semaines doit alerter, exactement comme un test qui échoue. C'est le piège classique de la supervision : on surveille les erreurs, pas le silence.
La restauration complète annuelle
Le test automatisé valide les données. Il ne valide pas la procédure, et c'est une autre affaire.
Une fois par an, restaurez pour de bon sur un système vierge, sans consulter vos notes habituelles, en chronométrant. Ce que cet exercice révèle est systématiquement le même genre de choses : une dépendance non documentée, un mot de passe présent seulement sur la machine perdue, une étape manuelle que personne n'avait notée, un ordre de restauration qui compte.
Et surtout, il donne la durée réelle. C'est fréquemment la mauvaise nouvelle : une sauvegarde impeccable dont la restauration complète prend trois jours n'est pas un plan de reprise si votre tolérance est de quatre heures. Cette durée ne se devine pas, elle se mesure.
En résumé
Une sauvegarde jamais restaurée n'est pas une sauvegarde : c'est une hypothèse. La transformer en certitude demande peu de choses — une restauration partielle automatisée chaque semaine, une restauration complète chronométrée chaque année — mais c'est la seule dépense qui distingue une protection réelle d'un tableau de bord rassurant.
Commentaires