Les fichiers système corrompus reviennent sans cesse : la cause (et comment l’arrêter)

Ce que signifie réellement la « corruption récurrente »

Une corruption sur un événement unique est agaçante. La corruption récurrente est diagnostique. Si la même classe de fichiers continue de se détériorer—binaires gérés par paquets, bibliothèques partagées, fichiers de configuration ou journaux—votre système écrit à plusieurs reprises des données incorrectes, perd des écritures à répétition, ou rejoue sans cesse un état corrompu.

Deux schémas à reconnaître

Schéma A : « Je répare et ça casse encore. » Vous réinstallez glibc, restaurez depuis une sauvegarde, ou ré‑imagez l’hôte. Tout démarre, puis le même fichier devient de la bouillie plus tard. Cela suggère fortement un problème d’intégrité dans le chemin d’écriture : RAM, CPU, stockage, contrôleur, câble, alimentation, firmware, ou un bug du noyau/driver. Le logiciel peut aussi être en faute, mais l’interrogation doit d’abord viser le matériel.

Schéma B : « C’est toujours faux après un démarrage ou un déploiement. » La corruption apparaît juste après un redémarrage, après un déploiement automatisé, ou après un snapshot/rollback. Cela pointe vers des problèmes d’ordre/flush, des couches de cache, des images instables, ou une automatisation qui applique à répétition un artefact mauvais. Le stockage peut être impliqué, mais le moment où cela survient est un indice.

Ce qu’est (et n’est pas) la corruption

La corruption n’est pas toujours un fichier plein d’octets aléatoires. Cela peut être :

• Un fichier tronqué (fréquent avec perte d’alimentation, manque d’espace, ou sémantique de flush buggy).
• Une détérioration des métadonnées (entrées de répertoire erronées, inodes pointant vers n’importe quoi).
• Une incohérence logique (corruption au niveau applicatif, comme l’échec d’une somme de contrôle d’une page de base de données).
• Données obsolètes (le système a « réussi » l’écriture, mais lit ensuite un contenu ancien).

De plus : toute « corruption » n’est pas forcément une corruption. Parfois c’est un outil d’automatisation qui « corrige » une config dans un mauvais état, ou un script post‑installation qui réécrit des choses à chaque démarrage. L’astuce est de le prouver avec des preuves, pas des impressions.

Paraphrase d’une idée de John Allspaw : « On ne corrige pas les incidents en grondant les gens ; on corrige le système qui a rendu l’issue probable. »

Et oui, j’ai vu des équipes accuser des rayons cosmiques pendant des semaines alors que le vrai problème était un répartiteur d’alimentation SATA branlant. L’univers est vaste, mais votre baie est plus proche.

Mode d’emploi pour un diagnostic rapide

Ceci est l’ordre qui trouve rapidement le goulot en production. Ce n’est pas parfait. C’est rapide.

Première étape : décider si c’est reproductible et où ça se manifeste

1. Confirmer le symptôme : quels fichiers sont corrompus, quand ils changent, et sur quels hôtes ?
2. Vérifier les logs pour douleur I/O : messages du noyau, erreurs de système de fichiers, réinitialisations de contrôleur.
3. Vérifier si la corruption arrive à la lecture ou à l’écriture : les sommes de contrôle échouent‑elles en lisant d’anciennes données, ou seulement après de nouvelles écritures ?

Deuxième étape : trier la pile d’intégrité de bas en haut

1. État du stockage : SMART, erreurs média, statut RAID/mdadm, résultats de scrub ZFS/Btrfs.
2. Transport/contrôleur : réinitialisations de lien, logs d’erreur NVMe, messages firmware HBA.
3. Mémoire : logs EDAC/MCE, memtest, compteurs ECC.
4. Alimentation et historique d’arrêt : pertes d’alimentation brutales, événements PSU, arrêts sales, logs UPS si disponibles.

Troisième étape : éliminer « c’est notre automatisation »

1. Vérification des artefacts : les signatures de paquets se vérifient‑elles ? les couches de conteneur correspondent‑elles aux digests attendus ?
2. Dérive de gestion de configuration : un playbook applique‑t‑il le même fichier « mauvais » à chaque exécution ?
3. Comportement de rollback/snapshot : restaurez‑vous un snapshot connu mauvais ?

Actions pour arrêter l’hémorragie (à faire tôt)

• Quarantainez l’hôte s’il corrompt des écritures. Ne le laissez pas continuer à produire de la « mauvaise donnée » qui a l’air valide.
• Remontez les systèmes de fichiers suspects en lecture seule si vous le pouvez.
• Si vous utilisez RAID et suspectez un disque, marquez‑le et rebuild—après avoir collecté des preuves.
• Si vous suspectez la RAM, cessez de faire confiance au nœud. Une RAM défaillante peut aussi corrompre les sauvegardes.

Les modes de défaillance qui font revenir la corruption

1) Le sophisme « le système de fichiers l’a fait »

Ext4, XFS, ZFS, Btrfs—aucun n’est immunisé contre des données erronées qui lui sont transmises. Un système de fichiers peut détecter certaines classes de corruption (surtout avec des sommes de contrôle), mais il ne peut pas corriger magiquement ce que le CPU+RAM+contrôleur ont déjà dégradé, sauf si vous avez redondance et intégrité bout‑à‑bout.

