Récupération ext4 vs XFS sur Ubuntu 24.04 : quel outil exécuter en premier (et pourquoi)

décembre 3, 2025 • février 3, 2026 • Lecture : 32 min • Views: 7

Cet article vous a aidé ?

Vous avez redémarré. La machine, non. Ou elle a démarré, mais un point de montage est passé en lecture seule, des applications renvoient des erreurs d’E/S, et votre réflexe « correction rapide » plane sur fsck comme un doigt nerveux au-dessus d’un gros bouton rouge.

C’est le moment où l’ordre des outils compte plus que le choix de l’outil. Avec ext4 et XFS, le mauvais premier geste peut transformer un problème de métadonnées récupérable en une fouille archéologique. Le bon premier geste paraît souvent ennuyeux : identifier, isoler, imager/snapshoter, puis réparer avec les outils natifs du système de fichiers dans l’ordre recommandé.

La règle importante : votre premier outil est « arrêter de modifier le disque »

Si vous ne retenez qu’une chose : les outils de réparation de systèmes de fichiers ne sont pas des « diagnostics en lecture seule ». Ce sont des chirurgiens, et parfois ils amputent pour sauver le patient. Votre premier outil est un bouton pause : remontez en lecture seule, arrêtez les services et capturez des preuves avant de muter l’état.

Ce que « premier » signifie dans la vie réelle

Quand quelqu’un dit « exécutez fsck » ou « exécutez xfs_repair », il veut généralement dire « corrigez maintenant ». En exploitation, « premier » devrait signifier :

Confirmez quel système de fichiers vous touchez. Les gens se trompent plus souvent qu’ils ne l’admettent.
Confirmez le mapping du périphérique. LVM, mdraid, multipath, namespaces NVMe : votre intuition /dev/sdX n’est pas une stratégie.
Confirmez le domaine de défaillance. Est-ce le système de fichiers, le bloc de stockage, le contrôleur, ou une couche au-dessus (comme dm-crypt, mdraid ou le stockage virtualisé) ?
Faites en sorte que le disque cesse de changer. Si vous pouvez faire un snapshot, faites-le. Si vous pouvez imageer, faites-le. Si vous pouvez au moins remonter en lecture seule, faites-le.

Ce n’est qu’ensuite que vous choisissez le premier outil spécifique au système de fichiers. Sur ext4, c’est généralement fsck.ext4 (via e2fsck) mais pas toujours en mode « corriger tout ». Sur XFS, c’est typiquement xfs_repair — souvent précédé de xfs_repair -n ou d’une décision volontaire sur le journal (-L n’est pas un câlin chaleureux).

Une règle supplémentaire : si vous voyez des erreurs matérielles (timeouts, erreurs média, CRC), traitez les utilitaires de réparation comme secondaires. Réparez la plomberie d’abord, sinon vous allez réparer une corruption qui continue de s’accumuler.

Blague 1 : Lancer des outils de réparation sur un disque mourant, c’est comme repeindre une maison pendant un tremblement de terre : ce n’est pas la faute de la peinture, et ça ne finira pas bien.

Et une vérité opérationnelle à épingler dans votre canal d’incident :

« L’espoir n’est pas une stratégie. » — General Gordon R. Sullivan

Faits et contexte qui modifient les décisions

Ce ne sont pas des détails triviaux. Ils expliquent pourquoi ext4 et XFS se comportent différemment en cas de panne, et pourquoi le « premier outil » diffère.

ext4 descend de la lignée de journalisation d’ext3, conçu pour une large compatibilité Linux et une récupération prévisible. Son journal rend souvent les montages post-crash plus tolérants que les anciens systèmes de fichiers.
XFS est né chez SGI pour des systèmes IRIX haute performance et est ensuite devenu un système de fichiers Linux majeur ; il est construit autour de structures de métadonnées agressives et d’une grande évolutivité.
XFS journalise les métadonnées (le log), pas les données de fichiers par défaut. Cela signifie qu’après un crash vous pouvez voir des contenus de fichiers « propres » mais sémantiquement incorrects parce que les dernières écritures n’ont pas été complétées — surtout pour des applications sans discipline d’fsync.
Le mode « ordered » d’ext4 (souvent par défaut) tente de vidanger les données de fichier avant de valider les métadonnées associées, réduisant certaines classes de pointeurs orphelins après crash, au prix de la performance.
XFS utilise des allocation groups (AG) pour paralléliser les opérations sur les métadonnées. La corruption peut se localiser à un AG, ce qui est utile ; la réparation nécessite souvent un scan complet, lent sur de gros volumes.
ext4 peut faire des « vérifications de métadonnées en ligne » de façon limitée, mais les incohérences sérieuses nécessitent généralement un démontage et e2fsck. La réparation XFS est aussi hors-ligne pour les réparations réelles.
XFS a un mécanisme de replay du journal au montage. Si le journal lui-même est corrompu, le montage peut échouer. On est tenté d’utiliser xfs_repair -L, qui abandonne le journal — parfois nécessaire, parfois désastreux.
ext4 dispose de checksums de métadonnées et de journal sur les noyaux modernes ; cela aide à détecter la corruption tôt, mais cela signifie aussi que des environnements de secours anciens peuvent échouer face à des flags de fonctionnalités récents.
Les environnements de secours Ubuntu 24.04 comptent : un live ISO trop ancien peut ne pas comprendre vos fonctionnalités ext4 ou les métadonnées XFS v5, vous faisant diagnostiquer à tort une « corruption » qui est en réalité un « outil obsolète ».

