Linux sans magie #50 — Diagnostiquer un RAID dégradé

Dans le #49, nous avons étudié les niveaux RAID 0, 1, 5 et 10 et créé le modèle d'un RAID logiciel Linux avec mdadm. Le véritable test arrive lorsqu'un membre disparaît ou signale des erreurs. Le système peut encore répondre, les fichiers rester accessibles, et pourtant la tolérance à une nouvelle panne être déjà épuisée.

Comment distinguer un membre réellement défaillant d'un problème de câble, de contrôleur, de chemin virtuel ou d'assemblage ? Comment préparer la réparation sans aggraver la situation ? Cet article présente une méthode de diagnostic d'abord en lecture seule, puis les conditions pour décider d'une intervention encadrée.

Reconnaître une situation dégradée

Le noyau Linux regroupe plusieurs périphériques bloc dans un ensemble MD. Un RAID redondant peut poursuivre ses opérations même si un membre n'est plus opérationnel, mais la capacité restante dépend du niveau et de la disposition.

État sain : RAID 1 à deux membres
   disque A [U] ─┐
                 ├─ /dev/md0 → filesystem → application
   disque B [U] ─┘

État dégradé :
   disque A [U] ─┐
                 ├─ /dev/md0 → application encore accessible
   disque B [_] ─┘    mais plus de seconde copie disponible

Sur un RAID 1 à deux membres, un seul membre sain peut encore fournir les données. Sur un RAID 5, une panne de disque est tolérable, mais une nouvelle panne peut rendre l'ensemble inutilisable. Avec RAID 10, les conséquences dépendent des copies touchées. RAID 0 ne tolère pas de panne de membre.

Un état dégradé est donc un incident de disponibilité en cours, même si aucune application ne s'est encore arrêtée. Il ne prouve pas à lui seul que toutes les données sont saines ni que le bon disque a été identifié.

Première règle : préserver l'état

Avant d'agir, ouvrez un ticket ou une main courante et notez l'heure, l'hôte, le périphérique MD, les applications dépendantes et les alertes observées. Confirmez si une sauvegarde récente et restaurable existe, ainsi que la criticité du service et la capacité de fonctionner temporairement en mode dégradé.

N'exécutez pas immédiatement mdadm --create, --zero-superblock, --assemble --force, --fail, --remove, --add ou une commande de formatage. Ces opérations peuvent changer l'état ou les métadonnées avant que le diagnostic soit établi. En particulier, ne recréez jamais un ensemble pour tenter de le « retrouver ».

Ne retirez pas non plus un disque physiquement sur la seule base de son nom /dev/sdX : cette dénomination peut changer après redémarrage. L'identification physique doit être corroborée par l'inventaire matériel et les identifiants persistants.

Étape 1 — Lire l'état MD sans écriture

Ces commandes visent l'observation :

cat /proc/mdstat
sudo mdadm --detail --scan
sudo mdadm --detail /dev/md0
lsblk -o NAME,PATH,SIZE,TYPE,FSTYPE,MOUNTPOINTS,SERIAL

/dev/md0 est un exemple. Remplacez-le uniquement après avoir établi le véritable périphérique de l'incident. Si aucun ensemble n'est actif, mdadm --detail sur une cible inexistante ne peut pas diagnostiquer les disques ; passez d'abord par l'inventaire des périphériques et des superblocks.

Dans /proc/mdstat, un RAID 1 à deux membres sain peut afficher [UU], et un ensemble dégradé [U_] ou [_U]. Cette notation indique des positions de membres, pas directement des noms de disques ni leur localisation physique.

Exemple illustratif, non issu d'une machine réelle :

md0 : active raid1 sdb1[0]
      1047552 blocks super 1.2 [2/1] [U_]

La séquence [2/1] décrit ici deux membres RAID attendus pour un seul membre actuellement actif. Ne concluez pas que sdb1 est le disque en panne : dans cet exemple, il est justement présent. L'emplacement absent doit être rapproché de la configuration et des événements.

Étape 2 — Distinguer le rôle des membres

mdadm --detail fournit notamment le RAID Level, l'Array Size, le UUID, l'état général, le nombre de périphériques actifs, en fonctionnement ou défaillants, et la table des membres.

Indicateur	Interprétation utile
`State : clean, degraded`	Ensemble cohérent selon MD, mais redondance incomplète
`Active Devices` inférieur à `Raid Devices`	Des positions attendues ne sont pas actives
`faulty`	Membre considéré défaillant par MD
`removed`	Position sans membre actif
`spare rebuilding`	Reconstruction vers un membre de remplacement en cours
`active sync`	Membre actif et synchronisé selon MD

