Une sauvegarde non testée n’est pas une sauvegarde
Nous reprenons régulièrement des systèmes d’information dont les sauvegardes tournent depuis des années sans qu’aucune restauration n’ait jamais été effectuée. Le tableau de bord est vert, les tâches se terminent en succès, les e-mails de rapport arrivent. Et le jour où il faut restaurer, on découvre que la base de données était sauvegardée à chaud sans quiescence, que le disque de rétention était plein depuis six semaines, ou que l’archive est bien là mais que personne ne sait quel mot de passe la déchiffre.
Une tâche en succès ne prouve qu’une chose : la tâche s’est terminée
Un travail de sauvegarde vérifie qu’il a écrit des octets là où il devait les écrire. C’est tout. Il ne vérifie pas que ces octets sont cohérents du point de vue applicatif, qu’ils sont lisibles par la version actuelle du logiciel, ni qu’il existe une procédure exécutable par quelqu’un d’autre que son auteur. Ces trois questions ne se règlent pas par un rapport automatique : elles se règlent en restaurant.
Première marche, la plus facile à monter : demander à l’outil de relire ce qu’il a écrit. Proxmox Backup Server sait le faire seul, et c’est souvent là que la première mauvaise nouvelle arrive.
Mais une vérification d’intégrité ne prouve que l’intégrité. Elle ne dit rien du temps que prendra la remise en service, ni du fait que l’application redémarrera. Pour cela, il faut restaurer pour de bon.
Ce que nous vérifions, et dans quel ordre
- La restauration d’un fichier isolé. Le cas le plus fréquent en production : un utilisateur a écrasé un document. Si cette opération prend une demi-journée, la chaîne est mal conçue, même si elle fonctionne.
- La restauration d’une machine virtuelle complète sur un hôte différent de celui d’origine. C’est là que l’on découvre les dépendances implicites : une adresse IP figée, une licence liée au matériel, un point de montage absent.
- La cohérence applicative. Une base restaurée doit démarrer, pas seulement exister. Nous ouvrons l’application et nous vérifions une écriture, pas seulement un ping.
- Le délai réel, chronométré. Pas le délai théorique du contrat : celui mesuré pendant le test, avec le débit réel du lien de restauration.
Chaque test produit un compte rendu : ce qui a été restauré, sur quelle plateforme, en combien de temps, et ce qui a échoué. Le document qui n’indique aucun échec au premier test est généralement le document d’un test mal conçu.
À quelle fréquence, et sur quoi
Tout tester tous les mois n’arrive jamais, parce que personne n’en a le temps : un protocole irréaliste n’est pas appliqué, et un protocole non appliqué ne vaut rien. Ce que nous recommandons tient en trois lignes.
- Un test complet par an, sur le périmètre critique, chronométré et consigné.
- Un test partiel par trimestre : une machine, un fichier, une base. Une demi-journée suffit.
- Un test systématique après tout changement d’hyperviseur, de version applicative ou de topologie de stockage. C’est le moment où les chaînes se cassent silencieusement.
Le point qui décide de tout : le cloisonnement
Une sauvegarde accessible depuis le système compromis n’est pas une sauvegarde, c’est une cible supplémentaire. Les rançongiciels modernes cherchent les sauvegardes avant de chiffrer les données : c’est devenu la première étape de leur mode opératoire, pas la dernière.
Concrètement, cela signifie que le serveur de sauvegarde ne doit pas être membre de l’annuaire qu’il protège, ne doit pas partager ses identifiants avec la production, et doit refuser la suppression d’archives depuis un client. Nous utilisons Proxmox Backup Server pour cette raison autant que pour ses performances : la déduplication et la vérification d’intégrité y sont natives, et le serveur reste maître de sa rétention.
Les deux chiffres à écrire avant de choisir un outil
Combien de temps l’activité peut-elle rester à l’arrêt, et combien d’heures de données peut-on perdre. Tant que ces deux réponses ne sont pas écrites et validées par la direction, tout débat technique sur l’outil de sauvegarde est prématuré : on ne dimensionne pas une chaîne de reprise sans savoir ce qu’elle doit tenir.
Et lorsque la réponse est « nous ne pouvons rien perdre et ne pas nous arrêter », il faut présenter le coût correspondant. Dans la plupart des cas, la discussion aboutit à un compromis raisonnable — mais un compromis assumé, écrit, plutôt qu’une illusion.
C’est le point de départ de toute mission de continuité et reprise : deux chiffres, puis une architecture, puis un test qui le prouve.