Comment vérifier que vos sauvegardes se restaurent vraiment

La vraie question qui compte à propos de vos sauvegardes n’est pas « sont-elles exécutées ? ». C’est « à quand remonte la dernière fois où vous en avez réellement restauré une ? ». En audit, on répond à la première par un oui tranquille et à la seconde par un silence gêné. Ce silence, c’est le trou : une sauvegarde qui s’exécute chaque nuit sans erreur ressemble à une sauvegarde qui marche, et ce n’est pas toujours le cas. Vous ne le savez qu’une fois que vous la restaurez.

Cet article parle de la partie que presque personne ne fait : tester la restauration des sauvegardes. Monter l’exercice, le chronométrer et trouver ce qui casse à froid, pas le jour de l’incendie. Parce que la sauvegarde qui n’a jamais été restaurée n’est pas une sauvegarde : c’est une promesse non vérifiée.

La sauvegarde qui n’a jamais été restaurée n’est pas une sauvegarde

Une tâche de sauvegarde qui se termine au vert vous dit une seule chose : que des données ont été lues et écrites ailleurs. Elle ne dit pas qu’elles sont complètes, que le fichier n’est pas corrompu, que la base de données est cohérente ni que vous pouvez démarrer un système avec. Le « vert » mesure l’écriture, pas votre capacité à récupérer. Confondre les deux, c’est le faux sentiment de sécurité le plus cher qui existe en IT.

Le jour où vous devez restaurer n’est jamais un mardi tranquille. C’est à trois heures du matin, avec le rançongiciel déjà à l’intérieur ou le serveur qui ne démarre plus et la direction qui demande quand on refacture. Le pire moment pour découvrir que la sauvegarde de la base de données était à moitié faite, qu’il manquait un dossier ou que restaurer 2 To sur votre ligne prend trois jours. Le test de restauration existe pour que ces découvertes arrivent aujourd’hui, à froid et sans coût, et non à ce moment-là.

Personne n’a un problème de sauvegardes. Tout le monde a un problème de restaurations. La plupart ne le savent simplement pas encore.

Ce qu’est un test de restauration et à quelle fréquence le faire

Un test de restauration, c’est récupérer pour de faux afin de savoir que le jour réel vous le pouvez pour de vrai : vous prenez une sauvegarde, vous la montez dans un environnement contrôlé et vous vérifiez que les données sont là, cohérentes, et que le système fonctionne. Ce n’est pas regarder le rapport ni vérifier que le fichier pèse ce qu’il faut ; c’est toucher les données récupérées et confirmer qu’elles servent. Et tous ne se valent pas : chaque niveau teste une chose différente et a sa fréquence raisonnable.

• Restaurer un fichier ou un dossier (mensuel). L’exercice le moins cher et le plus fréquent dans la vraie vie : quelqu’un a supprimé quelque chose. Récupérez un fichier d’il y a une semaine et un d’il y a un mois et vérifiez qu’il s’ouvre. Cela valide la rétention, pas seulement la copie d’hier soir.
• Restaurer une boîte ou un compte de messagerie (trimestriel). Testez la récupération d’une boîte complète ou de messages précis, surtout avec Microsoft 365 ou Google Workspace, où beaucoup croient — à tort — que le fournisseur fait déjà leur sauvegarde.
• Restaurer un serveur ou une application entière (trimestriel ou semestriel). Monter le serveur de fichiers, l’ERP ou la base de données en isolé et vérifier qu’il démarre et reste cohérent. C’est ici qu’apparaissent les dépendances oubliées : services qui ne démarrent pas, licences, connexions à d’autres machines.
• Récupération bare-metal ou de tout l’environnement (annuel). Reconstruire de zéro, comme s’il ne restait plus rien. La vraie simulation de sinistre : c’est ici que se mesure réellement votre RTO et que sortent les temps que personne n’avait chronométrés.

La règle pratique : plus c’est critique et difficile à reconstruire, plus on le teste souvent. Et chaque fois que quelque chose de significatif change — un nouveau serveur, une migration — il faut refaire l’exercice. Une sauvegarde qui marchait en janvier peut être cassée depuis la migration de mars sans que personne s’en rende compte.

Comment monter un test de restauration sérieux

Un test mal fait donne une tranquillité encore pire que de ne pas tester. « J’ai ouvert un PDF de la copie et il s’affichait » ne prouve rien. Un exercice sérieux se fait dans un environnement isolé, suit un script et produit un chiffre mesuré, pas une impression. Voici notre checklist :

