Serveur en panne : la sauvegarde permet-elle de tout récupérer ?

Le scénario en bref

Exemple, inventé pour illustrer. Un lundi à 7 h 40, dans un cabinet dentaire fictif. Le serveur qui fait tourner le logiciel de radiologie est une machine virtuelle (un ordinateur « logiciel » hébergé sur un serveur physique). Pendant le week-end, une mise à jour Windows s'est installée. Ce matin, la machine ne démarre plus : elle affiche l'écran de récupération de Windows avec un code d'erreur.

Ce code correspond, dans la documentation de Microsoft, à un fichier corrompu et illisible. Les postes du cabinet n'affichent plus les radios. La dernière sauvegarde complète date de la semaine précédente.

Voici, étape par étape, ce qu'un technicien fait dans ce cas, pourquoi, et le piège à éviter à chaque fois. Les durées données sont des ordres de grandeur pour cet exemple, pas des mesures.

Étape 1 : avant de toucher à quoi que ce soit, copier le disque

Ce qu'on fait. On éteint la machine virtuelle (elle est bloquée sur l'écran de récupération), puis on copie son disque (un gros fichier qui contient toute la machine) vers un autre emplacement, ou on crée un point de contrôle (une photo de l'état du disque, qui permet d'y revenir).

Pourquoi. Ce disque en panne contient la seule copie de tout ce qui a été fait depuis la dernière sauvegarde : les radios de la semaine, les rendez-vous, les notes. Toute réparation écrit sur le disque. Si elle tourne mal, ces données peuvent être perdues pour de bon.

Le piège. Lancer tout de suite un outil de réparation « pour gagner du temps ». Microsoft le rappelle d'ailleurs : un point de contrôle n'est pas une sauvegarde complète. Il sert ici de filet pour revenir en arrière, la vraie copie de sécurité reste la copie du fichier.

Étape 2 : tenter de réparer Windows sur place

Ce qu'on fait. On démarre la machine dans le mode de récupération de Windows (il s'ouvre tout seul après deux démarrages ratés). De là, on lance les outils de réparation intégrés à Windows, sans démarrer Windows lui-même : ils contrôlent les fichiers du système et remplacent ceux qui sont abîmés, à partir d'une copie saine de Windows.

Pourquoi. Si la réparation réussit, le cabinet repart avec ses données du jour, sans rien restaurer. C'est la voie la plus rapide quand elle marche.