Ces faits aboutissent à une conclusion sobre : ext4 tend vers des workflows « réparer via fsck », tandis que XFS exige de « diagnostiquer d’abord, puis réparer prudemment », avec un respect particulier pour le journal.

Quel outil lancer en premier (ext4 vs XFS) : le tableau de décision

Avant les outils du système de fichiers : les premiers gestes universels

Le premier « outil » devrait être un ensemble d’actions, pas une commande :

Arrêter les écritures : arrêter les services, démonter si possible, ou remonter en lecture seule.
Valider le chemin du périphérique : confirmer si vous êtes sur une partition, un LV LVM, un mdraid ou une mapping dm-crypt.
Chercher des erreurs matérielles : dmesg, journaux SMART/NVMe, statut RAID.
Faire un snapshot ou une image si les données comptent : snapshot LVM, snapshot de stockage, ou ddrescue si le matériel échoue.

Maintenant l’outil spécifique au système de fichiers

Voici l’ensemble de règles d’opinion que j’utilise en production.

ext4 : l’outil initial est généralement `e2fsck`, mais commencez par « regarder, ne pas toucher »

Si le système de fichiers est démontable ou monte en lecture seule à cause d’erreurs : lancez d’abord e2fsck -fn (sans modifications) pour estimer l’étendue des dégâts et le risque. Décidez ensuite si vous devez snapshotter/imager et exécuter une passe de correction.
Si vous suspectez une corruption sévère ou des problèmes matériels : faites d’abord des vérifications SMART/NVMe et envisagez l’imagerie, puis lancez e2fsck sur l’image ou le snapshot.
Si le journal est suspect : vous pourriez avoir besoin de e2fsck -f et, dans certains cas, de reconstruire le journal avec tune2fs — mais ne commencez pas par ça.

XFS : l’outil initial est `xfs_repair -n` (simulation), pas `xfs_repair`

Si le montage échoue avec des erreurs de journal : commencez par xfs_repair -n pour voir ce qu’il ferait. S’il indique que le journal est sale/corrompu, décidez prudemment s’il faut monter avec récupération ou abandonner le journal.
N’utilisez xfs_repair -L que si vous acceptez de perdre des transactions de métadonnées récentes. Il peut ramener le système de fichiers, mais au prix d’oublier « l’historique récent ». Parfois cela signifie perdre des fichiers entiers ou des entrées de répertoire créés juste avant le crash.
Si le matériel flanche : imagez d’abord. La réparation XFS sollicite beaucoup les métadonnées et va stresser un disque en fin de vie.

Blague 2 : xfs_repair -L c’est comme effacer l’historique de navigation : ça résout un problème, pas forcément celui que vous avez réellement.

La réponse courte : pourquoi l’ordre diffère

Le workflow de réparation d’ext4 est construit autour de fsck comme correcteur autoritaire, et il peut souvent rejouer ou concilier les journaux de façon relativement déterministe. XFS attend que le montage rejoue le journal pour gérer les récupérations courantes, et quand cela échoue, le journal devient un point de décision. C’est pourquoi xfs_repair -n est le bon premier outil pour XFS : il vous dit si vous êtes sur le point de prendre une tronçonneuse sur le journal.

Plan de diagnostic rapide (trouver rapidement le goulot)

Quand le temps presse, l’objectif n’est pas « être exhaustif ». L’objectif est « identifier quelle couche vous trompe ». Voici un ordre rapide qui fonctionne sur Ubuntu 24.04 dans de vraies flottes.

Étape 1 : Est-ce matériel ou transport ?

Vérifiez les logs du noyau pour des erreurs d’E/S/timeouts. Si vous en voyez, traitez les symptômes du système de fichiers comme secondaires.
Vérifiez rapidement la santé SMART/NVMe. Secteurs réalloués, erreurs média, erreurs CRC ou flags « critical_warning » NVMe changent tout.
Si c’est du RAID : confirmez la santé de l’array avant d’exécuter des outils de réparation. Réparer sur un array dégradé/en reconstruction peut aller, mais réparer sur un array silencieusement incohérent est une manière de créer de l’art.

Étape 2 : Le mapping bloc est-il correct ?

Confirmez l’identité du périphérique (UUID, WWN, numéro de série). Ne faites pas confiance à /dev/sdX.
Confirmez les couches : dm-crypt ? LVM ? mdraid ? multipath ? volume cloud ?

Étape 3 : Quel système de fichiers est-ce et que dit-il de lui-même ?

Identifiez le type et les fonctionnalités du FS sans monter (ou montez en lecture seule si c’est sûr).
Pour ext4 : faites une passe fsck non destructive pour voir l’étendue.
Pour XFS : faites une simulation de réparation pour vérifier si le journal est le problème.

