Pourquoi une sauvegarde non testée n'est pas un vrai plan de continuité

← Retour au blog

Une sauvegarde qui s'exécute n'est pas une sauvegarde qui restaure

Le rapport de sauvegarde vert chaque matin rassure, mais il ne dit rien du temps réel nécessaire pour remettre un serveur en service, ni de l'état exact des données restaurées. Une sauvegarde peut techniquement « réussir » tout en étant inutilisable : fichier corrompu, base de données incohérente, licence logicielle expirée sur l'environnement de restauration. La seule façon de savoir si une sauvegarde fonctionne vraiment est de la restaurer réellement, dans des conditions proches du réel, à intervalles réguliers.

RPO et RTO : chiffrer ce qu'on est prêt à perdre et à attendre

Le RPO (Recovery Point Objective) fixe la quantité de données que l'entreprise accepte de perdre en cas d'incident — par exemple une heure de saisie commerciale. Le RTO (Recovery Time Objective) fixe le délai maximal d'indisponibilité tolérable avant que l'activité ne soit sérieusement pénalisée — par exemple quatre heures pour un serveur de facturation. Sans ces deux chiffres définis à l'avance, il est impossible de savoir si une stratégie de sauvegarde est réellement adaptée à l'entreprise ou simplement rassurante sur le papier.

Une PME d'Île-de-France qui gère sa comptabilité en ligne n'a pas les mêmes objectifs de reprise qu'un atelier de production dont l'arrêt d'une machine pilotée par informatique coûte directement de la production. Le RPO et le RTO doivent donc être discutés système par système, avec les responsables métier concernés, et pas fixés arbitrairement par le seul service informatique.

• Identifier les systèmes critiques et leur tolérance réelle à l'indisponibilité.
• Fixer un RPO et un RTO par système, pas un chiffre unique pour toute l'infrastructure.
• Dimensionner la fréquence des sauvegardes et l'infrastructure de secours en fonction de ces objectifs.

La règle 3-2-1, toujours d'actualité

3 copies des données, sur 2 supports différents, dont 1 copie hors site : cette règle simple garantit qu'aucun incident isolé — panne matérielle, vol, dégât des eaux, incendie — ne peut détruire l'ensemble des copies en même temps. Une seule copie locale, même sauvegardée quotidiennement, reste vulnérable au même sinistre que les données qu'elle protège.

Le support « hors site » ne signifie pas forcément une copie physique déplacée manuellement : une sauvegarde répliquée automatiquement vers un espace cloud distinct, géographiquement séparé du site principal, remplit parfaitement ce rôle et simplifie considérablement l'exploitation quotidienne.

La sauvegarde immuable, un rempart contre le ransomware

Les ransomwares modernes ne se contentent plus de chiffrer les postes : ils cherchent activement les sauvegardes accessibles pour les chiffrer ou les supprimer, afin de forcer la victime à payer. Une sauvegarde immuable ne peut être ni modifiée ni effacée pendant sa période de rétention, même avec des identifiants administrateur compromis. C'est aujourd'hui l'un des points de contrôle les plus regardés par les assureurs cyber avant de couvrir une PME.

Le test de restauration, l'étape que tout le monde saute

C'est le point qui différencie le plus nettement les PME bien préparées des autres. Un test de restauration planifié permet de mesurer un temps de reprise réel, de vérifier l'intégrité des données restaurées et de corriger les défauts de configuration avant qu'un vrai incident ne les révèle. Sans ce test, le RTO annoncé n'est qu'une estimation théorique — et le jour où une PME en a réellement besoin n'est pas le bon moment pour découvrir qu'il faut trois fois plus de temps que prévu.

Ce qu'il faut retenir

Une stratégie de sauvegarde solide combine quatre éléments : des objectifs RPO/RTO chiffrés, la règle 3-2-1, des copies immuables face au ransomware, et surtout des tests de restauration réguliers. Sans le dernier point, les trois premiers ne sont qu'une théorie rassurante. C'est ce test qui transforme une sauvegarde en véritable plan de continuité d'activité.

Un test de restauration n'a pas besoin d'être un exercice lourd organisé une fois par an : une restauration ciblée d'un serveur ou d'une base de données critique, planifiée chaque trimestre sur un environnement isolé, suffit à garder une mesure fiable du temps de reprise réel et à détecter les anomalies avant qu'un incident ne les révèle au pire moment, sans mobiliser des ressources excessives.