Il y a une phrase inconfortable qui circule chez les administrateurs système : une sauvegarde jamais restaurée n’est pas une sauvegarde, c’est un espoir. Cela paraît exagéré jusqu’au jour où il faut le vérifier au mauvais moment.
Pourquoi elle échoue précisément quand vous en avez besoin
Le problème n’est pas que les sauvegardes ne se fassent pas. Elles se font presque toujours. Le problème, c’est que faire la sauvegarde et pouvoir la restaurer sont deux choses différentes, et seule la première se vérifie d’elle-même.
Les défaillances qui n’apparaissent qu’à la restauration sont toujours les mêmes : la sauvegarde se terminait mais le fichier était corrompu ; le dump de la base a été pris machine en marche et s’est révélé incohérent ; le système copiait un dossier qui n’était plus celui des données car l’application a changé de chemin il y a des mois ; la sauvegarde était bonne mais personne ne connaissait la procédure et six heures ont été perdues à improviser.
Aucun de ces problèmes n’apparaît dans un rapport de sauvegarde réussie. Tous surgissent à la première restauration.
Ce qu’un vrai test doit prouver
Un test de restauration utile ne consiste pas à ouvrir la sauvegarde et constater qu’il y a des fichiers dedans. Il doit répondre à quatre questions avec des données :
- Le système complet revient-il ? Démarré, pas seulement décompressé.
- Combien de temps cela prend-il ? Chronométré. Ce chiffre est votre temps de reprise réel, et il sert à poser des attentes avant une crise, pas pendant.
- Les données sont-elles cohérentes ? Les bases surtout. Qu’elles démarrent et répondent à une requête.
- La procédure est-elle écrite ? Car le jour où il faudra, celui qui la connaît par cœur peut être indisponible.
Comment le faire sans risque
La règle d’or : restaurez toujours vers une destination neuve, jamais par-dessus l’original. Un identifiant différent, et l’interface réseau déconnectée.
Ce dernier détail compte plus qu’il n’y paraît. Une restauration conserve la configuration réseau d’origine : si vous la démarrez connectée, vous aurez deux machines se disputant la même IP et vous casserez la production pendant un test de sécurité. Démarrez-la réseau coupé, vérifiez depuis la console, et détruisez-la ensuite.
À quelle fréquence
Trimestriel est un bon point de départ pour la plupart. Et toujours, sans exception, après un changement significatif : une migration, une mise à jour majeure, un changement de structure de données ou de politique de sauvegarde. Les changements sont précisément ce qui casse les sauvegardes sans prévenir.
Un exemple chiffré
Notre dernier test documenté, mené sur un serveur réel et non sur un cas de laboratoire : restauration complète depuis notre centre de données principal en 33 secondes, et depuis le second centre de données en 58 secondes, les deux fois sur un nœud physique différent de l’original.
L’intéressant dans ces chiffres n’est pas qu’ils soient bas. C’est qu’ils existent : quand un client demande combien de temps prend une reprise, la réponse n’est pas une estimation, c’est une mesure.
Ce que vous devriez demander à votre prestataire
Si vous avez souscrit des sauvegardes chez quelqu’un, la question est directe : quand avez-vous effectué votre dernière restauration réelle, et combien de temps a-t-elle pris ? Un prestataire qui teste a le chiffre sous la main. Celui qui ne teste pas improvise une réponse générique.
Comment nous procédons
Dans nos services de sauvegarde, nous documentons les tests de restauration avec date, source, destination et temps mesurés. Et sur le niveau géré, nous réalisons le test périodique pour vous et vous remettons le rapport. Le tout dans nos deux centres de données en Andorre.