Étape 4 : Choisissez la voie de récupération la plus sûre

Les données sont irremplaçables : imagez/snapshotez d’abord, réparez ensuite.
Le service est irremplaçable : basculez d’abord, réparez à côté.
Vous devez remettre la machine en 10 minutes : vous serez tenté de « lancer le réparateur ». Faites au moins une passe en lecture seule pour savoir ce que vous risquez.

Tâches pratiques de récupération (commandes, ce que la sortie signifie, et la décision à prendre)

Ceux-ci sont délibérément opérationnels : chaque tâche inclut une commande, une sortie exemple, ce que cela signifie, et ce que vous faites ensuite. Exécutez-les depuis un shell de secours si possible (ou au moins en mode mono-utilisateur). Remplacez les noms de périphériques avec précaution.

Tâche 1 : Confirmer ce qui échoue (erreurs de montage et état actuel)

cr0x@server:~$ findmnt -rno TARGET,SOURCE,FSTYPE,OPTIONS / /var /home
/ /dev/mapper/vg0-root ext4 rw,relatime,errors=remount-ro
/var /dev/nvme0n1p3 xfs ro,relatime
/home /dev/mapper/vg0-home ext4 rw,relatime

Signification : /var est en XFS et déjà en lecture seule. C’est un indice : soit XFS a détecté une incohérence, soit le noyau l’a passé en lecture seule à cause d’erreurs d’E/S.

Décision : Arrêtez tout ce qui écrit dans /var. Si vous ne pouvez pas démonter, gardez en lecture seule et commencez par des vérifications du journal/matériel avant la réparation.

Tâche 2 : Identifier le type de système de fichiers depuis le périphérique bloc (sans deviner)

cr0x@server:~$ lsblk -f /dev/nvme0n1
NAME        FSTYPE FSVER LABEL UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
nvme0n1
├─nvme0n1p1  vfat   FAT32       4C3A-1B2F                             510M     2% /boot/efi
├─nvme0n1p2
└─nvme0n1p3  xfs               3a2d0a3e-3f2e-4f2d-9d8a-0c2c8c9d6f11                /var

Signification : C’est XFS sur /dev/nvme0n1p3. Pas d’ambiguïté.

Décision : Utilisez les outils XFS (xfs_repair, xfs_metadump), pas fsck (qui ne s’applique pas à XFS de la même façon).

Tâche 3 : Vérifier les logs du noyau pour des erreurs d’E/S avant de « réparer » la corruption

cr0x@server:~$ dmesg -T | egrep -i "I/O error|blk_update_request|nvme|ata|reset|xfs|ext4" | tail -n 25
[Mon Dec 29 09:41:11 2025] nvme nvme0: I/O 123 QID 6 timeout, aborting
[Mon Dec 29 09:41:12 2025] nvme nvme0: Abort status: 0x371
[Mon Dec 29 09:41:14 2025] XFS (nvme0n1p3): log I/O error -5
[Mon Dec 29 09:41:14 2025] XFS (nvme0n1p3): Log I/O Error Detected. Shutting down filesystem
[Mon Dec 29 09:41:14 2025] XFS (nvme0n1p3): Please unmount the filesystem and rectify the problem(s)

Signification : Ce n’est pas une « corruption aléatoire du système de fichiers ». L’erreur d’I/O du journal est causée par des timeouts NVMe.

Décision : Traitez le périphérique comme suspect. Capturez les logs, considérez les problèmes de contrôleur/firmware/PCIe, et priorisez l’imagerie/snapshot plutôt que des réparations agressives.

Tâche 4 : Vérification SMART rapide pour disques SATA/SAS (si applicable)

cr0x@server:~$ sudo smartctl -H -A /dev/sda
smartctl 7.4 2023-08-01 r5530 [x86_64-linux-6.8.0-xx-generic] (local build)
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  5 Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  Always       -       0
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       0
199 UDMA_CRC_Error_Count    0x003e   199   199   000    Old_age   Always       -       12

Signification : Les erreurs CRC suggèrent des problèmes de câblage/contrôleur même si le disque « passe ». Cela peut corrompre des écritures et provoquer des arrêts du système de fichiers.

Décision : Réparez le transport (câble/backplane/HBA) avant la réparation. Si c’est un serveur en baie hot-swap, reseatez/remplacez et retestez.

Tâche 5 : Vérification santé NVMe (courant dans les flottes Ubuntu 24.04)

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

Signification : Pas d’erreurs média, mais des entrées d’erreurs existent. Combiné aux timeouts dans dmesg, cela sent les problèmes de contrôleur/chemin plutôt que la mort du NAND.

Décision : Récupérez le log d’erreurs NVMe, vérifiez les événements PCIe AER, envisagez une mise à jour de firmware. Toujours snapshotter/imager avant réparation si les données sont critiques.

Tâche 6 : Confirmer l’état mdraid avant de toucher les systèmes de fichiers au-dessus

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>

Signification : RAID1 est sain ([UU]).

