Linux sans magie #55 — Vérifier et réparer un filesystem Linux

Un serveur redémarre après une panne électrique. Un volume ext4 refuse de se monter, ou ses journaux contiennent des erreurs de métadonnées. Le réflexe peut être de lancer fsck -y sur le premier périphérique repéré. C'est pourtant une mauvaise approche : une réparation de filesystem peut modifier ou supprimer des références à des données, et une erreur de cible peut affecter un autre volume.

Après les articles sur les disques pleins (#52), les filesystems en lecture seule (#53) et les inodes (#54), nous terminons cette séquence par une méthode de préparation : identifier le bon filesystem, rechercher la cause de l'erreur, préserver les données, choisir le bon outil et contrôler la reprise. Les exemples concernent surtout ext4 et une fenêtre de maintenance hors ligne.

Vérifier n'est pas forcément réparer

Un filesystem gère les fichiers, répertoires, blocs et métadonnées qui donnent du sens aux données enregistrées. Une coupure pendant des écritures, une défaillance de stockage ou un bogue peuvent laisser des structures incohérentes.

Le contrôle cherche ces incohérences. La réparation peut modifier des structures : réconcilier des compteurs, déplacer des entrées orphelines, reconstruire des références ou rendre des objets auparavant accessibles plus difficiles à retrouver. Une réparation réussie ne prouve pas l'intégrité des contenus applicatifs.

Application → point de montage /srv/data → ext4
                                         ↓
                                  /dev/mapper/data_lv
                                         ↓
                                  LVM / RAID / disque

Le vérificateur ext4 vise le périphérique contenant ext4,
pas nécessairement le disque physique situé en dessous.

La couche d'assemblage compte. Si ext4 est au-dessus d'un volume LVM, d'un mapping LUKS ou d'un RAID MD, un diagnostic exécuté sur le mauvais membre ne contrôle pas correctement le filesystem et peut provoquer des dommages.

fsck et e2fsck : deux rôles différents

fsck est un outil générique de lancement qui sélectionne un programme adapté au type de filesystem, généralement nommé fsck.<type>. Sur un ext4, il peut invoquer e2fsck, l'outil spécialisé des familles ext2, ext3 et ext4.

e2fsck connaît leurs superblocks, groupes de blocs, inodes, répertoires et mécanismes de journalisation. Il peut effectuer un contrôle et proposer des corrections. Le comportement dépend des options et de l'état du volume.

Mais fsck n'implique pas une procédure commune à tous les filesystems :

Filesystem	Outil ou approche	Point d'attention
ext2 / ext3 / ext4	`e2fsck`	Contrôle normalement sur filesystem non monté
XFS	`xfs_repair`	`fsck.xfs` est normalement un programme factice qui termine avec succès
Btrfs	Outils et procédures Btrfs dédiés	`btrfs check --repair` n'est pas un geste de première intention
FAT	`fsck.fat`	Options et contraintes propres au format

Sur XFS, une récupération de journal peut intervenir lors d'un montage après arrêt non propre ; ce n'est pas la même procédure qu'un e2fsck ext4. Un code retour 0 de fsck.xfs ne signifie pas qu'un examen approfondi de XFS a été réalisé.

Étape 1 — Évaluer l'incident avant les commandes

Avant de parler réparation, demandez-vous si le problème vient du filesystem ou d'une couche plus basse. Les symptômes incluent un montage impossible, Structure needs cleaning, I/O error, des erreurs ext4 ou un passage en lecture seule. Un disque devenu inaccessible ou un RAID dégradé peuvent produire des conséquences semblables.

Commencez par des commandes d'inventaire :

findmnt -o SOURCE,TARGET,FSTYPE,OPTIONS
lsblk -o NAME,PATH,FSTYPE,TYPE,SIZE,RO,MOUNTPOINTS
lsblk -f
journalctl -k -b --no-pager -n 200
cat /proc/mdstat

Sur un hôte sans RAID logiciel MD, /proc/mdstat n'apporte pas nécessairement de signal utile. Avec LVM, sudo pvs et sudo lvs peuvent compléter la cartographie. Si le disque est distant ou géré par un hyperviseur, consultez aussi la supervision de la plateforme.

Conservez les horodatages et les erreurs d'E/S : si le support tombe physiquement en panne, insister avec un outil de réparation logique peut aggraver l'état ou multiplier les lectures sur un matériel instable.

Étape 2 — Identifier sans ambiguïté la cible

Dans cet exemple, /srv/data est un point de montage fictif et le volume ext4 réside, après vérification, sur /dev/mapper/data_lv. Ce dernier nom reste un exemple : il ne doit jamais être copié sans validation sur votre machine.

findmnt --target /srv/data -o SOURCE,TARGET,FSTYPE,OPTIONS
lsblk -f
blkid

Ces commandes servent à comparer le filesystem annoncé, son UUID, le chemin réellement monté et les éventuelles couches d'abstraction. blkid peut exiger des privilèges pour découvrir tous les périphériques ; une sortie partielle ne prouve pas qu'un volume est absent.

Ne lancez pas e2fsck sur un disque entier contenant des partitions, sur un membre isolé de RAID ou sur le périphérique LUKS brut : ciblez le périphérique qui porte réellement le filesystem ext4.

Si le montage n'est plus actif, reconstruisez la topologie à partir de l'inventaire, des métadonnées de gestion et de la configuration validée, plutôt que de deviner un chemin /dev/sdX.

Étape 3 — Préparer l'arrêt et la récupération

Une réparation n'est pas une opération normale à exécuter au milieu de flux d'écritures applicatives. Préparez :

l'arrêt propre des services et l'identification des volumes qu'ils utilisent ;
une sauvegarde indépendante et restaurable, adaptée à l'importance des données ;
une fenêtre de maintenance et, pour le volume système, un environnement de secours ;
des critères d'arrêt si des erreurs matérielles apparaissent ;
l'accord du responsable du service sur les risques de perte et l'indisponibilité.

Pour ext4, e2fsck ne doit généralement pas être exécuté sur un filesystem monté. La documentation signale une exception étroite pour un contrôle -n sans options de modification particulières, mais précise que les résultats sur filesystem monté ne sont pas fiables. En pratique, planifiez le contrôle hors ligne et démonté.

Un snapshot de stockage peut parfois aider à préserver un état pour l'analyse, mais il ne remplace ni une sauvegarde indépendante ni une stratégie de récupération. Vérifiez sa cohérence et les contraintes de la pile technique avant de vous y fier.

Étape 4 — Examiner les options sans réparer à l'aveugle

Deux commandes montrent l'intention des outils, mais ne réalisent aucune réparation :

fsck -N -t ext4 /dev/mapper/data_lv
e2fsck -V

fsck -N demande d'afficher les opérations qui seraient lancées au lieu de les exécuter. Il ne vérifie pas les structures du filesystem ; c'est un contrôle de sélection d'outil. e2fsck -V renseigne la version du programme installé.

Dans un environnement de maintenance où le volume ext4 est confirmé non monté, un contrôle sans correction peut être envisagé :

# À UTILISER UNIQUEMENT HORS LIGNE, SUR LE BON VOLUME EXT4
sudo e2fsck -n /dev/mapper/<volume-ext4-identifie>

L'option -n répond négativement aux questions de correction et ouvre le filesystem en lecture seule, sauf cas particuliers documentés. Elle ne garantit pas un diagnostic fiable sur un volume monté, et ne valide pas les contenus d'une base de données. Un contrôle peut solliciter fortement les disques : n'insistez pas si la couche matérielle signale des erreurs.

Le mode -f force un contrôle complet même si le filesystem paraît propre. Son emploi relève d'une procédure de maintenance, pas d'une commande à lancer systématiquement après toute alerte.

Étape 5 — Comprendre les options qui modifient les données

La documentation d'e2fsck présente plusieurs modes de réponse, à ne pas confondre :

Option	Effet général	Risque opérationnel
`-n`	Refuser les corrections proposées	Résultats non fiables si filesystem monté
`-p`	Réparer automatiquement les problèmes jugés sûrs	Modifications sans confirmation individuelle
`-y`	Répondre oui aux questions de correction	Modifications potentiellement importantes
`-f`	Forcer la vérification	Augmente la charge et la durée du contrôle

Ne considérez pas -y comme une option de confort. Accepter toutes les propositions peut rendre des données inaccessibles ou modifier fortement les métadonnées. Une réparation doit être conduite sur la base d'un diagnostic, d'une sauvegarde et d'une procédure de retour arrière approuvée.

Voici des formes de commandes présentées uniquement à des fins d'identification, pas à exécuter telles quelles :

# EXEMPLES DE MODIFICATION : validation technique et humaine indispensable
sudo e2fsck -p /dev/mapper/<volume-ext4-identifie>
sudo e2fsck -y /dev/mapper/<volume-ext4-identifie>

Même une intervention interactive peut nécessiter des choix complexes. Une erreur inattendue, des messages relatifs au matériel ou un très grand nombre de corrections doivent déclencher une réévaluation et éventuellement une expertise de récupération.

Et si le volume utilise XFS ou Btrfs ?

Pour XFS, l'approche documentée par Red Hat utilise xfs_repair -n pour un examen sans correction, sur un filesystem non monté, en respectant les conditions concernant son journal. Une réparation réelle s'effectue via xfs_repair dans la procédure prévue. L'option -L, qui efface le journal, peut provoquer des pertes significatives : ne l'utilisez jamais comme raccourci pour dépasser un montage impossible.

Pour Btrfs, les outils btrfs scrub, btrfs check et d'autres fonctions ciblées ont des objectifs distincts. Il ne faut pas assimiler une opération de scrub à une réparation hors ligne des métadonnées. Les mainteneurs de Btrfs déconseillent fortement btrfs check --repair sans avis spécialisé.

Un environnement de stockage distribué ou propriétaire demande sa propre procédure. Ne généralisez pas les commandes ext4 à tous les filesystems Linux.

Lire les codes de retour sans conclure trop vite

Les codes de sortie de fsck sont documentés sous forme de bits combinables :

Code	Signification
`0`	Aucune erreur signalée
`1`	Erreurs du filesystem corrigées
`2`	Redémarrage requis
`4`	Erreurs non corrigées
`8`	Erreur de fonctionnement
`16`	Mauvaise utilisation ou syntaxe
`32`	Vérification interrompue
`128`	Erreur de bibliothèque partagée

Un code 3, par exemple, peut représenter la combinaison 1 + 2. Il faut interpréter le code avec les messages complets et la documentation du checker effectivement utilisé, plutôt que d'en déduire « succès » ou « échec » sur un chiffre isolé.

Ces codes ne dispensent pas de tests applicatifs et de la vérification du bon volume.

Vérifier le résultat après intervention autorisée

Une fois une éventuelle réparation terminée, les services redémarrés selon le plan et le volume remonté, reprenez le même périmètre que durant le diagnostic :

findmnt --target /srv/data -o SOURCE,TARGET,FSTYPE,OPTIONS
lsblk -f
df -hT /srv/data
df -i /srv/data
journalctl -k --since "30 minutes ago" --no-pager

Vérifiez l'absence de nouvelles erreurs noyau, le type de filesystem, le bon montage et la capacité de l'application à fonctionner. Une écriture de test applicative contrôlée peut être prévue seulement après la validation de reprise. Contrôlez aussi la cohérence métier des données et l'état des sauvegardes.

Si les erreurs reviennent, ne répétez pas indéfiniment fsck. Reprenez le diagnostic de la chaîne physique, du contrôleur, du RAID, du volume logique ou du système de fichiers.

Sécurité, bonnes pratiques et limites

Un outil de vérification n'est pas une sauvegarde, un antivirus ni une garantie de récupération. Sa sortie peut contenir des noms de fichiers ou des détails d'infrastructure sensibles : traitez les journaux de réparation comme des données d'exploitation.

Ce guide ne propose aucune simulation de corruption, aucune exécution réelle d'e2fsck réparateur et aucune manipulation d'un volume de production. Les commandes d'observation sont illustratives ; celles qui peuvent modifier les métadonnées restent explicitement conditionnées à une procédure de maintenance.

La reprise doit documenter la cause supposée, les corrections approuvées, les effets observés, les données potentiellement perdues et les contrôles post-incident.

Retour arrière : quelles garanties ?

Il n'existe pas de rollback universel d'une réparation de filesystem : après réécriture de métadonnées, les structures d'origine peuvent avoir disparu. Certains outils disposent de mécanismes d'annulation limités, mais ils ne doivent pas être confondus avec une sauvegarde fiable.

Le véritable plan de récupération repose sur une copie indépendante et restaurable, des sauvegardes applicativement cohérentes lorsque nécessaire et, selon l'incident, la préservation préalable des supports. Sans ces garanties, une tentative de réparation peut compliquer la récupération.

Références officielles

Conclusion

La bonne question n'est pas « quelle commande va réparer le disque ? », mais quel filesystem est réellement concerné, quelle panne l'a affecté et quelle réparation peut être menée sans perdre les données encore récupérables ?

Identifiez la couche, préservez les données, choisissez le vérificateur propre au format et intervenez hors ligne lorsque la procédure l'impose. fsck et e2fsck sont utiles, mais ils ne remplacent ni l'analyse des causes ni une stratégie de sauvegarde testée.