Si vous voyez sans cesse de la corruption après « réparation du système de fichiers », vous avez probablement réparé des symptômes de métadonnées, pas la cause.

2) Supports de stockage instables : le classique ennuyeux

Les disques ne meurent pas toujours avec fracas. Souvent ils se dégradent. Vous verrez des secteurs realloués augmenter, des erreurs non corrigeables, ou des erreurs média NVMe. Parfois c’est un câble ou un backplane intermittent qui provoque des réinitialisations de lien, ce qui ressemble à des « erreurs I/O aléatoires » sous charge.

La corruption récurrente apparaît souvent dans les fichiers chauds : journaux, bases de données de paquets, bibliothèques partagées, et ce que votre agent de monitoring écrit chaque minute.

3) Ordonnancement d’écriture et mensonges de cache (alias « il a dit qu’il avait écrit »)

La pile de stockage est en couches : application → libc → cache de pages du noyau → système de fichiers → couche bloc → contrôleur → cache du dispositif → flash translation layer → média réel. Chaque couche peut reconnaître le succès tôt pour la performance. C’est acceptable jusqu’à ce qu’une perte d’alimentation ou un chemin de flush buggy fasse disparaître ou réordonner ces écritures « réussies ».

La version la plus maudite est un contrôleur ou un disque qui accuse réception des flushs mais ne les persiste pas réellement. Vous pouvez obtenir des motifs de corruption cohérents et répétitifs autour des arrêts, redémarrages ou panic kernel.

4) Mauvaise RAM : l’auteur silencieux de vos fichiers cassés

La RAM non‑ECC peut inverser des bits sans que vous le sachiez. La RAM ECC peut encore afficher des erreurs corrigées qui prédisent des défaillances non corrigeables à venir. Si vos fichiers système changent sans événement d’écriture clair, suspectez la mémoire. Si la base de données de votre gestionnaire de paquets est « corrompue » sur plusieurs installations fraîches du même hôte, suspectez fortement la mémoire.

5) Bugs de firmware et drivers : le piège « tout va bien »

Les disques NVMe modernes sont des ordinateurs avec du flash attaché. Les HBA et contrôleurs RAID exécutent un firmware qui peut être erroné de façons créatives. Les drivers du noyau évoluent. Un disque parfaitement sain peut produire de la corruption lorsqu’il est associé à une combinaison firmware+driver problématique, surtout sous forte profondeur de file d’attente, transitions de gestion d’alimentation, ou récupération d’erreurs.

6) Virtualisation et snapshots : le voyage temporel avec conséquences

Dans les environnements virtuels, la corruption peut être logique. Les snapshots peuvent être utilisés comme béquille, puis restaurés par erreur. Le thin provisioning peut atteindre ENOSPC au niveau de l’hyperviseur tandis que l’invité continue d’écrire jusqu’à s’effondrer. Les paramètres de cache de l’hôte peuvent violer les hypothèses de l’invité. Vous penserez « le système de fichiers invité est corrompu » alors que le véritable lieu du crime est le stockage hôte.

7) « Corruption » causée par votre propre pipeline

Parfois le fichier est « corrompu » parce que votre processus de déploiement a écrit la mauvaise build, tronqué un artefact, ou remplacé un binaire par un fichier texte (oui). Si le même fichier casse de la même façon après chaque déploiement, ce n’est probablement pas votre SSD. C’est votre CI/CD, votre dépôt d’artefacts, votre gestion de configuration, ou votre processus de création d’images.

Blague #1 : Le RAID n’est pas une sauvegarde. C’est juste une manière très confiante de perdre des données deux fois plus vite si vous êtes malchanceux.

Tâches pratiques : commandes, sorties et décisions

Ci‑dessous des tâches pratiques que vous pouvez exécuter sur un serveur Linux. Chacune inclut : la commande, ce que signifie une sortie typique, et la décision à prendre. Le thème est cohérent : collecter des preuves, puis prendre des actions irréversibles.

Tâche 1 : Identifier exactement ce qui a changé (et quand)

cr0x@server:~$ stat /usr/bin/sudo
  File: /usr/bin/sudo
  Size: 182000     Blocks: 360        IO Block: 4096   regular file
Device: 259,2 Inode: 131091      Links: 1
Access: 2026-02-05 10:11:44.000000000 +0000
Modify: 2026-02-05 09:58:12.000000000 +0000
Change: 2026-02-05 09:58:12.000000000 +0000
 Birth: 2025-12-01 03:14:55.000000000 +0000

Ce que cela signifie : Les timestamps Modify/Change indiquent quand le contenu ou les métadonnées ont changé. Si la corruption apparaît « après un reboot », mais que Modify est plusieurs heures plus tôt, votre reboot n’était pas la cause—juste le moment où vous l’avez remarqué.

Décision : Corrélez le temps Modify avec les déploiements, cron, logrotate, mises à jour de paquets et redémarrages. S’il n’y a pas d’événement d’écriture légitime, suspectez le stockage/la RAM.

Tâche 2 : Vérifier les fichiers gérés par paquets (détecter une corruption étendue)