Décision : Il est au moins sûr de poursuivre les diagnostics au niveau du système de fichiers. Si vous aviez vu [U_] ou une reconstruction, vous vous arrêteriez et stabiliseriez d’abord.

Tâche 7 : Confirmer la disposition LVM et quel LV vous allez opérer

cr0x@server:~$ sudo lvs -a -o lv_name,vg_name,lv_size,lv_attr,devices
  LV   VG  LSize   Attr       Devices
  root vg0 80.00g  -wi-ao----  /dev/nvme0n1p2(0)
  var  vg0 200.00g -wi-ao----  /dev/nvme0n1p2(20480)
  home vg0 500.00g -wi-ao----  /dev/nvme0n1p2(71680)

Signification : /var peut être un LV, pas une partition brute (dans cet exemple il est sur nvme0n1p2, pas p3). C’est là que les gens réparent la mauvaise chose.

Décision : Réparez le bon périphérique bloc (chemin LV comme /dev/vg0/var) et cessez d’utiliser des hypothèses sur les partitions.

Tâche 8 : Faire un snapshot avant la réparation (LVM)

cr0x@server:~$ sudo lvcreate -L 20G -s -n var-pre-repair /dev/vg0/var
  Logical volume "var-pre-repair" created.

Signification : Vous avez maintenant un snapshot copy-on-write. Ce n’est pas une sauvegarde complète, mais c’est un point de retour contre les erreurs de réparation.

Décision : Effectuez la réparation sur le LV d’origine seulement après avoir vérifié que l’espace du snapshot est suffisant pour les écritures anticipées pendant la réparation (les scans de métadonnées peuvent être gourmands en écritures).

Tâche 9 : Pour ext4, commencez par une vérification non destructive

cr0x@server:~$ sudo e2fsck -fn /dev/vg0/home
e2fsck 1.47.0 (5-Feb-2023)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/home: ***** FILE SYSTEM WAS MODIFIED *****
/home: 219842/32768000 files (0.2% non-contiguous), 4123712/131072000 blocks

Signification : Même avec -n (sans modifications), il signale « would be modified ». Cela indique des incohérences que e2fsck peut corriger.

Décision : Si le matériel paraît stable et que vous avez un snapshot/image, procédez à une passe de correction (e2fsck -fy) pendant une fenêtre d’indisponibilité. Si le matériel est instable, imagez d’abord.

Tâche 10 : Pour ext4, exécutez une passe de correction (contrôlée, journalisée)

cr0x@server:~$ sudo e2fsck -fy /dev/vg0/home
e2fsck 1.47.0 (5-Feb-2023)
Pass 1: Checking inodes, blocks, and sizes
Inode 924518 has illegal block(s).  Clear? yes
Pass 2: Checking directory structure
Entry 'cache' in /user/alex (924612) has deleted/unused inode 1032211.  Clear? yes
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/home: ***** FILE SYSTEM WAS MODIFIED *****
/home: 219840/32768000 files (0.2% non-contiguous), 4123690/131072000 blocks

Signification : Il a corrigé de réelles incohérences de métadonnées. Attendez-vous à ce que certains fichiers soient déplacés dans lost+found si des entrées de répertoire ont été endommagées.

Décision : Montez et validez l’intégrité au niveau applicatif (bases de données, boîtes mail, etc.). La cohérence du système de fichiers ne garantit pas la cohérence applicative.

Tâche 11 : Pour XFS, simulation de réparation d’abord

cr0x@server:~$ sudo xfs_repair -n /dev/vg0/var
Phase 1 - find and verify superblock...
Phase 2 - using internal log
        - zero log...
