Jay Did Quand nous auditons l'infrastructure d'une entreprise, nous posons toujours la même question : « Quand avez-vous restauré une sauvegarde pour la dernière fois ? »
La réponse la plus fréquente est un silence. Puis : « On a des sauvegardes automatiques, elles tournent tous les soirs. » Ce n'est pas la même chose.
Une sauvegarde jamais restaurée n'est pas une sauvegarde
C'est une hypothèse. Tant que vous n'avez pas remonté vos données sur un système vierge et vérifié qu'elles sont complètes et exploitables, vous ne savez pas si votre dispositif fonctionne. Vous savez seulement qu'un script s'exécute sans renvoyer d'erreur.
Les modes de défaillance que nous rencontrons le plus souvent sont tous silencieux :
- la sauvegarde tourne, mais exclut un répertoire ajouté il y a six mois ;
- la base de données est copiée pendant une écriture, produisant un fichier corrompu ;
- l'espace de destination est plein depuis des semaines, et la tâche échoue sans alerte ;
- les archives sont chiffrées, et la clé se trouve sur le serveur qui vient de tomber.
La règle 3-2-1
C'est la formulation la plus simple d'une stratégie sérieuse, et elle tient en une ligne : trois copies de vos données, sur deux supports différents, dont une hors site.
Trois copies. L'original plus deux sauvegardes. Pas l'original plus une : le jour où vous découvrez que la sauvegarde est corrompue, il ne vous reste rien.
Deux supports différents. Si vos deux copies vivent sur le même serveur, ou sur deux disques du même boîtier, un incident électrique ou un vol les emporte ensemble.
Une copie hors site. C'est la protection contre l'incendie, le dégât des eaux, le cambriolage — et contre les rançongiciels, qui chiffrent systématiquement les partages réseau accessibles depuis la machine infectée.
La nuance qui compte : hors ligne
La règle 3-2-1 a été formulée avant la généralisation des rançongiciels. Aujourd'hui, une copie hors site reste vulnérable si elle est accessible en écriture depuis le système sauvegardé.
Une sauvegarde réellement protégée est soit déconnectée physiquement, soit stockée avec un verrou d'immuabilité qui interdit toute modification pendant une durée définie — y compris par un administrateur dont les identifiants auraient été volés.
Le test que nous faisons faire
Une fois par trimestre, sans prévenir l'équipe technique, nous demandons une restauration complète sur un environnement neuf. Le chronomètre tourne. L'exercice répond à trois questions que personne ne peut deviner sur le papier :
- Combien de temps ? Si la restauration prend onze heures et que votre activité en tolère deux, votre dispositif ne convient pas, même s'il fonctionne parfaitement.
- Combien de données perdues ? Entre la dernière sauvegarde réussie et l'incident, il y a toujours un trou. Sa taille doit être une décision, pas une découverte.
- Qui sait faire ? Si une seule personne maîtrise la procédure et qu'elle est injoignable, la sauvegarde ne vous protège que pendant ses heures de bureau.
Par où commencer
Si vous ne deviez faire qu'une chose cette semaine : prenez la sauvegarde d'hier soir, restaurez-la sur une machine de test, et ouvrez les données. Pas le fichier d'archive — les données réelles, dans l'application.
Dans la moitié des cas que nous accompagnons, ce simple exercice révèle un problème que personne ne soupçonnait. Il vaut mieux le découvrir un mardi matin, calmement, que le jour où tout est déjà perdu.