cr0x@server:~$ sudo debsums -s
/usr/bin/sudo
/lib/x86_64-linux-gnu/libc.so.6

Ce que cela signifie : Les chemins listés diffèrent des sommes de contrôle attendues par le paquet. Plusieurs bibliothèques de base qui échouent est rarement « quelqu’un les a éditées ». C’est généralement de la corruption.

Décision : Si vous voyez plusieurs paquets non liés échouer, arrêtez de patcher fichier par fichier. Passez directement aux vérifications d’intégrité (disque/RAM) et envisagez de mettre l’hôte en quarantaine.

Tâche 3 : Vérifier les logs du noyau pour erreurs I/O et réinitialisations

cr0x@server:~$ sudo dmesg -T | egrep -i "I/O error|buffer I/O|blk_update_request|reset|nvme|ata|scsi|EXT4-fs error|XFS|BTRFS"
[Wed Feb  5 09:55:03 2026] nvme nvme0: I/O 123 QID 6 timeout, aborting
[Wed Feb  5 09:55:03 2026] nvme nvme0: Abort status: 0x371
[Wed Feb  5 09:55:05 2026] EXT4-fs error (device dm-0): ext4_find_entry:1453: inode #262402: comm systemd: reading directory lblock 0

Ce que cela signifie : Les timeouts et aborts indiquent que le périphérique ou le chemin a un comportement anormal. Les erreurs de système de fichiers sont souvent des conséquences en aval.

Décision : Si vous voyez des réinitialisations/timeouts, traitez‑le comme un incident matériel/firmware/transport jusqu’à preuve du contraire. Planifiez une fenêtre de maintenance contrôlée ; ne faites pas du « attendre et voir ».

Tâche 4 : Inspecter le journal système pour les récidivistes

cr0x@server:~$ sudo journalctl -b -p warning..alert --no-pager | head -n 20
Feb 05 09:55:06 server kernel: EXT4-fs error (device dm-0): ext4_journal_check_start:83: Detected aborted journal
Feb 05 09:55:06 server kernel: Buffer I/O error on dev dm-0, logical block 0, lost async page write

Ce que cela signifie : « Aborted journal » et « lost async page write » ne sont pas subtils. Ils indiquent que le noyau n’a pas pu compléter les écritures de façon fiable.

Décision : Réduisez immédiatement l’activité d’écriture et capturez les diagnostics du stockage. Si c’est un nœud de production dans une flotte, drenez‑le.

Tâche 5 : Vérifier l’état du système de fichiers (exemple ext4)

cr0x@server:~$ sudo tune2fs -l /dev/mapper/vg0-root | egrep -i "Filesystem state|Errors behavior|Last checked|Last mount time|Mount count|Maximum mount count"
Filesystem state:         clean
Errors behavior:          Continue
Last mount time:          Wed Feb  5 09:54:58 2026
Last checked:             Sun Jan 12 02:00:01 2026
Mount count:              39
Maximum mount count:      40

Ce que cela signifie : « Errors behavior: Continue » signifie qu’ext4 essaiera de continuer après des erreurs. Cela peut être utile, et cela peut aussi étendre les dégâts à travers votre système de fichiers.

Décision : Sur des systèmes où la justesse compte plus que la disponibilité, envisagez de régler errors sur remount read‑only. Mais faites‑le intentionnellement, avec préparation opérationnelle, pas comme un ajustement en panique.

Tâche 6 : Exécuter une vérification de système de fichiers en lecture seule (plutôt sûre)

cr0x@server:~$ sudo fsck.ext4 -fn /dev/mapper/vg0-root
e2fsck 1.46.5 (30-Dec-2021)
/dev/mapper/vg0-root: clean, 412351/6553600 files, 8123456/26214400 blocks

Ce que cela signifie : -n signifie « sans modifications », -f force la vérification. « clean » est bon ; cela n’innocente pas le matériel, mais réduit la probabilité que le système de fichiers soit la cause primaire.

Décision : S’il rapporte des erreurs, planifiez une réparation hors ligne et supposez que des problèmes I/O sous‑jacents pourraient re‑corrompre l’état réparé.

Tâche 7 : Vérifier SMART pour les disques SATA/SAS

cr0x@server:~$ sudo smartctl -a /dev/sda | egrep -i "Reallocated_Sector_Ct|Current_Pending_Sector|Offline_Uncorrectable|UDMA_CRC_Error_Count|SMART overall-health"
SMART overall-health self-assessment test result: PASSED
  5 Reallocated_Sector_Ct   0x0033   098   098   010    Pre-fail  Always       -       12
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       3
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       3
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       42

Ce que cela signifie : « PASSED » est du marketing. Les secteurs en attente/non corrigeables indiquent que le disque a eu des difficultés. Les erreurs CRC impliquent souvent les câbles/backplanes plutôt que le média lui‑même.

Décision : Remplacez le disque si les secteurs en attente/non corrigeables persistent ou augmentent. Si les erreurs CRC montent, ressortez/remplacez le câble/le chemin backplane et observez si le compteur cesse d’augmenter.

Tâche 8 : Vérifier la santé NVMe et le journal d’erreurs

