É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.