Une sauvegarde de VM
ne vaut que par sa vérification

Une tâche verte n'est pas une preuve

Le rapport dit « sauvegarde terminée, 0 erreur ». Tout le monde est rassuré, et personne ne sait si la machine redémarrerait. C'est la différence entre sauvegarder et pouvoir restaurer : la première opération est une copie, la seconde est un service. Entre les deux, il y a un travail de vérification que presque personne ne planifie.

Notre règle est simple : une sauvegarde de machine virtuelle n'est considérée comme valide que si trois choses sont vraies. Les données sont intactes, la chaîne de restauration fonctionne, et quelqu'un a mesuré combien de temps cela prend.

La chaîne complète, étape par étape

Les trois premières étapes sont automatisables. La quatrième ne l'est pas complètement : il faut un humain qui regarde la machine démarrer, qui vérifie le service, et qui note la durée.

Ce que vérifie réellement un serveur de sauvegarde

Proxmox Backup Server découpe les sauvegardes en blocs identifiés par une empreinte SHA-256, ce qui permet la déduplication et le contrôle d'intégrité. Sa documentation décrit des tâches de vérification planifiées, avec deux réglages qui comptent : ignorer les sauvegardes déjà vérifiées récemment, et revérifier périodiquement l'ensemble (pbs.proxmox.com). La recommandation de l'éditeur est explicite : une vérification quotidienne ou horaire des nouvelles copies, et une revérification complète au moins une fois par mois.

Un détail que peu de gens connaissent, et qui change la conclusion d'un audit : sur des blocs chiffrés, le serveur ne peut contrôler que la somme CRC-32, pas l'empreinte du contenu en clair. Autrement dit, sans la clé, la vérification côté serveur est partielle. La clé fait donc partie de la sauvegarde, et son absence est une panne en attente.

Pour les machines sauvegardées par Veeam, le raisonnement est le même avec d'autres mots. Le contrôle d'intégrité vérifie que les blocs enregistrés correspondent à ce qui a été lu. La vérification de démarrage va plus loin : la machine est lancée dans un environnement isolé, sans réseau de production, avec des scripts qui testent le service. Le rapport ne dit plus seulement « copie lisible », il dit « la machine a démarré et le service a répondu ».

C'est cette différence qui compte dans un audit. Une vérification de blocs protège contre la corruption silencieuse ; une vérification de démarrage protège contre la mauvaise surprise du jour J : pilote absent, service qui ne remonte pas, disque au mauvais contrôleur.

Le test de restauration, chronométré

Un test sérieux ne touche pas la production. Nous restaurons la machine sur un pont réseau isolé, sans DHCP, avec une adresse temporaire, et nous ne la branchons sur rien. Puis nous mesurons trois durées : le temps de copie, le temps de démarrage, et le temps nécessaire pour que le service réponde.

• Le temps de copie dépend du stockage et du réseau. C'est celui qu'on sous-estime le plus.
• Le temps de démarrage révèle les dépendances : une machine qui attend un partage réseau inexistant ne démarre pas.
• Le temps de service est le seul qui compte pour le client : jusqu'à ce que l'application réponde, la restauration n'est pas finie.

La somme des trois donne un RTO réel, à comparer à celui qui est écrit dans le contrat. Un écart de deux heures entre les deux se discute avant l'incident, pas pendant. Nous ne publions pas ici de durée de restauration : elle dépend du stockage, du réseau et de la taille des machines. Elle se mesure par installation et se consigne dans la fiche de contrôle, pas dans un article.

Les pannes qu'on rencontre vraiment

• Le disque plein parce que la purge n'a jamais tourné : les nouvelles sauvegardes échouent silencieusement dans un rapport que personne ne lit.
• La clé de chiffrement perdue après un changement de matériel : les copies sont intactes et parfaitement inutilisables.
• La rétention trop agressive qui supprime la seule copie antérieure à une corruption découverte tardivement.
• Le matériel changé entre la sauvegarde et la restauration : pilote de stockage, version d'hyperviseur, firmware. La machine redémarre, mais pas comme avant.

La fiche de contrôle

Quatre lignes suffisent à savoir où on en est, et nous les relisons chaque mois : date de la dernière vérification réussie, date du dernier test de restauration, âge de la plus ancienne copie disponible, et emplacement des clés. Une fiche sans date ne vaut rien.

Le reste est une affaire de rythme. Une vérification automatique qui tourne seule ne remplace pas un test humain trimestriel, et un test trimestriel ne remplace pas une alerte quand une sauvegarde échoue. Les deux ensemble donnent une phrase qu'on peut dire à un client sans mentir : « si la machine tombe, on la remonte, et voilà en combien de temps ».