Une sauvegarde non testée n'est pas une sauvegarde. Cloud-PBS le fait pour vous.

Tous les tableaux de bord de sauvegarde sont au vert jusqu’au jour où on en a besoin. La sauvegarde s’est exécutée, la taille est cohérente, la rétention est saine, et tout le monde passe à autre chose. Puis une VM tombe, on lance la restauration, et la sauvegarde ne démarre pas, pas de chargeur d’amorçage, système de fichiers défaillant, etc. La sauvegarde existe mais ne peut être restaurée : la coche verte ne sert plus à rien.

C’est la situation inconfortable au centre de la plupart des stratégies de sauvegarde : une tâche de sauvegarde en succès prouve que des données ont été écrites, pas qu’elles peuvent revenir à la vie. Ce sont deux affirmations différentes, et une seule compte au moment d’un incident.

Ce qu’une sauvegarde « réussie » prouve réellement

Quand Proxmox Backup Server termine une tâche et renvoie un succès, il vous dit que les chunks ont été transférés, l’index a été écrit, et le serveur a stocké ce qu’on lui a envoyé. PBS va même plus loin que la plupart des systèmes et permet de lancer une tâche de vérification, qui relit les chunks stockés et les compare à leurs empreintes. Cela détecte la corruption silencieuse du stockage, ce qui a une vraie valeur.

Mais la vérification contrôle l’intégrité de la sauvegarde telle qu’elle est stockée. Elle ne teste pas la capacité de la sauvegarde à être restaurée, fonctionnelle. Une sauvegarde peut être parfaitement intègre et échouer à la restauration, parce que la restaurabilité dépend de choses que la tâche de sauvegarde ne regarde jamais :

• le chargeur de démarrage et le système de fichiers de l’invité ont survécu à l’aller-retour sauvegarde puis restauration,
• l’hôte cible dispose du type de stockage, des instructions CPU et du type de machine attendus par l’invité,
• pour les datastores chiffrés, l’hôte qui restaure détient la bonne clé.

Rien de tout cela n’est visible depuis un journal de tâche. La seule façon de savoir est de restaurer réellement et de démarrer la machine.

Pourquoi presque personne ne teste ses restaurations

Il n’est pas rare de croiser des équipes à qui on demande si elles testent leurs restaurations. La réponse est bien souvent « pas aussi souvent qu’on devrait », honnête et un peu coupable. La raison n’est pas la négligence, c’est le coût. Un vrai test de restauration suppose de trouver du calcul disponible, d’y restaurer une VM complète, de la démarrer en isolation pour qu’elle ne se batte pas avec la machine de production pour une IP ou un nom, de lancer la restauration, tout nettoyer et enfin faire le reporting. Le faire à la main pour une VM peut prendre beaucoup de temps homme. Le faire pour un parc, régulièrement, est un projet que personne n’a le temps de mener.

Alors ça n’arrive pas. La restauration est testée pour la première fois pendant l’incident, c’est-à-dire exactement au mauvais moment pour découvrir qu’elle ne fonctionne pas.

Ce qu’exige vraiment la validation de restauration

Une validation correcte, ce n’est pas « puis-je télécharger la sauvegarde ». C’est une séquence :

1. Restaurer la VM ou le conteneur depuis un instantané précis sur du vrai matériel.
2. Démarrer la machine dans un environnement dédié.
3. Constater que le démarrage fonctionne, pas seulement que l’hyperviseur a lancé le processus.
4. Capturer une preuve qui survit au test : quelque chose que vous pourrez montrer à un auditeur, un assureur ou votre direction des mois plus tard.

L’étape 4 est celle qu’on oublie souvent : un test de restauration qui ne laisse aucune trace est un réconfort personnel, pas un contrôle. Si vous ne pouvez pas produire, à la demande, une preuve montrant que la VM-100 a démarré depuis sa sauvegarde de 2 h du matin à une date donnée, alors sur le plan de la conformité, le test n’a jamais eu lieu.

Comment Cloud-PBS le prouve

C’est la partie de la sauvegarde infogérée que personne d’autre ne fait. Cloud-PBS est, à notre connaissance, le seul service de sauvegarde managé pour Proxmox qui valide la restaurabilité de bout en bout et vous en remet la preuve.

Depuis le tableau de bord, vous choisissez une sauvegarde et lancez un test de restauration. Nous allouons des ressources, restaurons la VM ou le conteneur depuis cet instantané exact et la démarrons. Puis nous capturons ce qui s’est passé :

• une capture d’écran de la machine démarrée,
• le journal de boot,
• un rapport PDF signé qui relie le tout : quel datastore, quel instantané, le résultat, les horodatages, et une signature cryptographique pour que le rapport ne puisse pas être modifié par la suite.

Quand le test se termine, nous démontons tout automatiquement. Aucune machine résiduelle, aucun nettoyage à votre charge. Ce que vous conservez, c’est la preuve : un artefact daté et signé qui atteste que cette sauvegarde précise, ce jour précis, s’est restaurée et a démarré. C’est le document que vous voulez avoir en main lors d’un audit, d’un renouvellement de cyber-assurance, ou d’un vrai sinistre.

La restaurabilité est la seule métrique de sauvegarde qui compte

Autant être direct. Le stockage consommé, le taux de succès des tâches, la profondeur de rétention : c’est de l’hygiène opérationnelle, pas un résultat. La seule question à laquelle une stratégie de sauvegarde doit répondre est « quand j’en aurai besoin, est-ce que ça fonctionnera ».

La validation de restauration, c’est la façon de transformer cette question d’un espoir en un fait, et de la répéter régulièrement pour que la réponse reste vraie à mesure que votre infrastructure évolue en dessous. Si vous êtes sous Proxmox et que vos sauvegardes n’ont jamais été testées, vous ne savez pas réellement si elles fonctionnent. Vous savez qu’un fichier existe.

Cloud-PBS est construit pour combler ce manque : le Test de restauration est intégré à votre instance, et l’essai gratuit de 7 jours vous laisse prouver une restauration sur votre propre charge avant tout engagement.