Comment réparer en toute sécurité des systèmes de fichiers XFS et Btrfs corrompus sous Unraid sans risque de perte de données

Le disque est physiquement présent, SMART ne signale aucune erreur et l’array Unraid a démarré sans incident — mais un partage a disparu et l’interface Web indique le disque comme Impossible à monter. Il s’agit d’un événement de corruption du système de fichiers, relevant d’une classe de problème distincte d’une défaillance matérielle.

La parité ne peut rien y faire. Le disque de parité conserve un miroir bit à bit des secteurs de données, pas un enregistrement de l’intégrité des métadonnées du système de fichiers. Si le journal ou le superbloc d’un disque de données est corrompu, la parité reproduit fidèlement cette corruption. La récupération dans ce cas nécessite d’intervenir directement avec les outils de réparation du système de fichiers — xfs_repair pour les volumes XFS et btrfs check pour BTRFS — depuis le terminal Unraid.

Comment Unraid utilise des systèmes de fichiers indépendants par disque

Dans un scénario de panne logique, l’architecture d’Unraid devient le facteur central pour déterminer ce qui est endommagé et ce qui ne l’est pas.

Contrairement aux configurations RAID 5 ou RAID 6, où une organisation en bandes s’étend sur plusieurs disques physiques, Unraid écrit les fichiers en intégralité sur des disques individuels. Chaque disque de données constitue un volume autonome — formaté en XFS ou Btrfs — monté indépendamment par le système d’exploitation. La couche d’agrégation d’Unraid, située au‑dessus, gère l’agrégation des partages et la mise à jour de la parité, tandis que la couche de système de fichiers sous‑jacente repose sur un Linux standard.

Conséquence pratique de cette architecture : une corruption du système de fichiers sur le disque 3 n’affecte pas les systèmes de fichiers du disque 1, du disque 2 ni d’un autre disque. Les données de chaque disque sont isolées. Vous réparez un volume, pas l’ensemble du système de stockage. L’exception est le disque de parité — il n’a pas de système de fichiers et ne doit jamais être soumis aux outils de réparation de systèmes de fichiers.

Causes de la corruption du système de fichiers dans Unraid

La corruption du système de fichiers dans Unraid est presque toujours attribuable à l’une des trois causes principales. Identifier celle qui s’applique détermine la procédure de réparation.

Le bouton Format : ce qu’il fait réellement et pourquoi il ne faut pas cliquer dessus

Lorsqu’un disque passe en statut « Unmountable », l’interface Web d’Unraid (WebGUI) affiche une option Format en plus des boutons de diagnostic. Pour les utilisateurs qui ne connaissent pas le fonctionnement de la parité dans Unraid, cela engendre une hypothèse dangereuse : cliquer sur Format permettrait d’une quelconque façon de remettre le disque en état de fonctionnement, la parité reconstruisant ensuite les fichiers perdus.

La séquence correcte lorsqu’un disque est non montable : diagnostiquer d’abord, réparer ensuite, formater uniquement en dernier recours — et seulement après que toutes les données ont été récupérées vers un autre emplacement.

Réparer un disque XFS non démontable sous Unraid : xfs_repair étape par étape

xfs_repair exige que le système de fichiers XFS ciblé soit complètement démonté avant son exécution. Dans une configuration Unraid en fonctionnement, tous les disques de données sont montés. Pour démonter un disque précis afin de le réparer sans arrêter l’ensemble des partages, il faut démarrer Unraid en Mode maintenance — un mode de démarrage qui remet l’array en ligne sans monter les partages et sans que les disques soient activement utilisés.

Étape 1 : Démarrer l’array en Mode Maintenance

Depuis l’interface Web d’Unraid (WebGUI), allez dans Main. Avant de cliquer sur Start, cochez la case Maintenance Mode qui apparaît sous les contrôles de démarrage de l’array. Cliquez sur Start. L’array démarre, mais aucun disque n’est monté sur les partages. Cet état est nécessaire pour exécuter xfs_repair.

