Comment tester vos sauvegardes (et pourquoi la plupart échouent)

La plupart des entreprises avec lesquelles nous travaillons ont des sauvegardes. Beaucoup moins en ont déjà restauré une. Et une sauvegarde jamais restaurée n’est pas un contrôle — c’est une supposition.

Pourquoi les restaurations échouent

Les tests de restauration trouvent presque toujours quelque chose. Les constats les plus fréquents :

• La tâche de sauvegarde échoue en silence, parfois depuis des mois, et l’alerte va à quelqu’un qui est parti.
• La sauvegarde ne couvre pas tout. Les fichiers sont protégés; la base comptable, le courriel ou une application infonuagique ne l’est pas.
• Les données reviennent, mais le système ne démarre pas — à cause d’une dépendance, d’une clé de licence ou d’une configuration jamais documentée.
• La base se restaure, mais il manque les écritures récentes, parce qu’elle a été copiée pendant son utilisation.
• Les sauvegardes étaient accessibles depuis le réseau et auraient été chiffrées avec tout le reste lors d’un rançongiciel.
• La restauration prend bien plus de temps que prévu. Douze heures, pas deux.

Rien de tout cela n’est exotique. Et tout cela vaut mieux découvert un mercredi planifié qu’au milieu d’un incident.

Comment faire un test de restauration

1. Choisir un système critique. Le serveur de fichiers, la base comptable, une boîte clé.
2. Le restaurer dans un environnement isolé — un endroit qui ne peut ni atteindre ni écraser le système en production.
3. Démarrer un chronomètre. Noter la durée réelle de chaque étape.
4. Vérifier le résultat. Pas seulement l’existence des fichiers : les ouvrir, lancer l’application, confirmer que les données les plus récentes sont là.
5. Noter chaque surprise — étapes manquantes, mots de passe introuvables, dépendances oubliées.
6. En faire un guide d’intervention qu’une autre personne que vous pourrait suivre.

Le chiffre qui compte

À la fin, vous obtenez un seul chiffre : le temps réel pour reprendre le travail. Comparez-le à la durée d’arrêt que l’entreprise peut se permettre (votre RTO) et à la quantité de données récentes qu’elle peut perdre (votre RPO). S’ils ne concordent pas, vous savez maintenant exactement quoi corriger — avant que ça compte.

À quelle fréquence

• Une restauration complète de chaque système critique au moins une fois par année.
• Des vérifications ponctuelles — un dossier ou une boîte — plus souvent.
• Après chaque changement important : nouveau serveur, nouvel outil de sauvegarde, migration. C’est alors que les sauvegardes cessent le plus souvent de fonctionner en silence.

Si vous n’êtes pas certain que vos sauvegardes se restaureraient, c’est la situation décrite dans on n’a pas vraiment de système de sauvegarde. Les tests de restauration font partie de notre pratique en infrastructure et sauvegarde.