Exemple de test de reprise après sinistre pour des serveurs
Publié le 31 octobre 2026
Une sauvegarde qui n’a jamais été restaurée ne constitue pas encore un plan de reprise. C’est un fichier plein d’espoir qui se trouve quelque part ailleurs. Cet exemple de test de reprise après sinistre montre comment une petite équipe d’hébergement, une agence ou un propriétaire de serveur peut tester une panne réaliste sans transformer un exercice courant en incident de production.
L’objectif est simple : prouver que vous pouvez restaurer les services réellement utilisés par les personnes, dans un délai acceptable pour votre entreprise. Cela comprend les sites web, les bases de données, les enregistrements DNS, le courrier si celui-ci est hébergé sur le même serveur, ainsi que les accès nécessaires pour tout gérer après la reprise.
Ce qu’un test de reprise après sinistre doit démontrer
Un test utile ne se contente pas de confirmer qu’une tâche de sauvegarde s’est terminée. Il répond à des questions pratiques : pouvez-vous trouver la bonne sauvegarde ? Pouvez-vous la restaurer sur un serveur vierge ? Le site web se charge-t-il correctement ? La base de données est-elle suffisamment à jour ? Un membre autorisé de l’équipe peut-il se connecter et prendre le relais ?
Deux objectifs de reprise sont importants à ce stade. Votre objectif de point de reprise, ou RPO, définit la quantité de données que vous pouvez vous permettre de perdre. Si les sauvegardes sont effectuées chaque nuit, vous risquez de perdre jusqu’à une journée de modifications. Votre objectif de délai de reprise, ou RTO, définit la durée pendant laquelle un service peut être indisponible. Un portfolio personnel peut tolérer plusieurs heures d’indisponibilité. Une boutique en ligne qui prend des commandes ne le peut probablement pas.
Définissez ces objectifs avant l’exercice. Sinon, une restauration peut sembler réussie simplement parce qu’elle a fini par fonctionner, même si elle a pris six heures alors que l’entreprise devait être de nouveau opérationnelle en une heure.
Exemple de test de reprise après sinistre : panne d’un serveur web
Imaginez une agence qui héberge 25 sites web clients sur un seul serveur Linux. Le serveur dispose de sauvegardes complètes quotidiennes, de sauvegardes de la base de données toutes les quatre heures et d’un espace de stockage des sauvegardes situé en dehors du serveur de production. Un lundi matin, une panne de disque rend le serveur indisponible.
Pour le test, ne débranchez pas le serveur de production. Créez une simulation contrôlée sur un serveur de reprise distinct ou une machine virtuelle isolée. Pour le premier exercice, choisissez un site représentatif plutôt que les 25. Choisissez un site doté d’une base de données, de téléversements de médias, de SSL, de tâches planifiées et d’un véritable compte administrateur. Une simple page statique ne permet pas de démontrer grand-chose.
Le scénario de test peut être formulé ainsi :
Incident : le serveur de production est définitivement indisponible à cause d’une panne de disque.
Objectif de reprise : restaurer le site web sélectionné et sa base de données sur un serveur de remplacement en moins de 90 minutes, avec une perte de données maximale de quatre heures.
Critères de réussite : le site web est accessible depuis un nom d’hôte temporaire ou lors d’un test avec le fichier hosts, les pages se chargent en HTTPS, la connexion à l’espace d’administration fonctionne, le contenu récent est présent, les fichiers téléversés s’affichent, les formulaires fonctionnent correctement, les tâches planifiées s’exécutent et les journaux du serveur ne signalent aucune erreur critique de l’application.
Il s’agit d’un test ciblé, mais il met en évidence les éléments qui provoquent habituellement des retards : identifiants manquants, sauvegardes incomplètes, suppositions concernant le DNS, incompatibilités de versions et responsabilités mal définies.
Avant le test, rendez la procédure de reprise accessible
Un test de reprise ne devrait pas dépendre d’une seule personne qui se souvient d’une série de commandes datant de deux ans. Notez où se trouvent les sauvegardes, comment y accéder, qui peut approuver les modifications DNS et quels services doivent être rétablis en premier.
Vérifiez que votre espace de stockage des sauvegardes est distinct du serveur de production. Les sauvegardes stockées uniquement sur le même disque que les sites web sont utiles en cas de suppression accidentelle de fichiers, mais elles ne sont pas d’une grande aide après la perte du serveur. Vérifiez également que les identifiants nécessaires à la reprise sont disponibles sans dépendre du serveur en panne. Cela comprend l’accès à l’espace de stockage des sauvegardes, au bureau d’enregistrement du domaine, au fournisseur DNS, les clés SSH, les détails des licences et tous les secrets d’application requis.
Si vous utilisez un panneau de gestion de serveur, documentez les manipulations à effectuer ainsi que les paramètres techniques. Ce n’est pas un raccourci. C’est un moyen de rendre la reprise reproductible pour la personne disponible au moment de l’incident. FASTPANEL peut vous aider à gérer les sites web, les bases de données, les sauvegardes et les paramètres du serveur depuis un seul endroit, mais le test nécessite toujours des responsabilités clairement définies et des éléments probants.
Effectuez l’exercice dans un ordre sûr
Démarrez un chronomètre lorsque l’équipe reçoit la notification de l’incident simulé. Notez l’heure, la personne qui effectue chaque action et toute décision qui bloque les progrès. Ces notes font partie du résultat du test ; ce ne sont pas de simples formalités administratives.
Commencez par mettre en place l’environnement de reprise. Dans la mesure du possible, utilisez le même système d’exploitation et les mêmes versions des environnements d’exécution requis. Une duplication exacte n’est pas toujours nécessaire, mais modifier simultanément le système d’exploitation, la version de PHP, la version de la base de données et la configuration du serveur web complique le dépannage. Si l’environnement de reprise est différent, consignez cette différence.
Récupérez ensuite la sauvegarde sélectionnée et vérifiez sa date. Restaurez les fichiers du site web et la base de données, puis ajoutez les valeurs de configuration dont l’application a besoin pour s’y connecter. Ne partez pas du principe que les fichiers de configuration contiennent tout. De nombreuses applications dépendent de variables d’environnement, de clés API, de paramètres de messagerie, de tâches cron ou de droits situés en dehors du répertoire du site web.
Mettez le site restauré en ligne à l’aide d’une URL temporaire, d’un domaine de préproduction ou d’une entrée locale dans le fichier hosts. Évitez de faire pointer le DNS public vers le serveur de reprise tant que vous n’avez pas vérifié que le site fonctionne. Vérifiez la page d’accueil, plusieurs pages internes, les images, les formulaires, la connexion aux comptes et l’espace d’administration. Pour un site WordPress, vérifiez également les permaliens, les extensions, les fichiers téléversés et la publication planifiée.
Vérifiez ensuite les services liés au site. Confirmez que le certificat SSL peut être installé ou renouvelé, que l’envoi de courrier est configuré comme prévu, que les tâches planifiées sont présentes et que les utilisateurs de la base de données disposent uniquement des accès nécessaires. Le bon chargement de la page d’accueil est un bon début, pas une fin en soi.
Testez également la décision de basculement
La restauration technique ne représente que la moitié de la reprise après sinistre. L’autre moitié consiste à décider quand et comment le trafic sera redirigé vers le serveur de remplacement.
Pour cet exercice, simulez une modification DNS une fois que le site restauré a passé les vérifications. Mesurez le temps nécessaire pour préparer et communiquer la modification, pas seulement celui que prend la propagation du DNS sur Internet. Des valeurs TTL DNS plus faibles peuvent réduire le délai d’attente, mais elles doivent être définies avant une panne. Modifier le TTL pendant l’incident aide rarement dans l’immédiat, car les résolveurs existants peuvent déjà avoir l’ancienne valeur en cache.
Si votre configuration utilise un répartiteur de charge, un proxy inverse ou un service de basculement cloud, testez ce mécanisme plutôt que le seul DNS. La bonne approche dépend de votre architecture. Pour un serveur unique hébergeant quelques sites d’entreprise, le rétablissement via le DNS peut très bien convenir. Un hébergeur ou une boutique ayant un volume élevé de transactions peut avoir besoin d’un mécanisme de basculement plus rapide et d’un environnement secondaire prêt à être utilisé.
Consignez des résultats exploitables
À la fin de l’exercice, ne vous contentez pas d’écrire « restauration réussie ». Consignez la durée réelle de la reprise, l’ancienneté de la sauvegarde, les vérifications échouées et les étapes manuelles nécessaires. Comparez ces chiffres à vos objectifs RTO et RPO.
Par exemple, l’équipe peut restaurer le site web en 52 minutes, puis découvrir que la dernière sauvegarde de la base de données date de six heures. La reprise du serveur a respecté l’objectif RTO de 90 minutes, tandis que la récupération des données n’a pas respecté l’objectif RPO de quatre heures. Ce résultat reste précieux, car il indique une mesure corrective précise : augmenter la fréquence des sauvegardes de la base de données ou, si nécessaire, ajouter une protection au niveau des transactions.
Parmi les problèmes courants, on trouve une durée de conservation des sauvegardes insuffisante, des identifiants non testés, une sauvegarde excluant les fichiers téléversés, des versions logicielles incompatibles et un accès DNS lié au compte d’un seul employé. Corrigez d’abord le problème présentant le risque le plus élevé, désignez une personne responsable et fixez une échéance. Un test sans suivi n’est qu’une répétition du même problème.
À quelle fréquence faut-il effectuer des tests ?
Pour la plupart des petites entreprises, un test de reprise trimestriel constitue un bon point de départ. Effectuez des tests plus fréquents après des changements importants, comme une migration de serveur, le recours à un nouveau fournisseur de sauvegarde, une mise à niveau de la base de données, une refonte de l’application ou un changement de responsable de l’infrastructure.
Faites varier le périmètre des tests. Un trimestre, restaurez un site web critique et sa base de données. Le trimestre suivant, testez la reconstruction complète d’un serveur. Plus tard, testez une panne d’accès à un compte ou un scénario de suppression accidentelle. Les différents types de panne révèlent des points faibles différents ; il n’est pas nécessaire de semer le chaos à chaque fois pour en tirer des enseignements utiles.
Le meilleur plan de reprise après sinistre est celui que votre équipe peut exécuter sereinement à l’aide des informations dont elle dispose déjà. Planifiez le prochain test avant que celui-ci ne tombe dans l’oubli, puis simplifiez et clarifiez un peu plus la procédure de reprise à chaque fois.