Une sauvegarde non testée est une hypothèse
Le taux d'échec des restaurations en situation réelle est le chiffre le plus embarrassant du métier. Les sauvegardes tournent, les rapports sont verts, et le jour venu la restauration échoue ou dure dix fois plus longtemps que prévu.
La cause est presque toujours connue d'avance et jamais vérifiée : personne n'a essayé.
Ce qu'un test doit prouver
Trois choses distinctes, souvent confondues.
Que les données sont là. Le fichier existe dans la sauvegarde, il n'est pas tronqué.
Qu'elles sont exploitables. Une base restaurée doit démarrer, pas seulement occuper un espace disque. Une archive doit s'ouvrir. Un document doit s'afficher.
Que le délai est tenable. Une restauration qui fonctionne en douze heures alors que l'activité en tolère deux est un échec, même si tout arrive intact.
Le troisième point est celui qu'on découvre le jour de l'incident, parce que les deux premiers se testent sur un fichier et le troisième seulement à l'échelle réelle.
Trois niveaux de test, du plus léger au plus sérieux
| Niveau | Ce qu'on fait | Fréquence raisonnable |
|---|---|---|
| Fichier | restaurer un document ancien pris au hasard | mensuelle |
| Service | remonter une base ou une machine sur un environnement isolé | trimestrielle |
| Bascule | faire tourner l'activité sur l'environnement restauré | annuelle |
Le niveau fichier ne coûte presque rien et attrape déjà beaucoup : sauvegarde qui ne tourne plus, support illisible, chiffrement dont la clé a été perdue.
Restaurer sans casser la production
C'est la crainte qui bloque les tests, et elle est légitime : une restauration mal ciblée écrase les données vivantes.
Trois précautions suffisent.
Restaurer ailleurs, jamais par-dessus. Un emplacement neuf, une machine isolée, un nom différent. Aucune procédure de test ne doit pointer vers la production.
Couper le réseau de la machine restaurée avant de la démarrer. Une machine restaurée qui rejoint le domaine, reprend son adresse ou se reconnecte à une file de messages peut créer des dégâts par simple présence.
Écrire le déroulé avant, puis le suivre. Un test improvisé finit un jour par une commande tapée dans la mauvaise fenêtre.
Ce qu'il faut noter à chaque test
Quatre lignes, datées, conservées.
- ce qui a été restauré, et depuis quelle date de sauvegarde
- le temps réel, du lancement à la donnée utilisable
- ce qui a échoué ou surpris
- ce qui a été corrigé ensuite
La deuxième ligne est celle qui alimente le plan de reprise, traité dans la leçon suivante. Sans mesure réelle, les délais annoncés dans ce plan sont des voeux.
Les échecs les plus fréquents
La base sauvegardée à chaud sans cohérence : les fichiers sont là, la base refuse de démarrer.
La clé de chiffrement stockée dans le système qu'on restaure : elle disparaît avec lui.
Le support illisible faute d'avoir été branché depuis deux ans.
La restauration qui fonctionne mais dure trop longtemps, faute d'avoir mesuré.
À retenir
Restaurez ailleurs, jamais par-dessus, réseau coupé. Testez un fichier chaque mois, un service chaque trimestre. Et notez le temps réel : c'est la seule donnée qui rende un plan de reprise crédible.