Étude de cas sur la récupération de sauvegarde : retour 6 heures en arrière

Publié le 10 juillet 2026

À 02:14 UTC, la vitrine a cessé d’écrire les commandes dans la base de données. À 02:19, le site servait encore des pages en cache, mais le passage en caisse relevait déjà de la fiction. Cette étude de cas sur la récupération de sauvegarde décrit ce qui s’est passé ensuite sur un VPS de production pour une petite entreprise d’e-commerce, ce que nous avons restauré, ce que nous n’avons pas restauré aveuglément, et pourquoi le service était de nouveau stable avant l’aube.

Le client utilisait une pile assez standard pour une boutique en ligne en croissance : Nginx, PHP-FPM, MariaDB, Redis, et un panneau de contrôle utilisé par deux employés non administrateurs système. Le trafic n’était pas énorme, mais le timing était douloureux. Une campagne promotionnelle avait fait grimper le volume de commandes, les écritures en base de données atteignaient un pic, et un problème de stockage au niveau du système de fichiers a commencé à corrompre les tables actives de la base de données. Rien de dramatique au sens hollywoodien du terme, mais suffisamment sérieux pour que chaque minute compte.

La première tâche n’était pas la restauration. La première tâche consistait à empêcher la propagation des dégâts. Nous avons placé l’application en mode maintenance, préservé l’état actuel du disque pour analyse, et vérifié si la réplication, les snapshots ou les dumps logiques nous donnaient le point de récupération le plus propre. C’est plus important qu’on ne veut bien l’admettre. Une récupération rapide, c’est bien. Une récupération rapide vers des données endommagées, c’est juste une déception plus rapide.

Ce qui a échoué et comment nous l’avons su

Les journaux racontaient désormais la même histoire. MariaDB a commencé à signaler des erreurs de somme de contrôle de pages InnoDB, suivies de crashs de tables sur les tables de commandes et de sessions fortement sollicitées en écriture. L’hyperviseur lui-même était sain. Le comportement du CPU, de la RAM et du réseau est resté normal. Cela a permis d’écarter une panne générale de la plateforme et d’orienter l’événement vers l’intégrité du stockage au niveau de l’instance invitée.

Nous avons vérifié trois choses avant de toucher aux sauvegardes. D’abord, si le problème était isolé à un petit ensemble de tables et pouvait être réparé sur place. Ensuite, si les sauvegardes récentes étaient valides et pouvaient être montées. Enfin, si des transactions terminées après la dernière sauvegarde connue comme saine pouvaient être reconstruites à partir des journaux de l’application, des confirmations par e-mail ou des enregistrements de la passerelle de paiement.

Cette troisième vérification est souvent ignorée. Elle ne devrait pas l’être. Restaurer une sauvegarde ne constitue pas à elle seule toute la récupération. Les entreprises se soucient des commandes manquantes, des dossiers clients et de l’état des factures, pas seulement du fait que MySQL redémarre.

Le parcours de récupération que nous avons choisi

Cette étude de cas sur la récupération de sauvegarde est utile parce que l’option évidente n’était pas la meilleure. Nous avions trois options candidates.

Un rollback complet de snapshot VM aurait été le plus rapide en nombre de clics, mais il aurait aussi supprimé plusieurs heures de modifications légitimes du contenu, de mises à jour de plugins et de modifications de comptes clients. Réparer les tables sur place comportait trop de risques, car la corruption avait déjà touché des données transactionnelles essentielles. La meilleure voie était une restauration au niveau des fichiers et de la base de données dans une instance fraîche, suivie d’un rapprochement sélectif des données.

Nous avons donc d’abord provisionné un environnement de récupération propre. Même taille de VPS, même famille d’OS, même version du panneau, même branche PHP. Reconstruire dans une instance parallèle donne une marge de manœuvre. Cela protège aussi le système d’origine pour l’analyse forensique, ce qui est utile si le client doit comprendre la cause racine ou vérifier que le problème n’a pas été causé par le comportement de l’application.

Nous avons récupéré la dernière sauvegarde automatique réussie de 23:00 UTC. Puis nous l’avons testée avant le basculement. Cela semble basique, mais de nombreuses équipes ne découvrent les problèmes de sauvegarde qu’à la pire heure possible. L’archive s’est montée correctement, les sommes de contrôle correspondaient, l’import de la base de données s’est terminé sans erreur, et l’application a démarré en isolation. Bien. Le calme commence là.

Restaurer le service sans créer de nouveaux problèmes

La récupération s’est déroulée en quatre étapes. D’abord, l’infrastructure. Nous avons reconstruit la pile web, appliqué les mises à jour système déjà approuvées, et aligné les versions d’exécution afin que l’application n’échoue pas à cause d’un décalage inattendu de dépendances.

Ensuite, les données. La restauration de la base de données s’est terminée en 11 minutes. Les fichiers web ont été restaurés en moins de 4 minutes. Les ressources média étaient intactes, ce qui a évité au client des images de produits cassées et des cadres de navigateur furieux. Redis n’a pas été restauré depuis la sauvegarde, car les données en cache sont jetables par conception. Réinjecter un cache obsolète dans un environnement neuf fait partie de ces petites erreurs qui créent un gros désordre plus tard.

Troisièmement, la validation. Nous avons vérifié la connexion à l’application, le parcours de paiement, les écritures d’administration, l’exécution du cron, la validité SSL, le courrier sortant et le comportement des callbacks de la passerelle de paiement. Nous avons aussi comparé les nombres d’enregistrements des tables de commandes, de clients et de catalogue aux courbes de croissance attendues de la semaine précédente. Les chiffres n’ont pas besoin d’être une poésie parfaite, mais ils ne doivent pas sembler étranges.