Dans notre exemple, elle échoue : Windows ne démarre toujours pas. On revient alors proprement à l'état d'avant la tentative (le point de contrôle ou la copie de l'étape 1), pour ne pas laisser un disque à moitié modifié.

Le piège. Enchaîner les tentatives pendant des heures pendant que le cabinet attend. Il faut se fixer une limite de temps, puis passer au plan B : la restauration.

Étape 3 : restaurer la machine depuis la sauvegarde, à côté de l'originale

Ce qu'on fait. On restaure la machine virtuelle de la semaine précédente depuis la copie hors site (stockée hors du cabinet). On la restaure sous un autre nom, à côté de la machine en panne, jamais par-dessus.

Pourquoi à côté. La machine en panne contient encore les données récentes (étape 4). Si on écrase son disque avec la sauvegarde, elles disparaissent. On ne supprime l'ancienne machine qu'à la toute fin, une fois tout vérifié.

Ce qui prend du temps :

• La taille du disque. Toute la machine doit être recopiée, pas seulement les fichiers utiles.
• Le débit. Une copie hors site arrive par la connexion internet du cabinet ou du centre de données ; une copie sur place, par le réseau local, va beaucoup plus vite.
• La vérification. On contrôle que la machine restaurée démarre et que ses fichiers sont lisibles avant de la remettre en service.

Dans cet exemple, pour une machine de l'ordre de 150 Go restaurée depuis une copie hors site, comptez plusieurs heures. C'est un ordre de grandeur hypothétique : la durée réelle dépend de la taille, de la connexion et de l'outil de sauvegarde. La seule façon de la connaître pour votre cabinet est de l'avoir mesurée lors d'une restauration d'essai.

Le piège. Découvrir le jour de la panne que la restauration prend une journée, ou que la sauvegarde « réussie » ne se restaure pas. Une sauvegarde qu'on n'a jamais restaurée n'est pas une preuve. L'ANSSI le dit sans détour dans son guide sur la sauvegarde : les sauvegardes doivent être testées régulièrement, et une procédure de restauration doit être rédigée et régulièrement mise en œuvre.

Étape 4 : rattraper ce qui a été créé depuis la dernière sauvegarde

Ce qu'on fait. La machine restaurée date de la semaine passée. Il lui manque tout ce qui a été fait depuis. Sur le serveur physique, on ouvre l'ancien disque en lecture seule et on y récupère les fichiers récents : base de données du logiciel, radios, documents.

Pourquoi en lecture seule. Rien ne peut alors modifier l'ancien disque pendant la copie. Si on se trompe, il reste intact et on peut recommencer.

La copie « à froid ». Une base de données ne se copie pas comme un simple fichier pendant qu'elle travaille. Sur la machine restaurée, on arrête le service de la base de données avant de remplacer ses fichiers par les versions récentes, puis on le redémarre. Copier une base ouverte donne une copie incohérente, qui peut refuser de s'ouvrir ou perdre des enregistrements. Pour un logiciel métier, on suit la procédure de son éditeur, et on le fait vérifier par lui si nécessaire.

Le piège. Croire que la sauvegarde contient tout. Elle ne contient que ce qui existait au moment où elle a été faite. Sans cette étape, une semaine de radios manquerait.

Étape 5 : vérifier que Windows est sain, puis tester avec l'équipe

Ce qu'on fait. Sur la machine restaurée, désormais démarrée, on lance les outils de réparation intégrés à Windows et on lit leur rapport pour voir ce qui a été trouvé ou corrigé.

Puis le contrôle qui compte : avec une personne du cabinet, on ouvre une radio prise ce matin ou la semaine dernière, on vérifie qu'elle s'affiche sur les postes et que les derniers rendez-vous sont là. Une machine qui démarre ne prouve pas que les données sont complètes.

Le piège. Remettre tout de suite la même mise à jour sur la machine restaurée. On la diffère le temps de comprendre ce qui a abîmé le disque, et on garde la machine en panne jusqu'à ce que tout soit validé.

Que faire quand un serveur Windows ne démarre plus après une mise à jour ?

D'abord copier le disque avant toute réparation. Ensuite tenter une réparation depuis le mode de récupération de Windows, avec ses outils intégrés. Si elle échoue, restaurer la dernière sauvegarde à côté de la machine en panne, puis récupérer les données récentes sur l'ancien disque (détail aux étapes 1 à 5 ci-dessus).

Combien de temps prend une restauration complète d'un serveur ?

Des heures, rarement des minutes. Le temps dépend de la quantité de données, de l'endroit d'où on restaure (sur place ou hors site), du débit de la connexion et du temps de vérification. Ajoutez le rattrapage des données récentes et les tests avec l'équipe. Le bon chiffre est celui que vous avez mesuré lors d'une restauration d'essai : c'est lui qui dit combien de temps votre cabinet peut rester sans son logiciel.

Les données créées depuis la dernière sauvegarde sont-elles perdues ?

Pas forcément, mais elles ne sont pas dans la sauvegarde. Si le disque d'origine est encore lisible (une panne de Windows, pas un disque détruit), on peut souvent les récupérer dessus, comme à l'étape 4. Si le disque est détruit, chiffré par une attaque ou volé, ce qui a été fait depuis la dernière sauvegarde est perdu. Plus les sauvegardes sont fréquentes, plus cette perte possible est courte.

Et si ce n'est pas une panne, mais une attaque ?

Si l'écran affiche une demande de rançon ou si les fichiers ont été chiffrés, la marche à suivre change. La fiche réflexe « rançongiciels » de cybermalveillance.gouv.fr demande notamment de :

• débrancher les sauvegardes du réseau si elles y sont connectées, pour qu'elles ne soient pas chiffrées à leur tour ;
• ne pas payer la rançon ;
• conserver les preuves (journaux, copies ou disques des machines touchées) et porter plainte avant de réinstaller ;
• notifier l'incident à la CNIL dans les 72 heures si des données personnelles ont pu être consultées, modifiées ou détruites ;
• réinstaller les systèmes touchés, puis restaurer depuis une sauvegarde antérieure à l'attaque et réputée saine.

C'est là que la copie déconnectée (hors ligne) fait toute la différence : une sauvegarde qui reste branchée en permanence au réseau du cabinet peut être chiffrée en même temps que le serveur.

Sauvegarde, RAID, réplication : quelle différence ?

Seule la sauvegarde permet de revenir à hier ou à la semaine passée. RAID et réplication aident à rester en marche, ils ne remplacent pas la sauvegarde.

Perte de données admissible et durée d'arrêt admissible, en clair

L'ANSSI parle de PDMA et de DMIA ; les prestataires disent souvent RPO et RTO. Ce sont les mêmes notions :

• Perte de données maximale admissible (PDMA, ou RPO) : jusqu'à quel moment dans le passé on doit pouvoir revenir. Une sauvegarde par nuit veut dire qu'on accepte de perdre, au pire, une journée de travail. Dans l'exemple, la dernière sauvegarde complète datait d'une semaine : c'est une semaine de travail qu'il a fallu rattraper à l'étape 4.
• Durée maximale d'interruption admissible (DMIA, ou RTO) : combien de temps le cabinet peut rester sans son système avant que cela devienne un vrai problème pour les patients et l'activité.

Ces deux chiffres se décident avant la panne, avec votre prestataire. Ils disent à quelle fréquence sauvegarder et quelle copie doit être rapide à restaurer.

Ce que la réglementation française ajoute pour un cabinet de santé

• La copie hors du cabinet doit être chez un hébergeur certifié HDS. Le Code de la santé publique (article L.1111-8) impose de confier l'hébergement de données de santé à un hébergeur certifié, et l'article R.1111-9 range explicitement « la sauvegarde des données de santé » parmi les activités d'hébergement. Une sauvegarde externalisée de vos dossiers patients chez un prestataire relève donc de cette obligation. Demandez le certificat HDS de votre prestataire de sauvegarde.
• Une perte de données patients peut être une violation de données au sens du RGPD. Pour la CNIL, un incident qui compromet la disponibilité de données personnelles en est une, par exemple la suppression de données médicales qui n'étaient pas sauvegardées ailleurs. Toute violation doit être inscrite dans un registre interne ; si elle présente un risque pour les personnes, elle doit être notifiée à la CNIL au plus tard 72 heures après en avoir pris connaissance.
• Dans notre exemple, rien n'a été perdu : les données ont été restaurées et rattrapées. Si la restauration avait échoué, ou en cas d'attaque, la question de la notification se serait posée. Votre délégué à la protection des données ou votre conseil peut vous aider à trancher.

Ce que cet exemple apprend

• Deux copies indépendantes, dont une déconnectée. Une sur place, pour restaurer vite. Une hors du cabinet, pour l'incendie, le vol ou l'attaque. C'est la règle dite 3-2-1, que l'ANSSI recommande : trois copies distinctes des données (les données en service et deux sauvegardes), sur des supports différents, dont une hors ligne.
• Une sauvegarde « réussie » ne prouve pas qu'on peut restaurer. Seule une restauration d'essai le prouve.
• Une restauration réelle prend des heures. Mieux vaut le savoir avant la panne.
• Il faut un plan pour les données récentes. Ce qui a été fait depuis la dernière sauvegarde se rattrape sur l'ancien disque, quand il est encore lisible, et jamais par-dessus.

Vérifier votre propre sauvegarde en 6 questions

1. Qu'est-ce qui est sauvegardé exactement, et le serveur entier (pas seulement des dossiers) en fait-il partie ?
2. Y a-t-il une copie sur place et une copie hors du cabinet, dont une qui n'est pas branchée en permanence au réseau ?
3. À quelle fréquence ? Combien de travail perdriez-vous au pire ?
4. Quand a eu lieu la dernière restauration d'essai, et combien de temps a-t-elle pris ?
5. Si la copie externe contient des données patients, l'hébergeur est-il certifié HDS ?
6. Qui fait quoi le jour de la panne, y compris pour récupérer les données récentes et, si besoin, prévenir la CNIL ?

Pour aller plus loin sur ce qu'il faut sauvegarder dans un cabinet, lisez notre article sauvegarder les données de vos patients.

Ce que DeepIT fait

Chez les cabinets dont nous gérons l'informatique, nous mettons en place une sauvegarde hors site, suivie par notre équipe, dans le cadre de la gestion informatique externalisée. Nous vous aidons à faire la liste de ce qui doit être sauvegardé et à préparer ce qui se passe le jour d'une panne. À Marseille et dans les Bouches-du-Rhône (Aix-en-Provence, Aubagne, La Ciotat…), nous intervenons d'abord à distance, et sur place quand il le faut. Voir aussi nos pages cabinets dentaires et informatique médicale.

Faire le point sur vos sauvegardes→