would zero log
Phase 3 - for each AG...
        - scan (but don't clear) agi unlinked lists...
        - process known inodes and perform inode discovery...
Phase 4 - check for duplicate blocks...
Phase 5 - rebuild AG headers and trees...
Phase 6 - check inode connectivity...
Phase 7 - verify link counts...
No modify flag set, skipping filesystem flush and exiting.

Signification : L’outil vous dit qu’il voudrait zéroter le journal. C’est le grand panneau rouge : le journal ne peut pas être rejoué tel quel.

Décision : Décidez si vous pouvez accepter de perdre des opérations de métadonnées récentes. Si c’est un volume de base de données, envisagez de restaurer depuis des sauvegardes applicatives plutôt que de forcer l’abandon du journal.

Tâche 12 : Pour XFS, tenter un montage en lecture seule pour copier les données (si faisable)

cr0x@server:~$ sudo mount -o ro,norecovery /dev/vg0/var /mnt/var_ro
mount: /mnt/var_ro: mount(2) system call failed: Structure needs cleaning.

Signification : Même en lecture seule sans récupération, le montage échoue. Les métadonnées sont probablement endommagées au-delà de la tolérance du montage.

Décision : Passez à la planification de xfs_repair — idéalement sur un snapshot/image.

Tâche 13 : Pour XFS, exécuter la réparation (sans -L sauf si vous l’assumez)

cr0x@server:~$ sudo xfs_repair /dev/vg0/var
Phase 1 - find and verify superblock...
Phase 2 - using internal log
        - scan filesystem freespace and inode maps...
        - found corruption in filesystem
        - resetting log...
Phase 3 - for each AG...
        - scan and clear agi unlinked lists...
        - process known inodes and perform inode discovery...
Phase 4 - check for duplicate blocks...
Phase 5 - rebuild AG headers and trees...
Phase 6 - check inode connectivity...
Phase 7 - verify link counts...
done

Signification : Il a réinitialisé le journal dans le cadre de la réparation (certaines réparations impliquent la gestion du journal). Dans d’autres situations vous serez forcé de choisir -L.

Décision : Montez et validez. Si des fichiers manquent ou des répertoires sont étranges, prévoyez une restauration depuis les sauvegardes ou une réparation au niveau applicatif.

Tâche 14 : Pour XFS quand le journal est irrécupérable : la décision explicite -L

cr0x@server:~$ sudo xfs_repair -L /dev/vg0/var
Phase 1 - find and verify superblock...
Phase 2 - using internal log
        - zero log...
        - scan filesystem freespace and inode maps...
Phase 3 - for each AG...
Phase 4 - check for duplicate blocks...
Phase 5 - rebuild AG headers and trees...
Phase 6 - check inode connectivity...
Phase 7 - verify link counts...
done

Signification : Vous avez abandonné le journal. Toutes les transactions de métadonnées présentes uniquement dans le journal ont disparu. Cela peut orpheliner des fichiers récents ou annuler des changements de répertoire.

Décision : Ne faites cela que si (a) vous avez des sauvegardes, (b) vous avez accepté la perte des changements récents, et (c) l’alternative est « le système de fichiers reste indisponible ». Documentez le choix.

Tâche 15 : Valider le montage et vérifier les basculements en lecture seule après réparation

cr0x@server:~$ sudo mount /dev/vg0/var /var
cr0x@server:~$ findmnt -no OPTIONS /var
rw,relatime,attr2,inode64,logbufs=8,logbsize=32k

Signification : Monté en lecture-écriture avec des options XFS normales. Bon signe.

Décision : Surveillez dmesg pour de nouvelles erreurs d’E/S. Si cela repasse en lecture seule, vous poursuivez une instabilité matérielle, pas un crash ponctuel.

Tâche 16 : Vérifier le journal ext4 et les fonctionnalités (utile pour les problèmes d’outils anciens)

cr0x@server:~$ sudo tune2fs -l /dev/vg0/home | egrep -i "Filesystem features|Filesystem state|Errors behavior|Journal"
Filesystem state:         clean
Errors behavior:          Continue
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype extent 64bit metadata_csum
Journal inode:            8

Signification : Les fonctionnalités modernes d’ext4 comme metadata_csum exigent un e2fsck suffisamment récent. Ubuntu 24.04 est OK ; des médias de secours anciens peuvent ne pas l’être.

Décision : Si vous êtes démarré dans un environnement ancien et qu’il se plaint de fonctionnalités inconnues, passez à une image de secours contemporaine plutôt que « désactiver des fonctionnalités » dans la panique.

Tâche 17 : Confirmer la version des métadonnées XFS (v5 vs plus ancien)

cr0x@server:~$ sudo xfs_info /dev/vg0/var
meta-data=/dev/vg0/var          isize=512    agcount=64, agsize=819200 blks
         =                       sectsz=4096  attr=2, projid32bit=1
         =                       crc=1        finobt=1, sparse=1, rmapbt=0
data     =                       bsize=4096  blocks=52428800, imaxpct=25
naming   =version 2              bsize=4096   ascii-ci=0, ftype=1
log      =internal               bsize=4096   blocks=25600, version=2
realtime =none                   extsz=4096   blocks=0, rtextents=0

Signification : crc=1 indique des checksums de métadonnées (fonctionnalités XFS v5). Encore une fois : des outils anciens peuvent mal se comporter.

Décision : Assurez-vous que votre environnement de secours est contemporain (Ubuntu 24.04 ou équivalent) avant d’interpréter des erreurs comme de la « corruption ».

Tâche 18 : Quand le disque meurt, imagez-le avec ddrescue (pas dd)

cr0x@server:~$ sudo ddrescue -f -n /dev/nvme0n1 /mnt/recovery/nvme0n1.img /mnt/recovery/nvme0n1.map
GNU ddrescue 1.28
Press Ctrl-C to interrupt
Initial status (read from mapfile)
rescued:      0 B,  errsize:      0 B,  current rate:       0 B/s
ipos:         0 B,   errors:       0,    average rate:       0 B/s
opos:         0 B, run time:         0s,  remaining time:         0s
Finished

Signification : Dans des exécutions réelles vous verrez des octets sauvés, la taille d’erreur et le nombre d’erreurs. Le fichier map vous permet de reprendre et de faire des tentatives intelligentes plus tard.

Décision : Effectuez les réparations de système de fichiers sur l’image (loopback) ou sur un disque cloné. Ne stressez pas une source défaillante avec des scans de métadonnées répétés.

Trois mini-récits d’entreprise depuis les tranchées de réparation

1) L’incident causé par une mauvaise présomption

