« On a des sauvegardes » : le piège de la restauration jamais testée

Il existe une phrase qui rassure tout le monde dans une réunion et qui se révèle dramatiquement creuse le jour de l'incident : « ne vous inquiétez pas, on a des sauvegardes ». Car une sauvegarde n'a strictement aucune valeur en elle-même. Sa seule valeur est sa capacité à être restaurée, intégralement et dans un délai acceptable.

Or, dans la pratique, l'écart entre « la sauvegarde tourne » et « la restauration fonctionne » est béant. Les cas vécus par les administrateurs ne manquent pas :

• le job de sauvegarde affichait un statut vert depuis des mois, mais ne sauvegardait plus la base de données critique depuis un changement de chemin ;
• l'archive existe, mais la clé de chiffrement a été perdue avec l'ancien serveur ;
• la restauration démarre, puis échoue à 80 % sur un fichier corrompu, rendant l'ensemble inexploitable ;
• le temps de restauration réel est de trois jours, là où le client en attendait deux heures.

Dans tous ces cas, la sauvegarde existait. Et dans tous ces cas, elle n'a servi à rien. C'est le risque le plus silencieux du métier : il ne se manifeste qu'au moment précis où l'on en a besoin, et où il est trop tard.

Beaucoup d'administrateurs envisagent la sauvegarde comme une question purement technique. Elle est aussi une obligation réglementaire, et c'est un point que le devoir de conseil vous impose de connaître.

L'article 32 du RGPD, relatif à la sécurité du traitement, exige des mesures techniques appropriées incluant explicitement « la capacité à rétablir la disponibilité des données à caractère personnel et l'accès à celles-ci dans des délais appropriés en cas d'incident physique ou technique ». Le texte va plus loin : il impose « une procédure visant à tester, à analyser et à évaluer régulièrement l'efficacité » de ces mesures.

Le RGPD ne demande pas seulement de sauvegarder. Il demande de tester régulièrement que la restauration fonctionne. Une sauvegarde jamais éprouvée n'est pas conforme.

La portée pour vous est double. D'abord, si vous gérez l'infrastructure d'un client qui traite des données personnelles, l'absence de test de restauration est un manquement que vous deviez signaler. Ensuite, en cas d'incident rendant des données indisponibles, la question de la conformité de la sauvegarde sera posée — et vous y serez associé.

Pendant longtemps, la sauvegarde répondait à des sinistres « bêtes » : panne disque, suppression accidentelle, incendie. Le ransomware moderne a rendu cette vision obsolète, car il s'attaque désormais activement aux sauvegardes elles-mêmes.

Les souches récentes ne se contentent pas de chiffrer les données de production. Elles recherchent et chiffrent en priorité :

• les partages réseau où sont déposées les sauvegardes ;
• les serveurs de sauvegarde accessibles avec les identifiants compromis ;
• les snapshots et les copies stockées sur le même hyperviseur que la production.

Autrement dit, une stratégie de sauvegarde entièrement en ligne et accessible depuis le réseau de production peut être anéantie en même temps que les données qu'elle était censée protéger. C'est la raison pour laquelle la règle 3-2-1 reste la référence : trois copies des données, sur deux supports différents, dont une copie hors site et — c'est le point critique aujourd'hui — isolée du réseau (déconnectée, immuable ou sur bande). Une copie qu'un attaquant ayant pris le contrôle du domaine ne peut pas atteindre.

Lorsque la restauration échoue à cause d'une attaque, le sinistre relève alors de la garantie cyber, qui prend en charge la remédiation, l'éventuelle reconstruction et les obligations envers la CNIL.

Quand un client se retrouve sans ses données après un incident parce que la sauvegarde dont vous aviez la charge n'a pas permis la restauration, deux registres de responsabilité se combinent.

Le préjudice du client. La perte de données et l'arrêt d'activité qui en découle constituent un dommage immatériel. Si la défaillance de la sauvegarde vous est imputable — parce que vous deviez la concevoir, la superviser et la tester —, le client peut engager votre responsabilité contractuelle. C'est la RC Pro qui répond de ce préjudice financier.

La violation de données personnelles. Si les données indisponibles incluent des données à caractère personnel, on entre dans le champ d'une violation au sens du RGPD, avec notification potentielle à la CNIL et exposition à des sanctions. C'est ici que la garantie cyber prend le relais.

Un même incident peut donc mobiliser les deux couvertures : la RC Pro pour le préjudice du client, la cyber pour le volet réglementaire et la remédiation technique. D'où l'intérêt, pour un administrateur dont c'est le cœur de métier, de ne pas dissocier les deux.

Le malentendu le plus fréquent entre un administrateur et son client ne porte pas sur l'existence des sauvegardes, mais sur deux notions rarement explicitées : combien de temps faut-il pour restaurer, et combien de données perd-on au passage. Ce sont le RTO et le RPO.

• Le RTO (Recovery Time Objective) est le délai acceptable de remise en service. Le client imagine souvent deux heures ; la réalité d'une restauration complète depuis une copie hors site peut être de un à trois jours.
• Le RPO (Recovery Point Objective) est la quantité de données que l'on accepte de perdre, mesurée par l'ancienneté de la dernière sauvegarde exploitable. Une sauvegarde quotidienne signifie jusqu'à vingt-quatre heures de saisies perdues.

Le litige naît presque toujours de l'écart entre le RTO/RPO réel et celui que le client croyait acquis. Cet écart non explicité est un nid à contentieux.

La parade relève du devoir de conseil : mesurez ces deux valeurs en conditions réelles, communiquez-les par écrit, et faites valider au client le niveau qu'il accepte au regard de ce qu'il est prêt à financer. Un client qui a signé un RPO de vingt-quatre heures ne pourra pas vous reprocher la perte d'une demi-journée de données. Un client à qui personne n'a jamais expliqué la notion se retournera contre vous au premier incident.

Voici les pratiques qui font la différence entre une sauvegarde qui rassure et une sauvegarde qui sauve réellement. Elles relèvent autant de la bonne pratique technique que de votre protection juridique.

1. Testez les restaurations à intervalles réguliers, en conditions réelles, sur un environnement de bac à sable. Une restauration jamais essayée est une hypothèse, pas une garantie.
2. Mesurez et documentez le temps de restauration réel (RTO) et la fraîcheur des données récupérables (RPO). Comparez-les aux attentes du client : l'écart est souvent une surprise.
3. Appliquez la règle 3-2-1 avec une copie isolée du réseau, hors d'atteinte d'un ransomware ayant compromis le domaine.
4. Surveillez le contenu des jobs, pas seulement leur statut. Un voyant vert ne garantit pas que les bonnes données sont incluses.
5. Consignez par écrit chaque test et chaque recommandation faite au client, notamment ses refus de budget. Ces traces protègent votre responsabilité au titre du devoir de conseil.

Une sauvegarde testée et documentée n'est plus une promesse en l'air : c'est une garantie démontrable, technique comme juridique. Et c'est exactement ce que vous voudrez pouvoir prouver le jour où la restauration sera la seule chose qui compte.