Étape 2 : identifier le bon chemin du périphérique

Cette étape évite une erreur fréquente et potentiellement grave lors d’une opération de réparation du système de fichiers (par exemple avec xfs_repair). Dans Unraid, chaque disque de données dispose de deux chemins de périphérique :

• /dev/mdXp1 — le périphérique MD (array), géré par la couche d’array d’Unraid. N’utilisez pas ce chemin pour xfs_repair.
• /dev/sdXp1 — la partition brute du disque, accès direct au matériel. Utilisez ce chemin.

Pour identifier quel /dev/sdX correspond au disque que vous souhaitez réparer, ouvrez un terminal (depuis l’interface Web (WebGUI) : Tools → Terminal, ou via SSH) et exécutez :

	# List disks with their Unraid slot assignments
	ls -la /dev/disk/by-id/

Faites correspondre le numéro de série affiché dans le rapport SMART de l’interface Web (WebGUI) avec le lien symbolique dans /dev/disk/by-id/ afin de confirmer le chemin du périphérique avant de poursuivre.

Étape 3 : exécuter xfs_repair — passe standard

	# Replace sdX with your actual device identifier (e.g. sdb, sdc)
	xfs_repair
	/dev/sdXp1

xfs_repair s’exécute en plusieurs phases : il vérifie les inodes, les répertoires et la carte de l’espace libre du système de fichiers XFS. Sur un journal sain, il rejoue les transactions non validées et se termine en affichant un résumé. Si l’outil s’achève sans erreur fatale, essayez de monter le disque en redémarrant hors du mode de maintenance.

Étape 4 : si xfs_repair échoue en raison d’un journal incohérent — option -L

Si la réparation s’arrête avec un message tel que « ERREUR : le système de fichiers contient des modifications de métadonnées importantes dans un journal qui doivent être rejouées » et refuse de poursuivre, le journal XFS est illisible. La seule option à ce stade consiste à remettre le journal à zéro en utilisant l’option -L.

	# Force repair by zeroing the dirty log
	# Use only after standard xfs_repair has failed
	xfs_repair
	-L
	/dev/sdXp1

Étape 5 : Vérifier la réparation

Après une réparation réussie, relancez xfs_repair une fois de plus en mode vérification uniquement (option -n, exécution sans modification) pour confirmer qu’aucune incohérence supplémentaire n’est présente :

	# Dry-run check — makes no changes, reports remaining issues
	xfs_repair
	-n
	/dev/sdXp1

Si le dry-run indique que le système est propre, redémarrez normalement (sans mode de maintenance). Le disque devrait se monter et son partage devrait réapparaître. Exécutez ensuite un contrôle de parité non correctif afin de confirmer l’intégrité de la parité.

Réparation d’un volume BTRFS corrompu dans Unraid

La corruption d’un volume BTRFS sous Unraid est moins fréquente que celle de XFS, notamment parce que le système de fichiers BTRFS repose sur la copie sur écriture (copy-on-write, COW) — il n’écrase jamais les données existantes, écrivant d’abord de nouvelles versions des blocs dans l’espace libre. Cette caractéristique renforce la résistance aux écritures incomplètes. Néanmoins, la corruption des métadonnées peut se produire, et la procédure de réparation d’un volume BTRFS sur Unraid diffère de celle applicable à XFS à plusieurs égards importants.

Étape 1 : Commencer par btrfs scrub — pas btrfs check

Avant toute opération de réparation, lancez un scrub sur le volume monté. Contrairement à xfs_repair, le scrub BTRFS peut s’exécuter alors que le système de fichiers est monté. Il vérifie les sommes de contrôle de tous les blocs de données et de métadonnées et signale les éventuelles incohérences. Sur un volume Unraid mono-disque sans RAID Btrfs, le scrub ne peut pas corriger automatiquement les erreurs — il n’existe pas de copies redondantes — mais il identifie précisément les blocs endommagés, information utile pour décider d’une stratégie de réparation. Démarrez l’array normalement (pas en mode Maintenance) et ouvrez un terminal :

	# Replace /mnt/diskX with the actual Unraid disk mount path
	btrfs scrub start
	/mnt/diskX
	# Monitor progress
	btrfs scrub status
	/mnt/diskX