Ils avaient une flotte de VM Ubuntu, la plupart en ext4, parce que l’image de base le livrait il y a des années. Un jour un noeud analytique critique a cessé de monter /data. L’astreignant a vu « Structure needs cleaning », a haussé les épaules et a tapé fsck -y /dev/sdb parce que la mémoire musculaire est invincible.

La commande n’a rien « réparé ». Elle n’a pas non plus échoué de façon évidente qui déclencherait la panique. C’est une partie du piège : fsck générique peut sélectionner des helpers, mais quand le type de FS est mal identifié ou que le périphérique est erroné, vous pouvez ne rien faire d’utile ou — pire — endommager un système de fichiers adjacent parce que vous étiez pointé sur la mauvaise couche (partition vs LV vs disque entier).

Le vrai problème : /data était en XFS sur un LV LVM, et le périphérique qu’ils ont réparé était la partition PV sous-jacente. Ils ont donc exécuté un outil inapproprié, sur une cible qui n’était pas le système de fichiers, tandis que le LV réel continuait de poser problème.

Quand un ingénieur senior est intervenu, il a fait les étapes peu glamours : lsblk -f, lvs et findmnt. Puis xfs_repair -n a montré que le journal était corrompu. La solution a été xfs_repair -L — perte acceptée des dernières minutes d’opérations de répertoire — suivie d’un rétablissement d’un petit ensemble de sorties applicatives depuis en amont.

La leçon réelle n’était pas « XFS est effrayant ». C’était que la récupération d’un système de fichiers est d’abord un problème de cartographie. Si vous ne savez pas quel périphérique bloc backe le point de montage, vous jouez au hasard avec le weekend de quelqu’un d’autre.

2) L’optimisation qui s’est retournée contre eux

Une équipe stockage voulait un ingestion plus rapide. Ils ont déplacé une charge à gros churn vers XFS et ont tuné pour le débit : plus grands buffers de journal, parallélisme agressif, et des écritures applicatives qui comptaient sur « le système de fichiers s’en occupera ». Les performances ont augmenté. Tout le monde s’est félicité de la façon dont les entreprises se félicitent : discrètement, et seulement après que le tableau de bord soit vert.

Puis un événement d’alimentation a frappé une baie avec un transfert UPS instable. Les serveurs ont survécu, pour la plupart. Mais plusieurs nœuds sont revenus avec XFS se plaignant de la récupération du journal. L’instinct de l’équipe a été de standardiser une étape de récupération automatique : si le montage échoue, exécuter xfs_repair -L et redémarrer. Ça a marché en test. Ça a marché en staging. Ça a « marché » exactement comme un couteau affûté « marche ».

En production, cela a rétabli les montages, mais les données applicatives étaient incohérentes. Certains répertoires avaient perdu des fichiers récemment créés. Des fichiers existaient avec une taille zéro. Le pire : le service était « up », donc les systèmes aval consommaient de mauvais résultats avant que personne ne remarque. Cela a coûté plus qu’une heure de downtime supplémentaire n’aurait coûté.

Le retour de bâton n’était pas XFS. C’était l’hypothèse que « le système de fichiers disponible » équivaut à « l’application correcte », et que l’abandon du journal est un comportement par défaut sûr. L’abandon du journal XFS est un dernier recours. Ce n’est pas une ligne de script de redémarrage.

Après coup, ils ont appliqué deux politiques : (1) ne jamais lancer automatiquement l’abandon de journal ; exiger une approbation humaine, et (2) pour les ensembles de données critiques, basculer et restaurer depuis des points de contrôle connus plutôt que forcer le système de fichiers à boiter.

3) La pratique ennuyeuse mais correcte qui a sauvé la situation

Une entreprise de services financiers avait une règle qui énervait tout le monde : avant tout outil de réparation, prendre un snapshot ou cloner. Aucune exception. Les ingénieurs plaisantaient en disant que la politique de snapshot existait pour les protéger d’eux-mêmes. Cette plaisanterie n’était pas fausse.

Un trimestre, une VM exécutant des traitements par lots a subi un hic de stockage côté hôte. Le noyau invité a commencé à logger des erreurs d’E/S, puis a remonté des volumes ext4 en lecture seule. Cela seul était un bon comportement : ext4 essayant d’empêcher d’autres dommages. La pression était énorme car les retards en fin de trimestre ont une capacité particulière à escalader dans la hiérarchie managériale.

L’astreignant a suivi le playbook : arrêter les écritures, confirmer la stabilité matérielle côté hyperviseur, prendre un snapshot LVM sur la couche stockage, puis lancer e2fsck -fn pour jauger les dégâts. Le rapport montrait des problèmes d’inodes et de répertoires, réparables. Ils ont exécuté e2fsck -fy sur le clone snapshot en premier, validé les contrôles applicatifs, puis réparé le volume réel.

Pendant la réparation, e2fsck a pris une décision qui aurait été inconfortable sans point de retour : il a effacé quelques entrées de répertoire pointant vers des inodes invalides. Le volume est revenu propre, mais un arbre de répertoire a été partiellement déplacé vers lost+found. Parce qu’ils avaient le snapshot, ils ont pu récupérer des fichiers spécifiques par inode depuis l’état pré-réparation plutôt que restaurer tout le monde.