cr0x@server:~$ sudo nvme smart-log /dev/nvme0
Smart Log for NVME device:nvme0 namespace-id:ffffffff
critical_warning                    : 0x00
temperature                         : 41 C
available_spare                     : 100%
percentage_used                     : 12%
media_errors                        : 7
num_err_log_entries                 : 54

Ce que cela signifie : Les erreurs média et un journal d’erreurs croissant sont des signaux rouges. Elles peuvent précéder une défaillance évidente de quelques semaines.

Décision : Extraites les entrées d’erreur détaillées et planifiez le remplacement. Les NVMe ont tendance à tenir « bien jusqu’au jour où non », et la corruption est souvent un prélude.

Tâche 9 : Vérifier le statut RAID/mdadm (RAID logiciel)

cr0x@server:~$ cat /proc/mdstat
Personalities : [raid1]
md0 : active raid1 sdb1[1] sda1[0]
      976630336 blocks super 1.2 [2/2] [UU]

unused devices: <none>

Ce que cela signifie : [UU] est sain. Si vous voyez [U_] ou un rebuild, l’array est dégradé ou en récupération—moment propice aux erreurs de lecture latentes pour se manifester.

Décision : Si dégradé, prenez toute alerte de corruption au sérieux : vous pourriez parfois lire depuis la « moitié mauvaise ». Vérifiez SMART par disque et envisagez de remplacer le disque suspect avant qu’un rebuild ne vous entraîne dans un échec de reconstruction.

Tâche 10 : Valider LVM et erreurs device‑mapper

cr0x@server:~$ sudo dmsetup status
vg0-root: 0 52428800 linear 
vg0-swap: 0 8388608 linear

Ce que cela signifie : Pour des mappages linéaires, status n’affichera pas grand‑chose. Mais si vous utilisez dm‑crypt ou thin pools, status peut révéler des échecs, manque d’espace ou problèmes de métadonnées.

Décision : Si les métadonnées du thin pool sont sollicitées ou proches du plein, corrigez cela avant tout. L’épuisement d’un thin pool peutimiter la corruption via des erreurs I/O et des écritures partielles.

Tâche 11 : Détecter les erreurs mémoire via EDAC/MCE (systèmes ECC)

cr0x@server:~$ sudo journalctl -k --no-pager | egrep -i "EDAC|MCE|Machine check|memory error" | tail -n 20
Feb 05 09:40:12 server kernel: EDAC MC0: 1 CE memory read error on CPU_SrcID#0_Ha#0_Chan#1_DIMM#0
Feb 05 09:40:12 server kernel: mce: [Hardware Error]: Machine check events logged

Ce que cela signifie : Les erreurs corrigées (CE) sont des avertissements. Elles peuvent devenir non corrigibles (UE). Un flux continu de CE n’est pas « acceptable ». C’est votre serveur qui vous dit poliment qu’il vous ment parfois.

Décision : Si vous voyez des CE récurrents, planifiez le remplacement du DIMM. Si vous voyez des UE ou des panics, retirez le nœud immédiatement.

Tâche 12 : Faire un test d’intégrité ciblé avec des sommes de contrôle

cr0x@server:~$ sudo sha256sum /usr/bin/sudo /lib/x86_64-linux-gnu/libc.so.6
c2b6d0b0a1e9a0d0f6c4b2f1e0d8a9f7b6a5c4d3e2f1a0b9c8d7e6f5a4b3c2d1  /usr/bin/sudo
b4d1c2e3f4a5968778695a4b3c2d1e0f9a8b7c6d5e4f3a2b1c0d9e8f7a6b5c4  /lib/x86_64-linux-gnu/libc.so.6

Ce que cela signifie : Vous créez une base de référence pour comparaison ultérieure. Si les hachages changent sans mises à jour légitimes, vous avez une perte d’intégrité.

Décision : Revérifiez après un stress ou après un reboot. Si les hachages dérivent, arrêtez de faire confiance à la machine et concentrez‑vous sur le matériel, le firmware et l’alimentation.

Tâche 13 : Stresser l’I/O et surveiller de nouvelles erreurs noyau (test contrôlé)

cr0x@server:~$ sudo fio --name=verify --filename=/var/tmp/fio.dat --size=2G --rw=randwrite --bs=4k --ioengine=libaio --direct=1 --numjobs=1 --iodepth=32 --verify=crc32c --verify_fatal=1 --runtime=60 --time_based
verify: (groupid=0, jobs=1): err= 0: pid=22110: Wed Feb  5 10:05:12 2026
  write: IOPS=18.2k, BW=71.0MiB/s (74.5MB/s)(4262MiB/60001msec)
  lat (usec): min=45, max=21980, avg=172.1, stdev=311.4

Ce que cela signifie : Les erreurs de vérification pendant fio sont extrêmement actionnables. Si l’outil signale une non‑correspondance de vérification, quelque chose sous l’espace utilisateur corrompt les données.

Décision : Si la vérification échoue, traitez‑le comme un incident matériel. Si elle passe mais que la production corrompt toujours, suspectez la logique de couche supérieure (automatisation, rollback, mauvaise utilisation par l’application) ou des problèmes matériels intermittents déclenchés par différents états de charge/alimentation.

