Pourquoi tester une restauration

Un backup marqué comme réussi n'est pas une preuve de restaurabilité.

Un logiciel de sauvegarde qui indique "succès" a vérifié une chose précise : que le job de sauvegarde s'est déroulé sans erreur détectée à ce moment-là — que les données ciblées ont pu être lues, transférées, et écrites sur le support de destination. C'est une information réelle et utile. Ce n'est pas la même chose que "cette sauvegarde peut être restaurée et le système ou l'application qui en dépend redémarrera correctement".

Ce que "réussi" ne couvre pas

Plusieurs situations produisent un statut de succès alors que la restauration, elle, échouerait ou produirait un résultat inutilisable :

• Une archive écrite intégralement sur le support mais partiellement corrompue par un problème matériel ou de transport, non détecté par le job lui-même.
• Un dump de base de données qui s'importe sans erreur, mais dont le moteur applicatif ne démarre jamais parce qu'un composant dépendant (extension, configuration, schéma partiel) manque à l'arrivée.
• Une politique de rétention ou de rotation qui supprime silencieusement le point de restauration attendu avant qu'il ait pu être testé, sans que cela remonte comme une anomalie côté sauvegarde.
• Une dérive de format ou de version entre l'outil qui a produit l'archive et celui censé la relire, qui ne se manifeste qu'au moment de la restauration réelle.

Dans chacun de ces cas, le tableau de bord du logiciel de sauvegarde affiche un succès. Le problème n'existe, factuellement, qu'au moment où quelqu'un tente réellement de restaurer — ce qui, dans la majorité des organisations, n'arrive qu'en situation de crise, au pire moment possible pour le découvrir.

Ce que la vérification indépendante change

RestorSignal ne se substitue pas au statut du logiciel de sauvegarde : il exécute une restauration réelle, contre un scénario défini à l'avance, et observe ce qui se produit effectivement — l'archive se lit-elle, le système ou la base démarre-t-il, les critères de contrôle attendus sont-ils satisfaits. Le résultat n'est jamais une appréciation vague du type "cette sauvegarde est bonne". C'est une description de faits observés : les composants utilisés pour l'exécution, les critères de contrôle appliqués, ce qui a été constaté, et les limites explicites de ce que le test a couvert.

Cette distinction entre PASS, FAIL et ERROR est stricte et jamais interchangeable : PASS signifie que le contrôle s'est exécuté et que la condition attendue est démontrée ; FAIL signifie que le contrôle s'est exécuté correctement mais que la condition attendue n'est pas satisfaite ; ERROR signifie que le contrôle n'a pas pu être évalué correctement — un délai dépassé, une infrastructure indisponible, une dépendance manquante. Un ERROR n'est jamais assimilé à un PASS, et n'est jamais masqué dans une synthèse globale qui donnerait l'impression que tout va bien.

Références

• TechTarget — « Verify backup data integrity to reduce recovery risks » (ressource externe, en anglais) : illustre, indépendamment de RestorSignal, pourquoi la disponibilité d'une sauvegarde ne suffit pas à établir sa restaurabilité.