Rien d’héroïque ne s’est produit. C’est le point. La politique ennuyeuse — snapshot d’abord — a transformé un incident stressant en une maintenance bornée.

Erreurs fréquentes : symptômes → cause racine → correction

1) « J’ai lancé fsck et ça n’a pas aidé »

Symptômes : Vous avez lancé fsck, le problème persiste, ou il a signalé « bad magic number ».

Cause racine : Mauvais type de système de fichiers ou mauvais périphérique ciblé (partition/PV au lieu de LV, périphérique md vs disque membre).

Correction : Ré-identifiez avec lsblk -f et findmnt. Utilisez e2fsck seulement pour ext* et xfs_repair pour XFS. Réparez la bonne couche (par ex. /dev/vg0/var, pas /dev/nvme0n1p2).

2) XFS ne monte pas et vous avez immédiatement utilisé `xfs_repair -L`

Symptômes : Le montage fonctionne après la réparation, mais des fichiers « récents » manquent ou des répertoires semblent restaurés en arrière.

Cause racine : L’abandon du journal supprime des transactions de métadonnées qui n’avaient pas été commises dans les structures principales.

Correction : Préférez xfs_repair -n d’abord ; si vous devez utiliser -L, documentez-le et validez l’intégrité applicative. Restaurez les sorties manquantes depuis sauvegardes/points de contrôle. Pour les bases de données, priorisez les outils de récupération applicative et les sauvegardes plutôt que les prouesses système de fichiers.

3) ext4 continue de remonter en lecture seule après que fsck l’ait « réparé »

Symptômes : ext4 monte, puis repasse en ro ; les logs du noyau montrent des erreurs d’E/S.

Cause racine : Erreurs sous-jacentes de disque/contrôleur ou chemin instable, pas des métadonnées non résolues.

Correction : Vérifiez dmesg et les logs SMART/NVMe. Remplacez le matériel, réparez le câblage/backplane, ou migrez les données hors du périphérique. Les outils de réparation ne rendent pas un bus instable fiable.

4) Les réparations prennent une éternité et vous supposez que l’outil est planté

Symptômes : e2fsck ou xfs_repair tourne pendant des heures sur des volumes multi-TB.

Cause racine : Les scans complets de métadonnées sont coûteux ; aussi, un disque avec des retries lents rend tout apparemment bloqué.

Correction : Confirmez que le disque n’émet pas de retries/timeouts dans dmesg. Utilisez iostat pour voir si l’I/O progresse. Si le matériel est malade, imagez d’abord avec ddrescue.

5) « Structure needs cleaning » sur XFS et vous essayez de monter en lecture-écriture quand même

Symptômes : Le montage échoue ; vous essayez différentes options de montage ; finalement vous obtenez un montage mais la corruption s’aggrave.

Cause racine : Forcer des montages ou le replay sur des métadonnées endommagées peut amplifier les dégâts, surtout en conservant des écritures.

Correction : Arrêtez les écritures. Utilisez xfs_repair -n et décidez : copiez depuis RO si possible, ou réparez hors ligne sur un snapshot.

6) Vous avez réparé le système de fichiers mais l’application est toujours cassée

Symptômes : PostgreSQL ne démarre pas, MySQL se plaint, ou une file a des segments corrompus, bien que fsck/réparation soit propre.

Cause racine : La cohérence du système de fichiers n’est pas la cohérence transactionnelle de l’application. Les crashs et abandons de journal peuvent briser des invariants d’un niveau supérieur.

Correction : Exécutez la récupération applicative (récupération DB, replay WAL, reconstruire index) ou restaurez depuis des sauvegardes connues bonnes. Traitez la réparation du système de fichiers comme « rendre montable », pas « rendre correct ».

Checklists / plan pas à pas

Checklist A : Les 10 premières minutes (tout système de fichiers)

Arrêter les écritures : arrêter les services, désactiver cron/timers si nécessaire.
Capturer des preuves : sauvegarder la sortie de dmesg et les logs pertinents.
Confirmer le mapping : findmnt, lsblk -f, lvs, /proc/mdstat.
Vérifier les indicateurs matériels : logs SMART/NVMe, statut RAID, logs contrôleur.
Décider du snapshot/image : si la valeur des données est élevée, snapshot/image maintenant, pas plus tard.

Checklist B : ordre de récupération ext4 (sécurité d’abord)

Démonter le système de fichiers (préféré) ou démarrer en mode secours.
Exécuter une vérification non destructive : e2fsck -fn /dev/...
Si des erreurs existent et que le matériel est stable : exécuter e2fsck -fy /dev/...
Monter d’abord en lecture seule si vous êtes nerveux, puis en lecture-écriture.
Vérifier dmesg pour de nouvelles erreurs ; si c’est propre, poursuivre la validation applicative.

Checklist C : ordre de récupération XFS (diagnostiquer, puis réparer délibérément)

