Autopsie : des sauvegardes ont saturé le disque et coupé les sites

Chaque mois, on raconte une intervention réelle du cabinet, du premier symptôme au retour à la normale. Les sites sont anonymisés, les détails techniques ne le sont pas.

Ce mois-ci, un cas qui prend tout le monde à contre-pied : l’outil censé protéger les sites est celui qui les a coupés.

Le 30 juin 2026, à 7 h 15, la supervision a signalé la même erreur sur plusieurs sites hébergés sur un même serveur. Ces sites n’ont ni le même thème, ni les mêmes extensions, ni le même trafic.

C’est ce point commun qui a orienté le diagnostic. Quand des sites sans rapport tombent ensemble, la cause n’est pas dans les sites. Elle est sous eux, dans le serveur qui les héberge.

On a donc laissé les sites de côté pour inspecter la machine.

Deux vérifications ont suffi. Redis tournait, mais son journal montrait qu’il refusait toute écriture, faute de pouvoir enregistrer son instantané sur le disque. Le contrôle suivant a donné la réponse : le disque était plein à 100 %, zéro octet libre sur 387 Go.

Redis est le cache qui garde en mémoire les données souvent demandées, pour que les sites répondent vite. Il est partagé par les sites du serveur. Quand il se met en protection, tous tombent, y compris ceux qui n’y sont pour rien.

Restait à savoir qui avait mangé la place. En classant les dossiers par taille, un coupable écrasait les autres : le répertoire de sauvegardes d’un seul site, la vitrine d’une entreprise industrielle, pesait 101 Go répartis en 606 fichiers.

L’extension de sauvegarde de ce site produisait une copie complète toutes les heures. Chaque copie partait bien vers un stockage distant, ce qui est le geste correct. Mais les copies locales n’étaient jamais purgées, et le stockage distant n’avait aucune durée de conservation : plus de 300 Go s’y étaient entassés en vingt mois.

Le détail qui fait mal : la panne a été déclenchée par la sauvegarde elle-même. Ce matin-là, la copie horaire a tenté de s’écrire, n’a pas trouvé la place, et a consommé les derniers octets disponibles en échouant.

Quatre gestes, dans l’ordre. La purge des archives locales du site en cause a rendu 101 Go au serveur en une vingtaine de minutes, en conservant la copie la plus récente et les journaux. Le disque est repassé de 100 % à 74 %.

1. Libérer le site en cause. Purge des archives locales, copie récente et journaux conservés.
2. Relancer la circulation. Redis réécrit son instantané, on vérifie lecture et écriture, puis chaque site touché un par un.
3. Traiter la cause. Fin de la copie complète horaire : base de données une fois par jour, fichiers une fois par semaine, et une règle de conservation des deux côtés.
4. Purger l’historique distant. Les 300 Go ramenés aux copies récentes et à un jeu mensuel d’archives.

Le troisième geste est le seul qui compte sur la durée. Les trois autres réparent, celui-là empêche la récidive.

Suivre un parc entier donne un avantage sur le dépannage isolé : un site nous apprend quelque chose, tous en profitent. Ce cas a déclenché trois mesures généralisées, appliquées aux sites que l’on maintient.

• Audit de la configuration de sauvegarde de tous les sites. Plusieurs présentaient la même dérive à un stade moins avancé. Quelques-uns, plus inquiétant, avaient des sauvegardes arrêtées sans que personne le sache. Trop de copies ou plus de copies du tout : les deux extrêmes de la même maladie.
• Une alerte automatique dès qu’un disque dépasse 85 %. C’est la leçon d’humilité du dossier. On a découvert cet incident par la panne, pas par la supervision.
• Une chasse aux doublons. Quand un site bénéficie déjà d’une sauvegarde quotidienne externalisée, la copie locale horaire n’ajoute aucune protection. Elle ajoute seulement du risque.

Le lendemain, un second serveur, chez un autre hébergeur et avec d’autres sites, a montré les mêmes signes pour la même cause. Ce n’était donc pas un accident isolé, mais une dérive silencieuse qui prospère parce que « les sauvegardes, ça marche tout seul ».

Pour les confrères, le cheminement sans fard. Le signal de départ est une erreur de connexion Redis simultanée sur plusieurs sites. La commande redis-cli INFO persistence renvoie alors rdb_last_bgsave_status:err, Redis étant en stop-writes-on-bgsave-error yes. C’est son comportement par défaut, et c’est heureux : il protège l’intégrité de son instantané.

redis-cli INFO persistence         # rdb_last_bgsave_status:err
df -h                              # / à 100 %, 0 octet libre sur 387 Go
du -xh --max-depth=1 / | sort -h   # descendre jusqu'au dossier de sauvegardes
redis-cli BGSAVE                   # puis rdb_last_bgsave_status:ok
lsof +L1                           # fichiers supprimés encore ouverts

La suite tient en trois temps.

• Localiser. df -h montre la racine à 100 %. Une descente par du en profondeur croissante isole le répertoire de sauvegardes, ici 101 Go en 606 fichiers, les archives étant fractionnées en parts d’environ 200 Mo.
• Purger sans casser. On limite la purge aux fichiers d’archive et on conserve .htaccess, les journaux et les données de restauration. Puis redis-cli BGSAVE, contrôle du statut et test d’écriture.
• Corriger la planification. La sauvegarde complète horaire est désactivée, la rétention abaissée en local comme à distance.

Un piège vécu sur le second serveur mérite d’être connu : après la purge, une partie de l’espace n’est revenue qu’au redémarrage. Des fichiers supprimés restaient ouverts par le processus de sauvegarde. La commande lsof le confirme avant d’en arriver au redémarrage.

Si vous voulez la méthode complète en amont de l’incident, elle est détaillée dans notre guide de la sauvegarde WordPress, de la copie au test de restauration.

Cas réel traité le 30 juin 2026 sur une infrastructure que nous administrons, second cas confirmé le 1er juillet 2026 sur un serveur distinct. Les volumes, le nombre de fichiers et les pourcentages sont les valeurs mesurées pendant l’intervention. Le client et les sites concernés sont anonymisés. Outils mobilisés : supervision du parc, journaux Redis, analyse d’occupation disque et WP-CLI pour l’audit de configuration généralisé.