• Environnement isolé, jamais la production. On restaure sur un réseau ou une machine à part, sans toucher aux systèmes vivants. Restaurer sur la production « pour voir si ça marche » est la meilleure façon de transformer un exercice en incident réel.
• Partir du scénario, pas du fichier. Définissez quel sinistre vous simulez : suppression accidentelle, serveur perdu, rançongiciel qui a chiffré la production et les copies accessibles. Restaurez comme vous le feriez ce jour réel.
• Vérifier la donnée, pas qu’elle « existe ». Que la base de données s’ouvre et soit cohérente, que les chiffres tombent juste, que la date de la copie soit celle attendue. Un fichier restauré qui ne s’ouvre pas est un fichier perdu avec plus d’étapes.
• Chronométrer le RTO pour de vrai. Mesurez de « on décide de restaurer » à « le service est utilisable », en incluant ce que personne ne compte : télécharger la copie depuis l’externe, déchiffrer, réinstaller, reconfigurer. Cette horloge est votre RTO réel, pas celui de la brochure.
• Confirmer le RPO réel. Vérifiez combien d’heures de travail vous perdez avec la copie utilisée. Si vous copiez une fois par jour, le pire cas est de 24 heures. Que ce chiffre soit connu et accepté par la direction, par écrit.
• Documenter et comparer à ce qui a été convenu. Consignez le résultat et confrontez-le au RTO/RPO que l’entreprise a dit pouvoir supporter. Si le plan dit huit heures et le test dit vingt-six, vous avez un problème à régler aujourd’hui, au calme.

Ce dernier point est ce qui rend l’exercice utile. Sans un RTO et un RPO convenus avec la direction, le test n’a rien à quoi se mesurer et reste une anecdote technique. Avec eux, chaque exercice vous dit si vous êtes dans ou hors de la marge que votre activité supporte.

Erreurs typiques que l’on ne voit qu’à la restauration

Il y a des pannes qu’aucun rapport de sauvegarde ne détecte, parce qu’elles ne surviennent pas à la copie mais à la récupération. Elles restent invisibles jusqu’au jour où vous restaurez ; c’est pour cela que l’exercice les fait sortir avant qu’elles ne fassent des dégâts.

• Sauvegardes incomplètes. La copie se fait, mais n’inclut pas tout : il manque une base de données, un dossier partagé ou le serveur ajouté il y a huit mois que personne n’a mis dans la tâche. Au vert depuis toujours ; vous récupérez et il manque justement ce qui comptait.
• Dépendances oubliées. Vous restaurez l’application et elle ne démarre pas car il lui manque un service, une version, un certificat ou la machine voisine avec laquelle elle dialoguait. Récupérer un système, ce n’est presque jamais récupérer un seul serveur.
• Chiffrement et clés perdues. La copie est chiffrée — bien — mais la clé était sur le même serveur qui a été perdu, ou personne ne sait où elle se trouve. Une copie que vous ne pouvez pas déchiffrer est un bruit parfaitement inutile.
• Données incohérentes. La copie a été prise avec la base de données en marche et sans dump cohérent : le fichier est là, mais corrompu ou au milieu d’une transaction. Vous ne le découvrez qu’en essayant de le monter.
• RTO réel intenable. Tout est là et tout est correct, mais le restaurer sur votre ligne internet prend quatre jours et l’activité en supporte un. Vous aviez la copie ; vous n’aviez pas le temps.

Aucun ne se règle en achetant plus de disques. Ils se règlent en testant : seul l’exercice les rend visibles pendant que vous pouvez encore les corriger sans hâte ni pertes.

Comment le fait MagicBoxDesk

Tester les restaurations à la main, avec discernement et régulièrement, est exactement le genre de tâche qu’une entreprise occupée à son métier ne finit jamais par faire : importante, pas urgente, jusqu’au jour où elle est ultra-urgente. C’est pourquoi, chez MagicBoxDesk, nous nous en chargeons. Notre sauvegarde managée inclut des restaurations testées régulièrement : nous ne vous livrons pas un logiciel en vous souhaitant bonne chance, mais un service qui répond du résultat. Nous montons vos copies dans un environnement isolé selon leur criticité, nous vérifions que les données sont cohérentes, nous chronométrons le RTO réel et nous vous remettons un rapport avec ce qui marche et ce qu’il faut ajuster avant que cela ne devienne un problème.

Tout cela s’articule avec notre supervision 24/7, qui surveille chaque tâche de copie et alerte si quelque chose échoue — vous l’apprenez par nous, pas par un sinistre —, et avec le reste des services IT managés qui composent votre IT externalisée. La différence est concrète : vous passez de croire que vous êtes protégé à avoir la preuve, avec une date et des temps mesurés.

Arrêtez de faire confiance à votre copie pour restaurer et vérifiez-le. Demandez un devis sans engagement et nous montons les tests de restauration de votre entreprise pour que, le jour où ça va mal, vous récupériez pour de vrai, pas par acte de foi.