Les libellés exacts dépendent de la version, du niveau RAID et de l'opération en cours. Recoupez-les avec /proc/mdstat, l'inventaire des disques et les messages du noyau, plutôt que d'agir sur un unique champ.

Le fait qu'un membre soit faulty ne démontre pas forcément une panne mécanique : des erreurs de liaison, une coupure d'alimentation, un problème de contrôleur ou un périphérique virtuel détaché peuvent provoquer une exclusion.

Étape 3 — Retrouver la cause dans les journaux

L'historique du noyau aide à différencier les symptômes :

journalctl -k --no-pager -n 200
journalctl -k --since "2 hours ago" --no-pager
dmesg --color=never | tail -n 100

Les messages peuvent mentionner des erreurs d'I/O, des timeouts, un périphérique qui disparaît, une réinitialisation de lien ou une défaillance RAID. Cherchez les horodatages et l'ordre des événements : une erreur de chemin ayant précédé la dégradation ne se traite pas forcément comme un support définitivement hors service.

Sur une machine virtuelle ou dans le cloud, rapprochez les messages Linux des événements de l'hyperviseur ou du fournisseur : un volume détaché côté plateforme ne doit pas être remplacé comme s'il s'agissait d'un disque physique local.

Si les journaux ont été purgés ou si le système vient de redémarrer, consignez cette limite. L'absence de message n'est pas une preuve d'absence d'erreur.

Étape 4 — Identifier chaque disque sans ambiguïté

Utilisez les informations de bloc, les chemins persistants et les superblocks MD :

lsblk -o NAME,PATH,MODEL,SERIAL,WWN,SIZE,TYPE,FSTYPE
ls -l /dev/disk/by-id/
sudo mdadm --examine /dev/disk/by-id/<membre-identifie>

Le dernier chemin est un placeholder : ne l'exécutez pas tel quel. mdadm --examine lit les métadonnées d'un membre, alors que mdadm --detail interroge l'ensemble MD actif. Les champs Array UUID, Events, Device Role et Array State peuvent éclairer un assemblage incomplet ou une divergence de générations.

Les compteurs Events doivent être interprétés avec prudence : ne forcez pas l'assemblage de membres présentant des métadonnées divergentes sur la seule base d'un nombre plus élevé.

Lorsque le matériel le permet, confrontez série ou WWN au logement physique, au contrôleur et aux informations de supervision. L'objectif est d'identifier le bon disque avant toute manipulation.

Étape 5 — Vérifier ce qui dépend de l'ensemble

Un RAID MD peut soutenir directement un filesystem, ou constituer une couche sous LVM, chiffrement ou stockage applicatif. Cartographiez les dépendances :

lsblk -f
findmnt -o SOURCE,TARGET,FSTYPE,OPTIONS
sudo pvs
sudo lvs -o lv_name,lv_path,lv_size,lv_attr

Les commandes LVM servent ici uniquement si LVM est présent. Repérez notamment les bases de données, volumes système, conteneurs et machines virtuelles qui utilisent le stockage. Cette liste conditionne l'urgence, les fenêtres d'arrêt et les vérifications après réparation.

Un df -h normal ne signifie pas que l'ensemble RAID est sain ; il reflète l'occupation du filesystem, pas sa redondance.

Décider : surveillance, sauvegarde ou arrêt

La décision dépend à la fois de la redondance restante, de la disponibilité des sauvegardes et des erreurs observées.

Service accessible, RAID 1 dégradé : limiter les changements, vérifier la sauvegarde, identifier le membre exclu et préparer un remplacement encadré.
RAID 5 dégradé avec erreurs supplémentaires : risque élevé pour les données ; examiner rapidement la stratégie de préservation et l'opportunité d'arrêter les écritures.
Plusieurs membres douteux, RAID inaccessible : préserver l'état, éviter toute réparation forcée et solliciter une procédure de récupération spécialisée.
Reconstruction déjà en cours : suivre sa progression et les I/O avant d'envisager d'autres opérations.

Ces situations sont des exemples, pas des règles d'intervention universelles. Un arrêt brutal n'est pas toujours préférable à la continuité : le propriétaire du service doit arbitrer en connaissance du risque de données.

Reconstruction : préparer, ne pas improviser

La documentation mdadm et Red Hat décrit, selon les cas, le marquage du disque défaillant, son retrait logique, puis l'ajout d'un membre de remplacement. Cet article n'est pas une procédure de remplacement exécutable en production. Les commandes suivantes montrent seulement la famille d'opérations, avec des placeholders :