Si le scrub se termine sans erreurs, le disque est sain et le statut « non montable » a probablement été un incident transitoire. Redémarrez le système et vérifiez si le disque se monte normalement.

Étape 2 : exécuter btrfs check en mode lecture seule

Si l’opération de scrub (vérification d’intégrité) signale des erreurs ou si le disque reste non démontable après un scrub, passez à btrfs check. Arrêter d’abord l’ensemble RAID pour pouvoir démonter le disque, puis lancer la vérification en mode lecture seule afin d’évaluer l’étendue des dégâts avant toute tentative de réparation :

	# Arrêter l'ensemble RAID puis vérifier sans modifier le système de fichiers
	btrfs check
	/dev/sdXp1

Examiner attentivement la sortie. btrfs check listera les erreurs d’arbres spécifiques et les objets orphelins. Les incohérences mineures — inodes orphelins, références de retour vers la racine incorrectes — peuvent être réparées en toute sécurité. Des erreurs dans l’arbre d’extents ou dans l’arbre des chunks indiquent des dommages structurels plus profonds ; la récupération via le mode de réparation peut alors être incomplète.

Étape 3 : Mode de réparation — à utiliser avec précaution

Pour des corruptions mineures et bien identifiées — erreurs du cache d’espace libre, inodes orphelins, rétro-références de la racine incorrectes — le mode --repair est généralement sans risque :

	# Only for minor, well-scoped corruption
	# Image the disk first if data is critical
	btrfs check
	--repair
	/dev/sdXp1

Étape 4 : récupération des sous‑volumes individuels

Si l’arbre Btrfs de niveau supérieur est endommagé mais que les sous‑volumes de données sont intacts, il est parfois possible de monter directement un sous‑volume spécifique et d’en extraire les données sans réparer l’arbre global :

	# List subvolumes on a partially readable volume
	btrfs subvolume list
	/mnt/diskX
	# Mount a specific subvolume by ID if the default mount fails
	mount
	-o subvolid=256
	/dev/sdXp1 /mnt/recovery_point

Si un sous‑volume se monte avec succès, copiez immédiatement les données vers un disque sain avant d’entreprendre toute réparation supplémentaire du volume endommagé. Cette opération permet de prioriser la récupération de données (récupération de sous‑volumes, sauvegarde) avant les réparations risquées sur le système de fichiers.

Quand les outils en ligne de commande échouent : récupération de fichiers depuis un disque Unraid corrompu avec RS RAID Retrieve

Les commandes xfs_repair et btrfs check agissent au niveau de la structure du système de fichiers — elles tentent de rendre à nouveau le volume montable. Lorsque cela s’avère impossible en raison d’une corruption sévère des métadonnées, ou lorsqu’une réparation s’achève mais que des fichiers restent manquants ou vides, l’étape suivante consiste en une récupération de fichiers (récupération de données au niveau fichier) à partir des données brutes du disque.

C’est ici qu’intervient RS RAID Retrieve. Le programme lit directement les secteurs, contourne les structures de système de fichiers endommagées et reconstitue les arborescences et le contenu des fichiers à partir des tables d’allocation sous-jacentes. Il prend en charge les systèmes XFS et BTRFS, que Windows ne peut pas monter nativement — travailler depuis un PC sous Windows avec le disque connecté en externe constitue donc le flux de travail standard.

RS Raid Retrieve

Récupération de données à partir de baies RAID endommagées

Télécharger

Disponible pour: Windows, macOS, Linux

Résultats de récupération de données par type de corruption

La corruption du système de fichiers sous Unraid est récupérable dans la majorité des cas — à condition de suivre la procédure appropriée et de ne jamais cliquer sur le bouton Formater tant que les données ne sont pas sécurisées. La logique décisionnelle est simple :