Quatorze mois de sauvegardes nocturnes, vertes chaque matin, et des fichiers de 4 Ko. Voilà ce que j’ai trouvé chez un industriel. Le job exportait la base fidèlement, sauf qu’un changement de mot de passe applicatif, six mois plus tôt, le faisait planter en silence. Le script renvoyait 0, personne ne lisait au-delà de ce 0. Quatorze mois d’archives vides, découvertes le jour où il a fallu s’en servir.
La seule preuve qu’une sauvegarde tient, c’est de l’avoir restaurée au moins une fois : pour de vrai, dans un environnement isolé, en relevant le temps de reprise et en écrivant la procédure au calme.
Ce que « la sauvegarde a réussi » ne dit pas
Les jobs tournent, les voyants restent verts, tout le monde dort tranquille. Pourtant ce message ne certifie qu’une chose : des octets ont été copiés quelque part. Il ne garantit ni leur complétude, ni leur cohérence d’un système à l’autre, ni leur capacité à relancer le service. Ces certitudes-là, vous ne les obtenez qu’en restaurant pour de bon.
Les défauts qui ne sortent qu’à la restauration
Quand je restaure réellement, dans un environnement isolé, les problèmes planqués remontent à la surface. Quatre reviennent plus souvent que les autres.
- La sauvegarde incomplète. On a la base mais pas les fichiers qu’elle référence, ou l’inverse. À la restauration, l’application pointe vers des pièces jointes envolées.
- La dépendance invisible. L’appli se restaure puis refuse de démarrer : un certificat, une variable d’environnement, un service tiers qui ne figurait dans aucun périmètre.
- Le chrono qui dérape. Ce qu’on imaginait en une heure en prend six, faute d’avoir jamais déroulé l’opération de bout en bout.
- Le support qui casse net. Le fichier s’ouvre à moitié puis s’interrompt. Quand c’est l’unique copie, la découverte est définitive.
Aucun de ces quatre points ne se voit dans un rapport de sauvegarde. Tous se voient à la première restauration.
La vraie question : combien de temps pour remettre debout ?
« Est-ce que je suis sauvegardé ? » : cette question rassure, et c’est précisément son défaut. Celle qui compte se mesure plutôt qu’elle ne se devine. En combien de temps est-ce que je remets le service en ligne ? Ce temps de reprise, on le relève montre en main, pendant qu’on restaure.
Il surprend, presque toujours. Une PME e-commerce se croyait capable de repartir « dans la matinée ». Premier test à froid : cinq heures rien que pour la base, plus deux heures de reconfiguration réseau qu’on n’avait pas anticipées. Sept heures au total. Pour une boutique qui réalise le gros de son chiffre le week-end, ce nombre déplace toute la discussion : on ne parle plus de savoir si on est protégé, mais de ce qu’on accepte d’investir pour descendre sous les sept heures.
Comment je m’y prends
Je restaure une sauvegarde réelle dans un environnement isolé. Je vérifie que l’application démarre vraiment et que les données tiennent la route, au lieu de me contenter d’un fichier décompressé. Je relève le temps que ça prend. J’écris la procédure pas à pas, en consignant les pièges rencontrés en chemin. Puis je rejoue l’opération à intervalle régulier, pour que la procédure d’aujourd’hui soit encore exacte dans six mois.
Le jour de l’incident, on ne veut surtout pas découvrir comment on restaure. On veut dérouler des gestes déjà répétés au calme.
Ce que cette méthode ne vous garantit pas
Un test réussi prouve une chose et une seule : que cette sauvegarde-là, sur cette cible-là, ce jour-là, repart. Il ne dit rien des sauvegardes que vous n’avez pas testées, ni d’une panne d’un genre inédit qui toucherait justement le maillon que personne n’avait pensé à inclure. Restaurer ne supprime pas le risque, ça le rend visible et chiffrable. C’est déjà beaucoup, mais qui vous promet une garantie totale vous vend autre chose qu’une sauvegarde.