Tâche 14 : Vérifier l’espace disque et l’épuisement d’inodes (le corrupteur discret)

cr0x@server:~$ df -h / /var /tmp
Filesystem             Size  Used Avail Use% Mounted on
/dev/mapper/vg0-root    50G   49G  200M 100% /
/dev/mapper/vg0-var     80G   79G  300M 100% /var
tmpfs                  7.8G  1.2G  6.6G  16% /tmp

Ce que cela signifie : Être à 100% peut provoquer des écritures tronquées, des renommages atomiques échoués, et des mises à jour de paquets à moitié écrites. Cela ressemble à de la corruption du point de vue de l’application.

Décision : Si vous êtes plein, libérez de l’espace d’abord. Puis relancez l’opération qui a « corrompu » les fichiers. Si le problème disparaît, ce n’était pas un SSD hanté—c’était un disque plein et de l’optimisme.

Tâche 15 : Confirmer si l’hôte subit des arrêts sales

cr0x@server:~$ last -x | head -n 12
reboot   system boot  5.15.0-94   Wed Feb  5 09:54   still running
shutdown system down  5.15.0-94   Tue Feb  4 22:10 - 22:10  (00:00)
reboot   system boot  5.15.0-94   Tue Feb  4 22:10 - 22:10  (00:00)
reboot   system boot  5.15.0-94   Tue Feb  4 17:31 - 22:10  (04:39)

Ce que cela signifie : Les événements « reboot » sans entrées « shutdown » correspondantes peuvent indiquer des plantages, pertes d’alimentation, ou reset forcés.

Décision : Si vous voyez des arrêts sales fréquents, traitez‑les comme une usine à corruption. Enquêtez sur l’alimentation, les panics noyau, les resets watchdog, et la stabilité de l’hyperviseur.

Trois mini‑récits d’entreprise issus du terrain

Mini‑récit 1 : L’incident causé par une mauvaise hypothèse

L’entreprise : une PME SaaS avec une flotte d’hôtes Linux « identiques » et une rotation d’astreinte active. Le symptôme : des défaillances sporadiques commençant par des plaintes du gestionnaire de paquets. Quelques nœuds signalaient que des bibliothèques partagées avaient une « taille inattendue » ou échouaient la vérification de somme. La première hypothèse était réconfortante : « C’est juste un mauvais déploiement. »

Ils ont rollbacké. Les erreurs sont revenues. Ils ont ré‑imagez. Même histoire, semaine après semaine. Quelqu’un a finalement comparé les nœuds défaillants et a trouvé une commune mesure silencieuse : tous étaient dans le même rack, sur le même switch top‑of‑rack et le même feed de PDU. Le stockage étant local NVMe, le réseau semblait hors de cause. Cette hypothèse—« le réseau ne peut pas causer la corruption des disques locaux »—était le piège.

Le vrai problème était des événements d’alimentation sales. De brèves baisses n’étaient pas suffisantes pour planter tous les serveurs, mais assez pour créer un comportement de brownout : les contrôleurs se réinitialisaient en plein écrit, les périphériques disparaissaient pendant des millisecondes, et l’OS continuait de tourner pendant que le chemin de stockage passait une mauvaise journée. Les nœuds ne redémarraient pas toujours. Ils continuaient, accusant parfois une écriture qui n’avait jamais atterri.

Une fois qu’ils ont corrélé les logs du noyau avec l’historique des événements du PDU, le motif s’est révélé : réinitialisations du stockage dans les secondes suivant chaque fluctuation d’alimentation. Les fichiers « corrompus » étaient exactement ceux qu’on s’attendrait à voir être chauds durant ces fenêtres : journaux, bases de paquets, et états de service fréquemment mis à jour.

La correction fut ennuyeuse et immédiate : stabiliser l’alimentation (remplacer un module PDU défaillant, déplacer l’alimentation du rack, valider le comportement UPS), puis ré‑image des hôtes affectés. Et, crucialement, ils ont changé leur runbook : tout hôte montrant des erreurs de système de fichiers plus des réinitialisations de périphérique est d’abord drainé, puis debuggué. Cette politique a évité des semaines de jeu du chat et de la souris.

Mini‑récit 2 : L’optimisation qui s’est retournée contre eux

Une grande équipe d’entreprise voulait accélérer les builds sur leur ferme de build interne. Ils ont monté un système de fichiers partagé pour les artefacts et ajusté des paramètres pour gagner en performance : writeback agressif, comportement sync relaxé au niveau applicatif, et une attitude « si c’est rapide, c’est bon ». C’était rapide. Puis ce n’était plus bon.

Les premiers signes étaient subtils : erreurs « archive corrupted » occasionnelles, échecs de tests qui disparaissaient au rerun, et binaires qui ne plantaient que dans la CI. Les ingénieurs ont accusé des tests instables (une tradition intemporelle) et ont ajouté des retries. Les retries « corrigeaient » le symptôme en le masquant.

Des mois plus tard, ils ont subi une défaillance spectaculaire : un candidat de release construit avec un outil corrompu. Rien de malveillant—juste des octets faux. Le build s’est terminé, les paquets signés, le déploiement lancé, et seulement ensuite les services ont commencé à se comporter comme s’ils avaient appris de nouvelles lois de la physique.

