Quand une application s’est arrêtée net, et remise en route en minutes

Un des services utilisés au quotidien s’est arrêté sans prévenir. Pas de panne réseau, pas de coupure de courant : juste une application qui refusait de démarrer, avec des erreurs incompréhensibles à l’écran. En creusant, on a trouvé la cause : des fichiers applicatifs avaient été modifiés ou supprimés, rendant le service inutilisable.

Ce genre d’incident passe souvent sous le radar jusqu’au moment où il arrive. Cet article raconte comment on l’a résolu en quelques minutes et ce que cette situation révèle sur la différence entre “avoir des sauvegardes” et pouvoir se remettre debout rapidement.

La situation de départ

L’infrastructure héberge une dizaine de services applicatifs (messagerie, partage de fichiers, synchronisation de données, outils métiers) qui tournent en continu sur un serveur dédié. Ces services s’appuient chacun sur un ensemble de fichiers persistants : configurations, bases de données, fichiers téléversés, préférences. C’est là que vit la donnée utile.

Un matin, l’un de ces services ne répond plus. L’interface affiche une erreur, le service refuse de redémarrer normalement. Les journaux du serveur pointent vers des fichiers manquants ou incohérents dans les données persistantes du service. La cause identifiée : une manipulation avait altéré des fichiers dont le service a besoin pour fonctionner. Ce type de situation peut venir d’une fausse manœuvre, d’un script mal configuré ou d’une mise à jour qui écrase des fichiers sans prévenir.

Ce qu’on a fait : retour à un état sain

La décision a été simple : restaurer les données persistantes du service à partir de la sauvegarde la plus récente, datant de moins d’une demi-heure. Ces captures automatiques des données applicatives sont prises toutes les 30 minutes et stockées sur un volume de stockage séparé du serveur de production. Une panne ou une corruption sur le serveur principal ne les touche donc pas.

La restauration a pris quelques minutes. Le service a redémarré normalement. La perte de données effective était inférieure à 30 minutes d’activité, ce qui représente un impact très limité sur ce type de service.

Sans cette sauvegarde en place, l’incident aurait nécessité une reconstruction manuelle du service : plusieurs heures de travail, avec une perte de données impossible à quantifier.

Ce que cet incident révèle : les couches de résilience

Résoudre l’incident rapidement n’était pas une question de chance. C’était le résultat d’une infrastructure pensée autour d’une question simple : que se passe-t-il si chaque composant tombe, et combien de temps pour se remettre debout ?

Voici les scénarios couverts, et comment chacun est traité.

Des fichiers applicatifs supprimés ou corrompus

C’est exactement ce qui s’est passé. Les données persistantes des services applicatifs sont sauvegardées toutes les 30 minutes sur un volume de stockage distinct. Trois versions sont conservées en parallèle. Retour à un état sain en quelques minutes, avec une perte de données maximale de 30 minutes.

Une mise à jour qui casse un service

Même logique. Si une mise à jour introduit un comportement anormal ou détruit des données, on peut revenir à l’état précédant la mise à jour. La sauvegarde existait avant la mise à jour, elle est disponible immédiatement. Cela rend les mises à jour moins risquées : en cas de problème, on revient en arrière.

Une panne sur un disque du serveur

Les disques du serveur principal sont organisés en redondance active : si un disque tombe en panne, le système continue de fonctionner sans interruption et le disque défaillant peut être remplacé sans arrêt de service. Par ailleurs, les sauvegardes sont stockées sur un second groupe de disques, lui aussi en redondance. Une panne sur le stockage principal n’efface pas les sauvegardes.

Une perte totale du serveur

Les sauvegardes complètes des environnements d’exécution sont effectuées quotidiennement, avec une rétention de 3 jours. En cas de destruction totale du serveur (incendie, vol, défaillance matérielle grave), il est possible de reconstruire l’ensemble de l’infrastructure sur un nouveau serveur à partir de ces sauvegardes. La perte de données se limite alors à la dernière sauvegarde quotidienne.

Perte ou destruction du poste de travail

L’ordinateur portable est couvert sur deux angles. Ses données système sont sauvegardées toutes les heures via un service hébergé localement sur le serveur. Ses données utilisateurs (photos, musique, vidéos, documents) sont synchronisées en temps réel vers le serveur via deux services distincts selon les types de fichiers. En cas de perte, vol ou destruction, les données sont récupérables depuis le serveur et un nouvel ordinateur peut être opérationnel en quelques heures.

Un ransomware ou une suppression massive accidentelle

Ce scénario est le plus complexe à couvrir. Si un logiciel malveillant chiffre ou détruit les données, la synchronisation en temps réel peut propager les dégâts vers le serveur. La protection repose ici sur les captures versionnées des données applicatives : un ransomware qui chiffre les données en cours de soirée n’efface pas les captures de l’après-midi. Les sauvegardes sont par ailleurs chiffrées et stockées séparément du stockage de production.

Le maillon manquant à ce jour est une copie hors site. Si le serveur est physiquement détruit ou volé, sauvegardes comprises, la récupération complète devient impossible. Ce point est identifié et en cours de traitement via une solution de stockage cloud chiffrée.

Ce que ça change concrètement

Sur ce cas précis : quelques minutes d’indisponibilité, moins de 30 minutes de données exposées, zéro reconstruction manuelle. Sans la sauvegarde fréquente des données applicatives, l’incident aurait coûté plusieurs heures de travail technique et potentiellement des données définitivement perdues.

Ce qui compte n’est pas la technologie utilisée mais le raisonnement qui la précède : identifier les types de pannes possibles, estimer leur impact, et couvrir chacun avec un mécanisme adapté. Beaucoup de petites structures ont des sauvegardes, mais elles sauvegardent souvent le mauvais endroit, pas assez fréquemment, ou sans jamais tester la restauration.

Le tableau ci-dessous résume la couverture actuelle :

Une architecture de résilience n’est jamais parfaite dès le départ. Ce qui compte, c’est d’en avoir une et de savoir où sont les trous. La question utile n’est pas “est-ce que j’ai des sauvegardes ?” mais “si un service tombe ce soir, est-ce que je peux le remettre en route demain matin sans perte majeure, sans avoir besoin d’un expert disponible d’urgence ?”

Si cette question reste sans réponse claire, c’est un point de départ concret pour structurer votre stratégie de sauvegarde.