Accueil›Guides›Que faire si…

Que faire si…

Mon serveur est tombé : que faire ?

On traite un serveur tombé dans cet ordre : comprendre la panne, savoir si les données sont encore lisibles, choisir le dernier point de restauration sain, restaurer, puis seulement décider si ce serveur aurait dû avoir un secours déjà prêt. Restaurer avant d’avoir identifié le point sain, c’est parfois écraser la seule copie encore bonne.

Mis à jour en octobre 20263 min de lecture5 sources citées

L’essentiel

  • Notez l’heure et le symptôme avant de toucher à quoi que ce soit : ce sera votre point de départ pour choisir la bonne copie.
  • Plusieurs machines touchées ou des fichiers renommés en masse : c’est une attaque, pas une panne. Isolez et suivez la fiche ransomware.
  • Ne relancez pas en boucle un serveur dont les disques font du bruit : chaque démarrage peut achever un disque mourant.
  • Restaurez à partir du dernier job réussi et antérieur à l’incident, après avoir ouvert un fichier test de ce point.
  • Chronométrez la remise en service : c’est votre RTO réel.

1. Diagnostiquer, sans tout éteindre au hasard

Notez l’heure et le symptôme : plus aucun réseau, écran bleu, disques qui claquent, application qui refuse d’ouvrir, message de chiffrement.

  • Alimentation, switch, câble. Un serveur « tombé » est parfois un lien mort. Les autres machines répondent-elles ? Le NAS répond-il ?
  • Un seul service. La machine démarre, l’application non. Ce n’est pas le même délai ni la même restauration qu’un disque mort.
  • Plusieurs machines à la fois, ou des fichiers renommés en masse. Traitez cela comme une attaque, pas comme une panne matérielle : coupez l’accès Internet du réseau touché, débranchez les machines atteintes sans les éteindre et passez à Un ransomware vient de se déclencher. Ne restaurez pas sur le réseau en feu.

Si le serveur physique sent le brûlé ou que les disques sont inaudibles et que vous n’avez pas de copie, arrêtez de le rallumer en boucle : chaque démarrage peut aggraver un disque mourant. La copie de sauvegarde devient prioritaire.

2. Déterminer si les données sont intactes

Trois situations :

  • Le système est mort, les disques de données répondent encore depuis un autre branchement ou un live CD. On peut copier d’urgence vers un disque sain, puis restaurer proprement. Cette copie d’urgence n’est pas une raison de sauter la sauvegarde hors site : elle peut être incomplète.
  • Les fichiers sont là et s’ouvrent. Panne logicielle ou matérielle partielle. Une réparation peut suffire. On sauvegarde l’état actuel avant de tenter des réparations destructrices, si cet état est encore sain.
  • Les fichiers sont illisibles, absents ou chiffrés. La production n’est plus une source. Seule une sauvegarde antérieure l’est.

3. Identifier le dernier point de restauration

Dans la console de sauvegarde, prenez le dernier job réussi, et vérifiez qu’il est antérieur à l’incident. Si la panne est une corruption découverte aujourd’hui mais commencée il y a une semaine, le job d’hier est un mauvais candidat. Ouvrez un fichier de test de ce point avant de lancer la restauration complète.

Repérez où est la clé de chiffrement. Sans elle, le point existe et reste illisible.

4. Restaurer

  • Fichiers seuls si le système est sain et qu’il ne manque qu’un dossier.
  • Serveur entier si le système est mort : image vers un matériel équivalent ou vers une machine virtuelle. C’est plus rapide qu’une réinstallation à la main, à condition que l’image ait été testée au moins une fois dans l’année.
  • Ne restaurez pas par-dessus un disque qui contient peut-être la seule donnée récente non sauvegardée, tant que ce doute n’est pas levé.

Si plusieurs serveurs sont à relancer, respectez l’ordre des dépendances : annuaire et réseau d’abord, puis bases de données, puis applications, puis postes. L’ANSSI recommande de définir cet ordre de restauration à l’avance, en tenant compte des dépendances et de la criticité des applications.