Le postmortem a montré une réaction en chaîne : l’optimisation de performance a élargi la fenêtre où les données vivaient en caches sans persistance durable. Un ensemble d’événements d’alimentation plus une forte charge d’écriture ont créé des écritures partielles d’artefacts. Parce que la pipeline manquait de vérification bout‑à‑bout à la frontière des artefacts, les mauvaises données ont propagé comme si elles étaient correctes.

La correction n’a pas été « ajouter plus de retries ». Ce fut restaurer la sémantique correcte de durabilité, ajouter des checksums d’artefact à la publication et à la consommation, et bloquer les releases en cas d’échec de vérification. La performance est revenue, légèrement moindre. La fiabilité est revenue, bien plus importante.

Mini‑récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une petite équipe de services financiers exécutait quelques nœuds Linux critiques. Matériel pas excitant. Pas à la pointe. Leur « arme secrète » était la discipline : scrubs périodiques de système de fichiers quand supporté, monitoring SMART avec seuils déclenchant le remplacement avant la catastrophe, et vérifications d’intégrité hebdomadaires d’un échantillon de binaires système.

Un vendredi après‑midi, une alerte a déclenché : des erreurs mémoire corrigées sont apparues sur un hôte qui traitait des batchs. Le système était encore « sain », et la charge « non client ». Le mouvement tentant aurait été d’ignorer jusqu’à lundi. Ils ne l’ont pas fait. Ils ont drainé le nœud et remplacé le DIMM cette nuit‑là.

Quand le DIMM est sorti, il ressemblait à tout autre DIMM : innocent et silencieux. Mais les logs étaient clairs—les taux d’erreur montaient. S’ils avaient attendu, l’étape suivante aurait pu être des erreurs non corrigibles, des panics noyau, ou pire : une corruption silencieuse des données qui rend vos sorties incorrectes alors que le statut du job dit « success ».

Ils ont reconstruit le nœud depuis une image connue bonne, relancé les batchs, et comparé les sorties. Les résultats d’un job différaient. C’était la preuve irréfutable : le système avait probablement produit des données incorrectes avant le remplacement du DIMM. Parce qu’ils avaient l’habitude de garder des sorties de référence et de les vérifier, ils ont détecté la divergence rapidement.

Leur pratique était ennuyeuse : surveiller, remplacer tôt, vérifier les sorties, et garder des images gold. Cela les a sauvés d’un scénario où « tout semblait vert » alors que les chiffres business étaient silencieusement faux.

Blague #2 : Si vous entendez « ça ne corrompt que parfois », c’est juste « ça corrompt » qui porte une plus jolie chemise.

Erreurs courantes : symptôme → cause racine → correctif

1) « fsck a réparé, donc on a fini »

Symptôme : Des erreurs de système de fichiers apparaissent, vous lancez fsck, le système démarre, puis la corruption revient.

Cause racine : Instabilité I/O sous‑jacente (disque, NVMe, contrôleur, événements d’alimentation) continue de corrompre les données.

Fix : Traitez fsck comme du triage. Récupérez SMART/NVMe logs, vérifiez dmesg pour des réinitialisations, et remplacez les composants défaillants. Ré‑imagez après avoir prouvé la stabilité matérielle.

2) « SMART dit PASSED »

Symptôme : La corruption persiste ; SMART overall health affiche PASSED.

Cause racine : Le « PASSED » SMART n’est pas prédictif ; vous avez ignoré l’évolution des attributs (secteurs en attente, erreurs CRC, erreurs média).

Fix : Suivez les deltas des attributs SMART. Remplacez les disques selon la croissance des reallocated/pending/uncorrectable ou des erreurs média NVMe—pas sur la seule ligne PASSED.

3) Corruption après chaque reboot

Symptôme : Le système revient avec des paquets cassés ou des fichiers illisibles après des cycles d’alimentation.

Cause racine : Mensonges du cache d’écriture, flushs incomplets au shutdown, ou perte d’alimentation abrupte provoquant un replay du journal vers un état endommagé.

Fix : Corrigez la stabilité d’alimentation. Validez le comportement du cache d’écriture du disque et le firmware du contrôleur. Envisagez des systèmes de fichiers avec sommes de contrôle bout‑à‑bout et redondance quand c’est approprié.

4) « Un seul fichier se corrompt sans cesse » (et vous le remplacez en boucle)

Symptôme : Le même fichier de config ou binaire est « corrompu » à répétition, mais le disque semble sain.

Cause racine : L’automatisation ou un script de démarrage le réécrit sans cesse (mauvais template, troncation, écriture atomique échouée à cause d’ENOSPC).

Fix : Auditez les runs de gestion de configuration et les scripts de démarrage d’unités. Confirmez les patterns d’écriture atomique (écrire fichier temp, fsync, rename) et vérifiez l’espace disque/inodes.

5) « Les bases de données sont corrompues, c’est forcément la base »

Symptôme : SQLite/Postgres/MySQL rapporte des échecs de checksum ou des pages corrompues.

Cause racine : Stockage ou mémoire corrompus en dessous, ou événements disque plein causant des écritures partielles.

