Vérifier et réparer un système de fichiers démonté : fsck, xfs_repair et btrfs check

Objectif

Vérifier l'intégrité d'un système de fichiers Linux et ne le réparer que si l'outil et le mode employés sont sûrs compte tenu de l'état de ce système de fichiers.

Prérequis

Le système de fichiers cible doit être démonté (s'il s'agit du système de fichiers racine, démarrer d'abord en mode rescue/emergency ou depuis un système live/de secours) ; accès root ; sauvegardes récentes si la réparation risque d'être destructive.

Étapes

1. Vérifier que le système de fichiers est démonté avant de le contrôler. Le manuel d'e2fsck indique clairement qu'il ne faut pas l'exécuter sur un système de fichiers monté, et que même lorsque -n rend l'opération techniquement sûre, les résultats affichés sur un système monté ne sont pas valides. Le frontal générique fsck appelle l'outil propre au système de fichiers (fsck.ext4, etc.).
2. Pour ext2/3/4 : lancer d'abord e2fsck -fn /dev/<device> (vérification complète forcée, sans aucune modification), puis e2fsck -f /dev/<device> pour réparer de façon interactive, ou -y pour répondre « yes » à toutes les questions sans intervention — ce qui accepte aussi les corrections destructives.
3. Pour XFS, le fsck générique appelle fsck.xfs, qui se contente normalement de retourner 0 ; il faut utiliser xfs_repair, qui refuse de travailler sur un système de fichiers monté. Commencer par xfs_repair -n /dev/<device> — le « no modify mode » : il indique ce qui serait réparé sans rien modifier, et retourne 1 si une corruption a été détectée, 0 sinon. Sans -n, il retourne 0 s'il se termine correctement, 1 en cas d'erreur d'exécution (relancer la commande) et 2 s'il ne peut pas continuer parce que le journal est sale. Si le journal est sale, monter puis démonter une fois le système de fichiers (sur une machine de même architecture de processeur) pour que le noyau rejoue le journal, puis relancer. xfs_repair -L remet le journal à zéro à la place : toutes les mises à jour de métadonnées en cours au moment du plantage sont perdues, ce qui, d'après le manuel, peut causer des dégâts importants — à n'utiliser qu'en dernier recours, après une sauvegarde sous forme d'image.
4. Pour Btrfs : btrfs check ne modifie pas le périphérique par défaut (--readonly ne fait que le confirmer) ; btrfsck est un alias obsolète. Son manuel déconseille --repair « unless you are advised to do so by a developer or an experienced user » (sauf conseil d'un développeur ou d'un utilisateur expérimenté) et précise qu'aucun outil de vérification ne peut corriger tous les types de corruption. Lorsqu'un snapshot ou une sauvegarde existe, préférer la restauration à --repair ; sur un système de fichiers monté, btrfs scrub start <mountpoint> vérifie les sommes de contrôle à chaud, ce qui n'est pas une vérification structurelle.
5. Pour forcer la vérification du système de fichiers racine lors d'un seul démarrage, ajouter fsck.mode=force dans le menu de démarrage (s'il est conservé dans la configuration, il force une vérification à chaque démarrage ; auto est la valeur par défaut, skip désactive les vérifications) ; fsck.repair= (preen, yes, no) détermine avec quelle agressivité systemd-fsck répond aux demandes de réparation pendant cette vérification automatique.
6. Interpréter le code de sortie du fsck générique comme une somme binaire de bits : 0 aucune erreur, 1 erreurs corrigées, 2 le système doit être redémarré, 4 erreurs non corrigées, les bits supérieurs signalant des échecs opérationnels ; les codes de plusieurs systèmes de fichiers vérifiés en une seule exécution sont combinés par OU binaire, donc vérifier un seul système de fichiers par appel lorsqu'un script a besoin d'un résultat précis.

Résultat attendu

Une vérification propre ne signale aucune corruption (code de sortie 0, ou code 0 pour xfs_repair -n) ; après une réparation, le système de fichiers peut être monté et le résumé de l'outil indique ce qui a été corrigé.

Limites et base de vérification

XFS et Btrfs définissent leurs propres codes de sortie et options — ne pas supposer qu'ils correspondent à ceux de fsck. btrfs check --repair ne fonctionne pas encore avec --mode=lowmem. Faire une sauvegarde (ou un snapshot) avant toute réparation hors mode d'essai : un outil de vérification peut aggraver l'état d'un système de fichiers endommagé.