Quatrièmement, le rapprochement. Entre 23:00 UTC et 02:14 UTC, une poignée de paiements réussis avaient été traités. Ces enregistrements n’existaient pas dans la base de données restaurée, car ils étaient intervenus après le point de sauvegarde. Nous les avons reconstruits à partir des confirmations du fournisseur de paiement, des notifications de commande par e-mail et des journaux d’accès web. C’est là qu’un opérateur expérimenté évite beaucoup de douleur métier. Une restauration techniquement réussie qui perd des commandes payées n’est pas vraiment une réussite.

À 03:41 UTC, l’application était disponible pour une revue interne du client. À 04:06 UTC, le DNS et le routage edge ont redirigé le trafic de production vers l’instance récupérée. La perturbation totale du passage en caisse côté client a été d’un peu moins de deux heures, tandis que l’accès en lecture à la majeure partie du site est resté disponible pendant une grande partie de l’incident.

Ce qui a rendu la récupération rapide

Ce n’était pas de la chance, ni un bouton magique de sauvegarde. La rapidité est venue de la préparation et de la réduction du nombre de décisions à prendre pendant l’incident.

Le client disposait déjà de sauvegardes planifiées automatiques avec rétention, d’un comportement du serveur surveillé, et d’un parcours de support qui ne disparaissait pas dans le silence des tickets. Cela a changé la tournure de la nuit. Nous ne débattions pas de l’existence d’une sauvegarde. Nous choisissions le point de restauration le plus sûr et le validions.

La cohérence de l’environnement a aussi compté. Comme la pile d’hébergement était standardisée, nous n’avons pas passé 45 minutes angoissantes à découvrir que l’application restaurée exigeait une ancienne extension PHP ou une bibliothèque système manquante. Les gens sous-estiment souvent le temps de récupération brûlé par la dérive de configuration.

Il y a aussi eu un gain moins visible : séparer ce qui a un état de ce qui est jetable. Le contenu de la base de données, les médias téléversés, la configuration et les ressources SSL ont été traités avec soin. Le cache, les fichiers temporaires et les sessions générées ont été reconstruits proprement. Cela allège la récupération et évite de transporter un vieux bruit dans un nouveau démarrage.

Ce que cette étude de cas sur la récupération de sauvegarde enseigne

La principale leçon n’est pas simplement de sauvegarder votre serveur. La plupart des entreprises connaissent déjà cette phrase. La leçon la plus difficile est de concevoir la récupération autour de la fonction métier, pas seulement autour des objets d’infrastructure.

Un snapshot VM est utile, mais il peut être trop grossier. Un dump de base de données est utile, mais insuffisant si les fichiers téléversés sont séparés. Une sauvegarde du panneau de contrôle est pratique, mais cette praticité doit quand même être testée. La bonne stratégie de sauvegarde dépend du comportement de l’application, de la fréquence des changements de données, et du niveau de perte réellement acceptable.

Pour un site d’e-commerce, les images de produits peuvent généralement tolérer des points de récupération légèrement plus anciens que les enregistrements de commandes. Pour une application SaaS, l’état de la base de données client peut compter davantage que le contenu du système de fichiers local. Pour une agence digitale hébergeant plusieurs sites clients sur un même serveur, l’isolation devient critique, car un site bruyant ne doit pas transformer la récupération en migraine pour toute la baie.

Les tests méritent aussi davantage de considération. Les sauvegardes sont des promesses jusqu’à ce qu’elles soient restaurées. Après leur restauration, elles deviennent des preuves. La différence coûte cher.

Ce qui a changé après l’incident

Nous n’avons pas traité la récupération comme une ligne d’arrivée. Après la stabilisation du service, nous avons examiné le comportement du stockage, la santé du système de fichiers, les vérifications d’intégrité de la base de données et le calendrier de la politique de sauvegarde. La cause technique immédiate pointait vers une incohérence du disque au niveau de l’instance invitée sous pression d’écriture, mais la question plus large était de savoir comment réduire le rayon d’impact la prochaine fois.

La fréquence des sauvegardes a été ajustée pour le niveau base de données afin de réduire l’exposition au point de récupération pendant les campagnes. Les seuils d’alerte pour l’attente I/O et les schémas d’erreurs de base de données ont été resserrés. Le client est également passé d’une logique de restauration unique à une logique en couches : sauvegardes automatiques, routines de restauration vérifiées, et traitement plus clair du rapprochement transactionnel.

C’est là que le support opérationnel managé prouve sa valeur. Non pas parce que les incidents n’arrivent jamais, mais parce que lorsqu’ils surviennent, quelqu’un sait déjà où regarder en premier et ce qu’il ne faut pas casser en le réparant. Cette petite différence fait souvent toute la différence.

Si vous exécutez des charges de travail génératrices de revenus, la vraie question n’est pas de savoir si vous avez des sauvegardes. La vraie question est de savoir si, à 2 heures du matin, vous pouvez restaurer les bonnes données au bon endroit, les vérifier rapidement, et rendre compte de ce qui s’est passé après la prise de la sauvegarde. Si la réponse est incertaine, le système demande encore de l’attention. Mieux vaut y répondre pendant un après-midi calme qu’au moment d’une panne du passage en caisse.

Andres Saar Ingénieur Customer Care