Fix : Vérifiez l’intégrité côté hôte (SMART/NVMe, logs mémoire), vérifiez les réglages de durabilité de la base, et confirmez que vous n’êtes pas à court d’espace pendant l’activité de la base.

6) Corruption sur plusieurs hôtes en même temps

Symptôme : Plusieurs nœuds montrent des événements similaires de « fichier corrompu » dans la journée.

Cause racine : Infrastructure partagée : une image mauvaise, un artefact défectueux, un array de stockage instable, ou un événement d’alimentation sur un rack/zone.

Fix : Cherchez le blast radius partagé. Comparez les build IDs, les digests d’image, et l’emplacement physique. Arrêtez les rollouts jusqu’à ce que vous puissiez prouver l’intégrité des artefacts.

7) « On va juste ajouter des retries »

Symptôme : Un build ou déploiement échoue parfois avec un mismatch de checksum ; les retries réussissent.

Cause racine : Vous masquez une source de corruption (dépôt d’artefacts, cache, transport, disque) et transformez cela en risque silencieux.

Fix : Rendez les mismatches de checksum fatals aux frontières. Les retries conviennent pour des erreurs réseau transitoires, pas pour des échecs d’intégrité.

Listes de contrôle / plan étape par étape

Étape 1 : Contenir les dégâts

• Drainer le nœud du trafic de production ou des planificateurs de charges.
• Arrêter les écritures non essentielles (désactiver agents bruyants, mettre en pause les jobs batch).
• Snapshotter ou imager le disque si vous avez besoin de preuves judiciaires, mais ne laissez pas cela retarder le remplacement lorsque les données sont à risque.

Étape 2 : Prouver si la corruption est en cours

• Hacher un petit ensemble de binaires et bibliothèques stables ; revérifier après stress et après un reboot.
• Exécuter un test I/O centré intégrité (comme fio avec verify) dans une fenêtre contrôlée.
• Vérifier les paquets sur tout le système (debsums ou vérification RPM) pour évaluer le blast radius.

Étape 3 : Remonter la pile du matériel vers le haut

• Média de stockage : SMART/NVMe logs, taux d’erreur, timeouts.
• Transport : erreurs CRC, réinitialisations de lien, logs HBA, vérification câbles/backplane.
• Mémoire : EDAC/MCE, memtest si vous pouvez prendre un arrêt.
• Alimentation : fréquence des arrêts sales, événements UPS et PDU.

Étape 4 : Corriger avec des remplacements et des configurations durables

• Remplacez proactivement les disques suspects. « Ça peut aller » n’est pas une stratégie SRE.
• Remplacez les DIMMs si des erreurs corrigées apparaissent de façon répétée.
• Mettre à jour le firmware NVMe/HBA lorsque les preuves pointent vers des timeouts/réinitialisations et que vous disposez de versions connues bonnes dans votre environnement.
• Corrigez l’instabilité d’alimentation ; ne vous contentez pas d’améliorer le journal et d’espérer.

Étape 5 : Reconstruire depuis du connu‑bon, puis revalider

• Ré‑imagez l’hôte ou réinstallez l’OS après confirmation de la stabilité matérielle.
• Relancez les contrôles d’intégrité post‑reconstruction : vérification des paquets, bases de hachages, et un court test verify I/O.
• Ce n’est qu’après cela que vous remettez en production.

Politique opérationnelle qui empêche les répétitions

• Rendez les mismatches de checksum et les erreurs I/O de système de fichiers dignes d’une alerte page.
• Gardez un état « quarantaine » pour les nœuds suspectés de corrompre des écritures.
• Suivez les deltas SMART/NVMe dans le temps, pas seulement les valeurs actuelles.
• Validez les artefacts à la publication et à la consommation avec des hachages.

Faits intéressants et contexte historique

• Les premiers systèmes de fichiers faisaient confiance au matériel. Beaucoup de designs classiques supposaient que disques et contrôleurs étaient honnêtes ; les sommes de contrôle bout‑à‑bout sont devenues courantes plus tard.
• La journalisation a réduit le temps de récupération, pas la vérité. Les systèmes de fichiers journalisés (comme ext3/ext4, XFS) aident à récupérer la consistance des métadonnées après crash, mais ne garantissent pas que vos données n’étaient pas erronées avant d’atteindre le journal.
• La corruption silencieuse existe depuis avant les SSD. Les flips de bits et écritures mal dirigées existaient aussi sur disques rotatifs ; les SSD ont juste ajouté plus de complexité firmware et de couches de traduction.
• La mémoire ECC n’a pas toujours été standard. Beaucoup de flottes fonctionnent encore sans ECC pour des raisons de coût, puis s’étonnent quand la corruption « impossible » survient.
• Les erreurs CRC signifient souvent des câbles. L’augmentation des erreurs UDMA CRC est fréquemment résolue en resserrant ou remplaçant les câbles SATA/SAS ou les backplanes, pas en changeant les disques.
• Les checksums sont devenus une fonctionnalité de stockage, pas juste applicative. Des systèmes de fichiers comme ZFS et Btrfs ont popularisé les checksums intégrés pour la détection (et avec redondance, la correction).
• Le comportement des caches d’écriture a une longue histoire de mensonges. L’industrie a maintes fois découvert des périphériques qui accusent réception des flushs incorrectement, surtout à travers des générations de firmware.
• « Ça marchait en staging » est une preuve faible. La corruption exige souvent une combinaison de chaleur, charge, profondeur de file d’attente, ou conditions d’alimentation que la staging ne reproduit jamais.

