Sur les diagnostics techniques qu’on mène en PME, un constat revient plus souvent que tous les autres : les sauvegardes tournent, les rapports sont verts, et personne n’a jamais restauré quoi que ce soit.
Ce n’est pas de la négligence. C’est une confusion parfaitement compréhensible entre deux affirmations qui se ressemblent : « la sauvegarde a fonctionné » et « les données sont récupérables ». La première est vérifiée automatiquement chaque nuit. La seconde ne se vérifie qu’en essayant.
Pourquoi un rapport vert ne prouve rien
Un outil de sauvegarde vérifie qu’il a écrit un fichier sans rencontrer d’erreur. C’est tout ce qu’il vérifie, et c’est légitime : il ne peut pas savoir si le contenu a du sens.
Six façons de rater une restauration avec un rapport parfaitement vert.
1. La sauvegarde est cohérente pour le disque, pas pour l’application. Copier une machine virtuelle pendant qu’une base de données écrit produit un fichier valide et une base dans un état intermédiaire. Elle refusera de démarrer, ou pire, démarrera avec des données partiellement écrites. C’est le cas le plus fréquent et le plus vicieux, parce que rien ne le signale.
2. Le périmètre a dérivé. La sauvegarde couvre les machines déclarées il y a trois ans. Celle qui a été ajoutée en février n’y figure pas. Personne n’a menti, personne n’a vérifié.
3. Ce qui compte n’est pas dans le périmètre. Les machines sont sauvegardées, mais pas les configurations réseau, ni les certificats, ni les règles de pare-feu, ni le contenu des volumes de conteneurs. On peut restaurer les serveurs sans pouvoir reconstituer le système.
4. Le support est illisible. Les bandes n’ont pas été relues depuis deux ans, ou le stockage distant a une corruption silencieuse sur les blocs anciens. Le fichier existe et ne s’ouvre pas.
5. Il n’y a nulle part où restaurer. La sauvegarde est parfaite et la seule machine capable de l’accueillir est celle qui vient de tomber. Sur un incident matériel, le délai de livraison du remplacement devient le délai de reprise.
6. La sauvegarde est chiffrée et la clé est dans le système perdu. Ce scénario arrive vraiment. Il se termine mal.
Le rançongiciel change la nature du problème
Une panne matérielle est aveugle. Un rançongiciel cherche activement les sauvegardes, parce que c’est ce qui empêche de payer.
Le schéma est connu : l’accès est obtenu, il reste discret plusieurs semaines, il identifie l’infrastructure de sauvegarde, il chiffre ou supprime les copies, puis il chiffre la production. Le rapport de sauvegarde reste vert pendant toute la première partie.
Ce qui protège n’est pas la distance géographique, c’est l’isolation des droits. Si le compte qui écrit les sauvegardes peut aussi les supprimer, et que ce compte est atteignable depuis le système compromis, la copie distante ne sert à rien. Il faut au moins une copie que le système compromis ne peut techniquement pas atteindre : un support déconnecté, ou un stockage configuré pour interdire toute suppression avant une échéance.
C’est un réglage, pas un investissement. Et c’est probablement la ligne la plus rentable de tout cet article.
Le test, et il tient en une heure
Il n’est pas nécessaire de simuler un sinistre complet. Un test partiel régulier attrape la majorité des défaillances.
- Choisissez une machine qui compte. Pas la plus critique la première fois, mais pas une machine vide non plus. Une application réellement utilisée.
- Restaurez-la sur un réseau isolé. Pas à la place de l’originale. Dans un réseau séparé, sans accès à la production, pour qu’elle ne perturbe rien.
- Démarrez-la et connectez-vous. C’est l’étape que le rapport de sauvegarde ne peut pas faire à votre place.
- Vérifiez une donnée datée. Ouvrez un enregistrement créé la veille de la sauvegarde. C’est ce qui prouve que la capture est cohérente, et pas seulement présente.
- Chronométrez. Le temps mesuré est une donnée d’exploitation. Il détermine ce que vous direz à vos clients le jour où ça arrivera.
- Écrivez ce que vous avez fait. Deux pages suffisent. Sans elles, la personne qui devra le faire en urgence, peut-être quelqu’un d’autre, redécouvrira tout sous pression.
Une fois par trimestre pour le critique. Et systématiquement après un changement d’infrastructure, parce que c’est là que les périmètres se perdent. Une migration d’hyperviseur, en particulier, invalide la chaîne de sauvegarde : l’outil connaissait l’ancienne plateforme, pas la nouvelle. Une migration réussie dont les sauvegardes ne fonctionnent plus est un incident qui n’a pas encore eu lieu.
Les deux questions à poser à votre prestataire
Si votre infrastructure est tenue par quelqu’un d’autre, deux questions suffisent, et elles ne demandent aucune compétence technique.
« Quand avez-vous restauré une machine pour de vrai, et laquelle ? »
Une date et un nom, ou rien. « On teste régulièrement » n’est pas une réponse.
« Combien de temps prendrait la restauration complète, et où restaurerait-on ? »
S’il n’y a pas de chiffre, le délai de reprise n’a jamais été mesuré. Ce n’est pas nécessairement grave, mais vous devez le savoir avant l’incident plutôt qu’après.
Ces deux questions figurent dans notre grille de diagnostic technique, et ce sont celles sur lesquelles nous obtenons le plus souvent un silence. Pas par mauvaise foi : parce que tester une restauration ne rapporte rien, ne se voit pas, et n’apparaît sur aucun tableau de bord. C’est exactement le genre de tâche qui ne se fait jamais si personne n’en a la charge explicite.
Pour aller plus loin
- Sept pannes que la supervision classique ne voit pas : pourquoi les voyants verts rassurent à tort
- Grille de diagnostic technique en douze points : la liste à passer sur votre propre infrastructure
- Alternatives à VMware et migration d’hyperviseur : pourquoi la requalification des sauvegardes est un jalon, pas une formalité
- Cybersécurité en PME : par quoi commencer : l’ordre des priorités quand le budget est fini
- Feuille de route stratégique : le diagnostic qui commence par vérifier ce point
- Plan de reprise d’activité en PME : les deux durées dont tout le reste découle