Votre backup est vert. Et alors ?

Tous les matins, votre outil de sauvegarde vous envoie le même rapport : job completed successfully. Voyant vert, dossier classé, café.

Le problème, c'est que ce voyant vert répond à la mauvaise question. Il dit « la copie a été écrite ». Il ne dit pas « cette copie peut être restaurée et exploitée ». Et l'écart entre les deux est énorme.

Les chiffres : l'écart entre sauvegarde et restauration

Les données du secteur sont brutales. Selon l'enquête State of the Backup 2024 de Backblaze (300 décideurs IT interrogés aux États-Unis), seuls 57 % des jobs de sauvegarde en entreprise se terminent avec succès. Plus inquiétant : seules 61 % des tentatives de restauration aboutissent au résultat attendu. Autrement dit, environ 4 restaurations sur 10 échouent au moment précis où l'on a besoin des données.

Et ce moment arrive plus souvent qu'on ne le croit : près de 39 % des organisations restaurent des données depuis leurs sauvegardes au moins une fois par mois.

Côté menaces, les rapports récents sur le ransomware convergent : la grande majorité des attaques ciblent désormais directement les dépôts de sauvegarde, et une large part de ces tentatives réussissent. Les organisations dont les sauvegardes ont été compromises font face à des coûts de récupération plusieurs fois supérieurs à celles dont les sauvegardes sont restées intactes.

Pourquoi un backup « réussi » échoue à la restauration

Un job vert peut masquer une dizaine de pannes silencieuses :

• Dump corrompu ou tronqué : le fichier existe, mais pg_restore s'arrête à 80 %.
• Archive incomplète : la sauvegarde a exclu un répertoire critique depuis un changement de config il y a six mois. Personne ne l'a vu.
• Dépendances manquantes : le dump SQL référence une extension ou un rôle qui n'existe que sur le serveur d'origine.
• Credentials périmés : la clé d'accès au bucket S3 a tourné ; le job écrit encore, mais plus personne ne sait lire.
• Backup chiffré… avec une clé perdue : techniquement parfait, pratiquement inutile.
• Fenêtre dépassée : le job « réussit », mais après la fenêtre prévue — votre RPO réel n'est pas celui que vous croyez.

Aucun de ces cas ne déclenche d'alerte. Tous se découvrent le jour de l'incident.

La seule preuve valable : restaurer pour de vrai

La parade est connue de tous les SRE : tester la restauration régulièrement. Le problème n'a jamais été le « quoi », c'est le « comment » :

1. C'est manuel et chronophage. Provisionner un environnement, télécharger l'archive, restaurer, vérifier, nettoyer, documenter. Personne ne le fait chaque semaine.
2. C'est rarement documenté. Quand un test est fait, la preuve tient dans un message Slack ou la mémoire de l'ingénieur qui l'a lancé.
3. Les outils qui l'automatisent sont enterprise. Veeam SureBackup, Commvault, Rubrik : puissants, mais liés à leur propre écosystème de sauvegarde, et hors budget pour une PME ou une équipe DevOps qui sauvegarde en pg_dump + S3.

Ce que fait RestoreProof

RestoreProof automatise le test de restauration et en produit une preuve cryptographique, sans jamais sortir vos données de votre infrastructure :

• Un runner déployé chez vous (binaire, Docker, Helm ou systemd) récupère la sauvegarde depuis sa source (S3 ou compatible, HTTP, local), la restaure dans un conteneur éphémère, et exécute des sondes de validation : intégrité d'archive, fichiers canaris, requêtes PostgreSQL/MySQL, endpoint HTTP.
• Le runner signe le verdict en Ed25519 avec une clé privée qui ne quitte jamais votre infrastructure. Le rapport est infalsifiable.
• Le plan de contrôle SaaS ne reçoit que le verdict signé — jamais les données, jamais les secrets.
• Les tests se planifient en cron : chaque nuit, chaque semaine, à votre rythme. Vous obtenez un historique de preuves horodatées, exploitable en audit (NIS2, ISO 27001, assurance cyber).

C'est la différence entre « notre backup a tourné » et « voici la preuve signée que notre backup du 14 mars se restaure et contient les données attendues ».

FAQ

Quelle est la différence entre vérifier un backup et tester une restauration ? Vérifier un backup (checksum, taille, présence du fichier) confirme que la copie existe et n'a pas été altérée. Tester une restauration confirme qu'on peut reconstruire un système exploitable à partir de cette copie : base démarrée, données présentes, application fonctionnelle. Seul le second prouve la récupérabilité.

À quelle fréquence faut-il tester ses restaurations ? Les référentiels (ISO 27001 A.8.13, recommandations ENISA/NCSC) parlent de tests « réguliers », les auditeurs attendent généralement des preuves datant de moins de 6 à 12 mois. En pratique, avec un test automatisé, rien n'empêche un test quotidien sur les sauvegardes critiques.

Peut-on tester une restauration sans exposer ses données ? Oui, si le test s'exécute dans l'infrastructure qui détient déjà les données. C'est le principe de RestoreProof : la restauration et la validation tournent chez vous, seul le verdict signé remonte au SaaS.

Sources à lier : Backblaze State of the Backup Survey 2024 ; ISO/IEC 27001:2022 Annex A 8.13 ; Directive (UE) 2022/2555 (NIS2), article 21.