FAQ

1) Un système de fichiers peut‑il « guérir » une corruption récurrente tout seul ?

Pas à moins qu’il n’ait à la fois détection et redondance. Les checksums détectent ; les miroirs/parité permettent de corriger. Sans redondance, le système de fichiers peut seulement se plaindre, pas réparer.

2) Si je réinstalle l’OS et que la corruption revient, quelle est la cause la plus probable ?

Instabilité matérielle (RAM, média de stockage, contrôleur, alimentation) ou un artefact/image mauvais répété. Si une installation fraîche se corrompt de la même façon sur le même hôte, suspectez d’abord la RAM et le stockage.

3) Est‑ce que c’est parfois « juste un mauvais arrêt » ?

Un seul arrêt non propre peut causer des dégâts, oui. Mais si cela se répète, les arrêts sont aussi un symptôme : alimentation instable, panics noyau, resets watchdog, ou un problème d’hyperviseur.

4) Comment distinguer une corruption disque d’une corruption mémoire ?

Les problèmes disque produisent souvent des erreurs I/O, timeouts, réinitialisations, avertissements SMART/NVMe, et plaintes de système de fichiers. Les problèmes mémoire peuvent provoquer des pannes étranges et généralisées : vérifications de paquets qui échouent sur des fichiers non liés, segfaults aléatoires, erreurs de décompression, et résultats incohérents entre runs. Les logs ECC (EDAC/MCE) sont l’indice le plus rapide si vous les avez.

5) Pourquoi la corruption touche‑t‑elle souvent les bases de paquets et les journaux en premier ?

Ce sont des fichiers chauds : écritures fréquentes et petites, beaucoup de patterns fsync/rename, et churn constant. Si votre chemin de stockage est instable, les fichiers chauds prennent le premier coup.

6) Les SSD sont‑ils plus ou moins susceptibles de corrompre les données que les HDD ?

Aucun n’est « sûr » par défaut. Les SSD ont plus de complexité firmware et peuvent échouer brutalement ; les HDD peuvent se dégrader lentement. Votre meilleure défense est le monitoring, la redondance, et la vérification d’intégrité.

7) Que faire si une seule VM montre de la corruption mais que l’hôte semble sain ?

Vérifiez la santé du stockage de l’hyperviseur, le thin provisioning, et l’historique snapshots/rollback. Des symptômes uniquement invités peuvent toujours venir d’un stockage hôte mensonger ou d’un épuisement de capacité au niveau virtualisation.

8) Dois‑je changer de système de fichiers pour régler ça ?

Changer de système de fichiers peut aider si vous passez à des systèmes avec checksums bout‑à‑bout et redondance (et la maturité opérationnelle pour exécuter des scrubs et gérer les remplacements). Mais changer pour « un autre système de fichiers journalisé » ne réparera pas une RAM défaillante ou une alimentation instable.

9) Si fio verify passe, suis‑je tranquille ?

Pas complètement. Cela signifie que la corruption n’a pas été reproduite sous ce test. Les problèmes intermittents peuvent dépendre de la température, d’états de gestion d’alimentation, ou de profils de charge. Traitez un passage comme une preuve, pas comme une exonération.

10) Quelle est la décision la plus rapide à prendre en production ?

Si vous voyez des réinitialisations/timeouts de périphérique dans dmesg plus des erreurs de système de fichiers : drainez le nœud et remplacez le matériel ou déplacez‑le hors du domaine rack/alimentation suspect. Ne négociez pas avec la physique.

Étapes suivantes qui tiennent dans le temps

Si les fichiers système corrompus reviennent sans cesse, arrêtez de traiter cela comme une réparation ponctuelle. Traitez‑le comme un incident d’intégrité avec une condition de récidive.

1. Collecter des preuves : erreurs dmesg, logs SMART/NVMe, messages EDAC/MCE, et sorties de vérification de paquets.
2. Quarantaine : drainer le nœud pour qu’il ne produise plus d’écritures mauvaises ni n’empoisonne les systèmes en aval.
3. Prouver la corruption en cours : bases de hachage et un court test I/O axé verify.
4. Corriger la cause : remplacer les disques dont les attributs d’erreur augmentent, remplacer les DIMMs avec des erreurs corrigées récurrentes, corriger l’instabilité d’alimentation, et mettre à jour le firmware quand il correspond aux modes de défaillance observés.
5. Reconstruire proprement : ré‑imagez depuis une source connue bonne, puis validez l’intégrité avant de remettre en service.
6. Prévenir les répétitions : imposer la vérification des checksums aux frontières d’artefact, suivre les deltas SMART/NVMe, et maintenir un runbook qui privilégie le drainage plutôt que le déni.

L’objectif n’est pas de devenir paranoïaque. C’est de devenir non‑surpris. La corruption récurrente est votre système qui vous envoie un signal fiable. Prenez l’indice, réparez le chemin, et laissez vos fichiers redevenir ennuyeux.