# PLAN À VALIDER — ne pas exécuter sans procédure d'incident approuvée
sudo mdadm --manage /dev/md0 --fail /dev/disk/by-id/<ancien-membre>
sudo mdadm --manage /dev/md0 --remove /dev/disk/by-id/<ancien-membre>
sudo mdadm --manage /dev/md0 --add /dev/disk/by-id/<nouveau-membre>

Ces opérations modifient l'ensemble. Un membre en panne peut déjà être absent, un remplaçant peut nécessiter une préparation préalable et certaines architectures imposent un ordre ou des options différents. Ne présumez pas que l'ajout d'un disque « vierge » est immédiatement compatible avec la disposition des partitions ou les métadonnées attendues.

Si la redondance résiduelle est insuffisante, retirer un autre membre peut rendre l'ensemble inaccessible. Ne marquez pas arbitrairement un disque sain comme défaillant pour « tester » la reconstruction sur des données importantes.

La reconstruction copie ou recalcule les informations nécessaires depuis les membres survivants ; elle peut être longue et augmenter fortement la charge d'I/O. Elle ne garantit pas que les fichiers étaient cohérents avant la panne.

Suivre une reconstruction en cours

La lecture périodique des compteurs MD est utile sans déclencher de modification :

cat /proc/mdstat
sudo mdadm --detail /dev/md0
cat /sys/block/md0/md/sync_action

Selon l'opération, sync_action peut afficher recover, resync, check, repair ou idle. La signification est documentée par le noyau Linux ; le chemin /sys/block/md0/... suppose que ce périphérique existe.

Surveillez le pourcentage, le débit, l'évolution des erreurs d'I/O, la température et l'état des services. Une reconstruction qui semble bloquée mérite un diagnostic avant toute tentative de relance.

Ne confondez pas contrôle et réparation : écrire repair dans sync_action est une action qui peut modifier les données ou la redondance. Elle n'a pas sa place dans un premier inventaire.

Vérifier le retour à un état sain

La fin d'un pourcentage de reconstruction n'est pas le seul critère de succès. Vérifiez, après intervention approuvée, la réintégration du nombre attendu de membres et l'absence de nouvelle erreur :

cat /proc/mdstat
sudo mdadm --detail /dev/md0
journalctl -k --since "30 minutes ago" --no-pager
findmnt -o SOURCE,TARGET,FSTYPE

Pour un RAID 1 à deux membres, retrouver [UU] est un indicateur utile ; l'état active sync et le nombre de membres attendus doivent également correspondre. Complétez avec des tests applicatifs, la vérification des sauvegardes et la remise en fonctionnement des alertes de supervision.

Un contrôleur ou disque remplacé doit être clairement associé à son identifiant matériel dans le compte rendu d'incident. Documentez la cause probable, les étapes exactes, les erreurs résiduelles et les mesures de prévention.

Bonnes pratiques, sécurité et limites

La surveillance continue compte autant que la réparation : configurez les alertes MD et hôte, vérifiez leur acheminement et supervisez les disques avec les mécanismes adaptés à l'environnement. Un RAID dégradé silencieux transforme une panne unique tolérable en un risque majeur à la suivante.

Conservez une configuration documentée et une sauvegarde indépendante testée. Évitez les commandes destructrices suggérées sans contexte sur des forums, et n'utilisez jamais --force pour masquer un problème de métadonnées sans expertise de récupération.

Ce guide se limite au diagnostic des ensembles MD Linux. Les contrôleurs RAID matériels, les services de stockage managés, les montages de cluster et les cas de corruption simultanée nécessitent des procédures spécifiques. Aucune simulation de panne n'a été exécutée pour cet article.

Retour arrière et gestion d'incident

Il n'existe pas de « rollback » générique après le retrait du mauvais membre ou l'écrasement d'un superblock. Préparez avant toute écriture les critères d'arrêt, le plan de restauration et le contact d'escalade. Si la situation se dégrade au cours de la reconstruction, ne multipliez pas les essais : préservez les preuves et réévaluez la récupération à partir de sauvegardes fiables.

Références officielles

Conclusion

Diagnostiquer un RAID dégradé exige de suivre un ordre précis : constater l'état MD, lire les journaux, identifier les membres, mesurer le risque pour le service, puis seulement préparer une réparation. Les commandes de gestion des disques ne doivent jamais précéder l'identification de la cible et la stratégie de récupération.

Le RAID protège certains scénarios de panne matérielle, pas les données contre tous les incidents. Dans le #51, nous aborderons le chiffrement de disque avec LUKS et cryptsetup : une autre couche de stockage, avec des objectifs et des précautions différents.