Dans beaucoup d’entreprises, le sujet des sauvegardes tient en une phrase rassurante :
“Oui, les backups tournent.”
C’est mieux que rien.
Mais ce n’est pas encore une réponse suffisante.
Parce qu’en réalité, une sauvegarde réussie ne garantit ni la vitesse de reprise, ni l’intégrité des données, ni la capacité réelle à restaurer au moment où l’entreprise en aura besoin.
Et c’est souvent là que le malentendu coûte le plus cher.
Le jour où un incident survient, personne ne demande si la tâche de sauvegarde est passée au vert.
La seule question qui compte devient :
“Combien de temps nous faut-il pour repartir, et avec quoi exactement ?”
Le faux confort du “tout est sauvegardé”
Beaucoup de PME vivent avec une impression de sécurité liée au simple fait d’avoir un outil de backup.
Le problème, c’est que la sauvegarde peut exister et rester pourtant fragile :
- restauration jamais testée ;
- sauvegarde partielle ;
- délai trop long ;
- dépendance à un seul support ;
- accès trop larges ;
- sauvegardes elles-mêmes atteignables par un attaquant.
Autrement dit, une sauvegarde peut tourner tous les jours… sans garantir une vraie reprise.
La vraie différence entre sauvegarder et restaurer
Sauvegarder, c’est copier des données quelque part.
Restaurer, c’est être capable de remettre en service ce dont l’entreprise a besoin, dans un délai acceptable, sans mauvaise surprise.
Et entre les deux, il y a souvent un monde :
- les fichiers sont bien là, mais pas complets ;
- la base existe, mais pas dans un état exploitable ;
- la machine est restaurable, mais trop lentement ;
- les accès ne sont plus clairs ;
- le point de restauration est trop ancien ;
- la procédure réelle n’a jamais été répétée.
C’est pour cela qu’une sauvegarde non testée reste, au fond, une hypothèse.
Ce que beaucoup de PME découvrent trop tard
Le jour où il faut restaurer “pour de vrai”, les problèmes les plus fréquents apparaissent vite :
Le temps réel est trop long
Sur le papier, la sauvegarde existe. Dans la vraie vie, la restauration complète prend beaucoup plus de temps que prévu.
Le périmètre n’est pas celui qu’on imaginait
Certaines données critiques ne sont pas incluses, ou pas avec la bonne fréquence.
Les dépendances ont été oubliées
Restaurer un serveur ne suffit pas si l’application dépend aussi d’un partage, d’une licence, d’un accès cloud, d’un DNS, d’un connecteur ou d’une base séparée.
Les droits d’accès posent problème
Quand personne n’a répété la procédure, on redécouvre les comptes, les mots de passe, les accès d’administration ou les chemins de récupération au pire moment.
La sauvegarde elle-même a été exposée
Si l’environnement de backup est trop proche du reste du SI, il peut être affecté à son tour.
Les 5 questions qu’une PME devrait se poser
1. Qu’est-ce qu’on doit absolument relancer en premier ?
Tout n’a pas la même criticité.
Messagerie, ERP, fichiers, applications métier, NAS, VM, postes clés : il faut connaître l’ordre réel de reprise.
2. En combien de temps peut-on restaurer ?
Pas “théoriquement”.
Réellement.
3. Les sauvegardes sont-elles testées ?
Un test trimestriel, même simple, apporte souvent plus de valeur qu’un statut vert jamais vérifié.
4. Les sauvegardes sont-elles isolées ?
Si un attaquant peut supprimer snapshots, sauvegardes ou accès d’administration, le plan devient beaucoup plus fragile.
5. Qui sait faire quoi le jour J ?
Une sauvegarde sans procédure claire repose trop souvent sur une seule personne ou sur une mémoire approximative.
Ce qu’il faut tester pour de vrai
Une PME n’a pas besoin de simuler une catastrophe totale tous les mois.
Mais elle devrait au minimum tester :
- la restauration d’un fichier critique ;
- la restauration d’une VM ou d’un service important ;
- le temps réel de récupération ;
- l’intégrité des données restaurées ;
- la procédure de reprise ;
- l’accès aux consoles et aux supports nécessaires.
Le but n’est pas de faire un exercice parfait.
Le but est d’éviter les surprises.
Le point souvent oublié : les sauvegardes sont aussi une cible
Dans beaucoup d’attaques modernes, l’objectif n’est plus seulement de chiffrer les données de production.
C’est aussi de neutraliser ce qui permettrait de revenir en arrière.
C’est pour cela qu’il faut surveiller de près :
- les suppressions de snapshots ;
- les modifications de jobs de sauvegarde ;
- les accès inhabituels à l’infrastructure de backup ;
- les comptes ayant trop de droits ;
- les stockages accessibles depuis les mêmes identifiants que le reste du SI.
Une stratégie de sauvegarde n’est donc pas seulement un sujet de copie.
C’est aussi un sujet de séparation et de protection.
Ce qu’un bon dispositif devrait produire
Une PME n’a pas forcément besoin d’un système complexe.
Mais elle devrait au moins être capable de dire clairement :
- ce qui est sauvegardé ;
- à quelle fréquence ;
- où ;
- pendant combien de temps ;
- qui peut restaurer ;
- en combien de temps ;
- et quand cela a été testé pour la dernière fois.
Si ces réponses restent floues, le risque est plus élevé qu’il n’en a l’air.
Conclusion
Le jour où un incident survient, la phrase “les backups tournent” ne suffit plus.
Ce qui compte vraiment, c’est la capacité à restaurer vite, proprement, dans le bon ordre et sans découvrir au passage que le plan reposait sur des suppositions.
La vraie question pour une PME n’est donc pas :
“Faisons-nous des sauvegardes ?”
La vraie question est :
“Si nous devions restaurer demain matin, savons-nous exactement comment repartir ?”