Chronométrez. Ce chiffre est votre RTO réel.

5. Envisager un PRA si le serveur est critique

Si l’arrêt a déjà coûté trop cher, ou s’il n’y a pas de matériel de remplacement, le PRA sert à redémarrer maintenant sur une instance de secours, à partir du point choisi, le temps de réparer le matériel. Si ce serveur retombe souvent, ou si la direction n’accepte plus ce délai, il doit entrer dans le PRA ou le PCA après l’incident, par écrit, pas seulement dans la conversation du soir.

Le mode dégradé (papier, autre outil) se déclenche en parallèle des étapes 3 et 4, pas après.

Après l’incident : le compte rendu

Dans la semaine, notez ce qui a pris plus de temps que prévu, ce qui manquait (mot de passe, clé, contact, matériel) et ce qui change dans le plan. Si la cause est une attaque, conservez les traces et les journaux : un dépôt de plainte doit intervenir avant la réinstallation des machines, et une violation de données personnelles se notifie à la CNIL dans les 72 heures.

Chez WeDoBack

WeDoBack peut restaurer le serveur complet, avec le système, les logiciels et les paramètres, ou seulement les fichiers. Les copies sont hors du serveur en panne, chiffrées, clé chez le client. Avec le PRA, les serveurs redémarrent sur des instances de secours à partir de la version choisie, sans attendre l’achat d’une machine ; l’activation est facturée à la journée. L’assistance se joint au 09 72 50 78 28, de 9 h à 13 h et de 14 h à 17 h 30 (heure de Paris). En dehors de ces horaires, la surveillance peut avoir alerté, mais le geste de restauration assistée attend l’ouverture, sauf organisation contraire prévue au contrat.

Appeler le 09 72 50 78 28Découvrir le PRA

Questions fréquentes

Dois-je éteindre le serveur ?

Pour une panne matérielle avérée (odeur de brûlé, disques qui claquent), oui : arrêtez de le relancer. En cas de doute sur une attaque, isolez-le du réseau plutôt que de l’éteindre : la mémoire peut contenir des éléments utiles à l’enquête, comme le rappelle Cybermalveillance.gouv.fr.

Combien de temps faut-il pour restaurer un serveur ?

Cela dépend du volume, du débit, de la méthode (fichiers ou image complète) et de la disponibilité d’un matériel de remplacement. Sans image système testée, comptez souvent d’une demi-journée à deux jours pour un serveur physique. Un PRA permet de redémarrer sur une instance de secours sans attendre le matériel.

Faut-il prévenir quelqu’un d’autre que le prestataire informatique ?

Si la panne est due à une attaque et que des données personnelles sont touchées, la violation doit être notifiée à la CNIL dans les 72 heures (RGPD, article 33). Prévenez aussi votre assureur s’il couvre le risque cyber, et déposez plainte avant de réinstaller les machines.

Pour aller plus loin

Sauvegarde informatiqueQuelle sauvegarde pour un serveur physique ?PRA et PCAQu’est-ce qu’un PRA ?PRA et PCAComment déterminer son RTO ?Que faire si…La sauvegarde de cette nuit a échoué

Sources

Documents consultés en octobre 2026.

  1. Rançongiciel ou ransomware : que faire si votre organisation est victime d’une attaque ? — Cybermalveillance.gouv.fr
  2. Sauvegarde des systèmes d’information – Les fondamentaux (ANSSI-BP-100, v1.1, 27 novembre 2025) — ANSSI
  3. Violations de données personnelles : les règles à suivre — CNIL
  4. SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems — NIST
  5. Offre PRA (Plan de Reprise d’Activité) — WeDoBack

Besoin d’aide maintenant ?

Ne restaurez rien avant d’avoir identifié une copie saine. Nous pouvons vous guider.

Appeler le 09 72 50 78 28ou nous écrire

Un incident en cours ?

Nos équipes vous aident à identifier la bonne copie et à restaurer, du lundi au vendredi de 9 h à 13 h et de 14 h à 17 h 30.

Appeler le 09 72 50 78 28Écrire à l’équipe