Démonter le système de fichiers (requis pour une vraie réparation).
Tenter de monter en lecture seule avec risque minimal (optionnel) : mount -o ro,norecovery si cela fonctionne, copiez les données.
Exécuter xfs_repair -n pour voir ce que la réparation ferait.
Si le journal est en cause, décidez si l’abandon du journal est acceptable ; préférez la restauration plutôt que -L pour des charges transactionnelles critiques.
Exécuter xfs_repair (et seulement si nécessaire, xfs_repair -L).
Monter et valider ; exécuter les contrôles applicatifs.

Checklist D : Quand le matériel est suspect

Arrêter immédiatement toutes les écritures.
Imager avec ddrescue ou cloner via votre plateforme de stockage.
Exécuter les réparations sur le clone/l’image.
Prévoyez remplacement/migration ; ne réparez pas et n’espérez pas sur du matériel instable.

FAQ

1) Puis-je exécuter `fsck` sur XFS ?

Pas de la manière dont vous l’entendez. XFS utilise xfs_repair. fsck générique ne fera pas ce qu’il faut pour réparer les métadonnées XFS et peut vous faire perdre un temps précieux — ou pire, cibler le mauvais périphérique.

2) Dois-je toujours démonter avant d’exécuter les outils de réparation ?

Oui pour les réparations réelles. ext4 e2fsck et XFS xfs_repair sont destinés à des réparations hors-ligne. Les lancer sur un système de fichiers monté est une excellente manière d’obtenir une corruption « réparée » plus de corruption nouvelle.

3) Pourquoi `xfs_repair -n` est-il si important ?

Parce que la gestion du journal XFS est un point de décision. -n montre ce que l’outil veut faire — en particulier s’il veut zéroter le journal — avant que vous ne vous engagiez à perdre des transactions de métadonnées récentes.

4) Quand `xfs_repair -L` est-il justifié ?

Quand le système de fichiers est indisponible, le replay du journal ne peut pas réussir, et vous acceptez de perdre des changements métadonnées récents. Utilisez-le en dernier recours, de préférence après snapshot/imagerie et après avoir envisagé des restaurations pour les charges transactionnelles.

5) ext4 indique « clean » mais mon appli a toujours des données manquantes. Comment ?

La cohérence du système de fichiers concerne les structures de métadonnées, pas la sémantique transactionnelle de votre application. Un crash peut laisser une application avec des écritures partielles ou des fsync manquants même si le système de fichiers est parfaitement cohérent.

6) Et si l’environnement de secours est plus ancien que les fonctionnalités du système de fichiers ?

Vous pouvez obtenir des rapports de « corruption » erronés ou un refus d’opérer. Sur ext4 et XFS de l’ère Ubuntu 24.04 (avec checksums de métadonnées), utilisez un système de secours contemporain. Ne tentez pas de désactiver des fonctionnalités comme raccourci.

7) Dois-je réparer sur le disque original ou sur un clone ?

Si les données ont de la valeur et que vous le pouvez, réparez sur un clone/snapshot/image. Cela vous protège des erreurs humaines et de la dégradation matérielle pendant la réparation. Si vous ne pouvez pas, au moins faites un snapshot si vous êtes sur LVM ou une plateforme de stockage qui le supporte.

8) Comment savoir si la « corruption » est vraiment matérielle ?

Les logs du noyau montrant des timeouts, resets, erreurs d’E/S, erreurs CRC ou aborts NVMe sont votre signal le plus fort. Les logs SMART/NVMe et la santé du contrôleur RAID confirment le schéma. Si ceux-ci existent, stabilisez le matériel d’abord.

9) Est-ce qu’ext4 est « plus facile » à récupérer que XFS ?

Dans de nombreux cas routiniers, la récupération ext4 paraît plus linéaire parce que e2fsck est le chemin standard. XFS est extrêmement robuste, mais la décision concernant le journal et le comportement de réparation demandent un peu plus de précaution.

10) Après la réparation, que dois-je valider ?

Options de montage (rw vs ro), logs noyau, comptes d’espace libre/inodes, et — surtout — contrôles d’intégrité applicative (vérifs DB, replay WAL, reconstruction de files d’attente, checksums si vous en avez).

Prochaines étapes concrètes

Si vous êtes face à un point de montage cassé sur Ubuntu 24.04, ne commencez pas par un réparateur. Commencez par le contrôle : arrêtez les écritures, confirmez le mapping du périphérique et déterminez si le matériel vous trahit. Ensuite, choisissez votre « premier outil système de fichiers » en fonction du modèle de panne du FS :

ext4 : commencez par e2fsck -fn pour évaluer, puis e2fsck -fy quand vous êtes prêt à engager des changements.
XFS : commencez par xfs_repair -n. Traitez l’abandon du journal (-L) comme un compromis délibéré, pas un réflexe.

Faites une chose de plus que votre futur vous appréciera : notez ce que vous avez vu dans dmesg, quel périphérique vous avez opéré, quels flags vous avez utilisés et pourquoi. Les rétrospectives d’incident aiment les faits. Les systèmes de fichiers aussi.