Linux sans magie #49 — RAID logiciel Linux avec mdadm

Dans le #48, nous avons distingué les snapshots LVM des sauvegardes indépendantes. Un autre mot revient quand on parle de résilience du stockage : RAID. Il permet, selon son niveau, de répartir les blocs sur plusieurs périphériques pour améliorer le débit, tolérer certaines pannes ou combiner ces propriétés.

Sur Linux, le sous-système MD (Multiple Devices) et l'outil mdadm gèrent des ensembles RAID logiciels. La difficulté n'est pas seulement de créer un périphérique /dev/md..., mais de choisir le niveau adapté, d'identifier correctement les membres et de détecter une dégradation avant une panne supplémentaire.

Un RAID n'est pas une sauvegarde. Il ne protège pas d'un effacement accidentel, d'une corruption logique propagée, d'un rançongiciel ou de la disparition de la machine entière.

Comprendre les couches

Imaginons un serveur avec deux disques réservés aux données. L'objectif est de continuer à lire le volume si l'un des deux disques tombe en panne, sous réserve que l'autre soit sain.

disque A ─┐
          ├── RAID 1 géré par mdadm → /dev/md0
disque B ─┘                           ↓
                                filesystem ext4
                                      ↓
                                   /srv/data

Le noyau expose l'ensemble RAID comme un périphérique bloc. On peut ensuite y créer un filesystem, y placer LVM si l'architecture le prévoit, puis le monter. L'ordre n'est pas interchangeable sans migration : mdadm agit sur les périphériques membres, non sur des fichiers ordinaires.

Chaque disque ou partition qui participe à l'ensemble porte généralement des métadonnées RAID (superblock). Elles permettent d'identifier le niveau, l'UUID de l'ensemble, les membres et leur rôle. Écraser ces métadonnées ou réutiliser un membre sans diagnostic peut compliquer ou empêcher la récupération.

Comparer RAID 0, RAID 1, RAID 5 et RAID 10

Niveau	Nombre minimal de membres	Capacité utile théorique avec N disques égaux de taille S	Tolérance aux pannes
RAID 0	2	N × S	Aucune : panne d'un membre = perte de l'ensemble
RAID 1	2	Généralement S	Un disque sur un miroir à deux membres ; davantage selon copies restantes
RAID 5	3	(N − 1) × S	Un membre défaillant
RAID 10	4 (configuration usuelle à deux copies)	Environ N × S / 2	Dépend des copies et des membres réellement en panne

Ces capacités sont approximatives : métadonnées, alignement, tailles réelles et disposition peuvent réduire l'espace disponible. Avec des disques de tailles différentes, un RAID classique se base généralement sur la capacité exploitable du plus petit membre.

RAID 0 répartit les blocs (striping) sans redondance. Il vise principalement les performances, mais une seule panne suffit à perdre l'accès à l'ensemble.

RAID 1 conserve plusieurs copies des blocs (mirroring). Il est simple à comprendre, mais ne remplace pas une copie indépendante des données.

RAID 5 distribue données et parité. Il peut survivre à une panne de membre, mais la reconstruction sollicite les disques restants. Tant que l'ensemble est dégradé, une seconde panne peut entraîner une perte de données.

RAID 10 combine une répartition et plusieurs copies. Sa tolérance réelle dépend de la disposition et des paires/copies affectées : dire « deux disques peuvent toujours tomber en panne » serait trompeur.

Le bon niveau dépend du besoin de disponibilité, des performances en écriture, du coût de capacité, de la durée de reconstruction, des types de disques et des sauvegardes disponibles.

RAID : ce qu'il protège et ce qu'il ne protège pas

Un RAID redondant vise à maintenir l'accès aux données lorsqu'un nombre limité de membres tombe en panne. Il peut toutefois être indisponible si le contrôleur, l'alimentation, l'hôte, le système ou plusieurs membres sont touchés. Même sans perte physique, une suppression de fichier est immédiatement répercutée sur les copies du RAID.

Ne confondez pas non plus RAID logiciel Linux, RAID matériel géré par un contrôleur, RAID fourni par un hyperviseur et redondance d'un service de stockage cloud. Les fonctionnalités et domaines de défaillance diffèrent.

Pour les données importantes, une sauvegarde restaurable, idéalement séparée de l'environnement de production, reste nécessaire. Testez-la avant de vous fier au RAID comme couche de disponibilité.

Avant de créer : inventorier le stockage

La première série de commandes est non destructive. Elle vise à découvrir les volumes RAID existants et à empêcher toute erreur de disque.

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

La dernière commande suppose qu'un /dev/md0 existe déjà : si ce n'est pas le cas, ne le créez pas simplement pour effectuer le contrôle. Sur un système sans RAID MD, /proc/mdstat peut ne contenir aucun ensemble actif.

Vérifiez les noms persistants sous /dev/disk/by-id/, les partitions, signatures de filesystems, montages et dépendances. Des noms tels que /dev/sdb peuvent changer après un redémarrage ou l'ajout d'un disque. Ne les utilisez pas comme identifiants fiables lors d'une intervention destructive.

Pour inspecter les métadonnées d'un périphérique candidat sans construire d'ensemble, mdadm --examine est approprié. Il faut néanmoins choisir une cible déjà identifiée :

sudo mdadm --examine /dev/disk/by-id/<identifiant-membre-lab>

Ici, le chemin entre chevrons est un placeholder, non un chemin exécutable tel quel.

Laboratoire : créer un RAID 1 sur deux disques jetables

Nous prenons l'exemple de deux disques virtuels dédiés, sans données utiles, avec sauvegarde ou possibilité de les recréer. L'exercice montre le modèle RAID 1, puis les contrôles à faire. Il ne décrit pas la migration d'un système existant.

Attention : mdadm --create écrit des métadonnées sur les périphériques membres. Une mauvaise cible peut détruire l'accès à des données existantes. Ne lancez rien sur un disque de production, un disque monté ou un membre déjà utilisé par un autre ensemble.

Étape 1 — valider les deux candidats

Confirmez que les périphériques choisis sont des disques ou partitions de laboratoire inutilisés :

lsblk -f
ls -l /dev/disk/by-id/
cat /proc/mdstat

Inspectez leur inventaire, leurs signatures et tout éventuel rattachement LVM ou RAID. La présence d'un filesystem, d'un superblock ou d'un montage doit bloquer la création jusqu'à clarification. Les permissions root ne remplacent pas cette validation.

Étape 2 — commande de création à valider

Pour un lab jetable, voici une illustration, volontairement non prête à copier avec de vrais chemins :

sudo mdadm --create /dev/md0 --level=1 --raid-devices=2 \
  /dev/disk/by-id/<disque-lab-A> /dev/disk/by-id/<disque-lab-B>

La commande définit deux membres d'un miroir RAID 1. Adaptez précisément les chemins et la désignation de l'ensemble, selon la distribution et le contexte. Ne modifiez pas des périphériques dont le contenu n'est pas parfaitement connu.

La création peut déclencher une synchronisation initiale. Le périphérique MD peut devenir accessible avant qu'elle soit terminée ; accessible ne signifie pas entièrement synchronisé.

Étape 3 — contrôler l'ensemble et la synchronisation

cat /proc/mdstat
sudo mdadm --detail /dev/md0
sudo mdadm --detail --scan
lsblk -f

Sur un RAID 1 à deux membres, un état sain présente généralement deux membres actifs et synchronisés, avec un indicateur tel que [UU] dans /proc/mdstat. Pendant une reconstruction, le détail affiche la progression et le rôle des membres.

Ne jugez pas l'état à partir d'un seul caractère : vérifiez aussi State, Active Devices, Working Devices, Failed Devices, le rôle des disques et l'absence d'alertes système.

Étape 4 — filesystem et montage : une autre opération

Une fois l'ensemble validé, un filesystem pourrait être créé sur /dev/md0, et non séparément sur les membres. Cette étape est destructive si /dev/md0 contient déjà un filesystem ou des données. Elle n'est donc pas automatisée ici.

Après un formatage et un montage réalisés dans un lab validé, ces commandes permettent de confirmer la bonne couche :

lsblk -f
findmnt --target /mnt/raid-lab -o SOURCE,TARGET,FSTYPE,OPTIONS
df -hT /mnt/raid-lab

Le montage doit pointer vers le périphérique MD (ou une couche LVM au-dessus, si elle est explicitement prévue), jamais vers un membre brut du RAID.

Persistance après redémarrage

Un RAID qui fonctionne maintenant doit aussi être retrouvé au redémarrage. La configuration mdadm répertorie les ensembles et leurs UUID ; son emplacement et l'intégration à l'initramfs dépendent de la distribution.

sudo mdadm --detail --scan

Ne redirigez pas aveuglément cette sortie vers /etc/mdadm.conf ou /etc/mdadm/mdadm.conf avec >>. On risquerait de dupliquer des entrées ou de conserver des noms de périphériques non pertinents. Comparez la configuration existante, validez les UUID et suivez la procédure de votre distribution pour reconstruire l'initramfs si nécessaire.

L'assemblage d'un ensemble existant (mdadm --assemble) est différent de la création (--create). Recréer un ensemble avec les mêmes disques n'est pas une façon sûre de réparer une panne d'assemblage.

Surveillance et état dégradé

Un RAID redondant peut continuer à fonctionner avec un membre en panne : cette continuité est utile, mais elle peut aussi masquer un incident tant que personne ne surveille le système.

cat /proc/mdstat
sudo mdadm --detail /dev/md0
journalctl -k --no-pager -n 100

Préparez des alertes adaptées : surveillance via mdadm --monitor, supervision de l'hôte et vérification des journaux. Sur certaines distributions, la notification mail nécessite une configuration MAILADDR et un service mail fonctionnel ; elle n'est pas automatiquement opérationnelle.

Pendant une dégradation, ne procédez pas au retrait ou à l'ajout de disques « au hasard ». Identifiez la panne physique, l'état de chaque membre, la capacité de tolérance restante et l'intégrité de la sauvegarde. Une reconstruction peut exposer des erreurs latentes et augmenter la pression sur les autres disques.

Vérification de cohérence et erreurs

Linux MD peut exécuter des contrôles de cohérence périodiques selon le niveau RAID et la configuration. Le compteur d'incohérences et la réponse à un check doivent être interprétés dans le contexte du niveau RAID ; un décalage n'identifie pas toujours quel bloc contient la bonne donnée.

Les commandes de type repair ou les opérations de réécriture ne sont pas de simples contrôles. Pour un incident réel, capturez d'abord l'état, consultez la documentation de la distribution et privilégiez une procédure de diagnostic réversible.

Les tests de performance ne doivent pas non plus perturber des disques en reconstruction. Définissez la charge admissible, les fenêtres de maintenance et les seuils de supervision.

Bonnes pratiques

Documentez les UUID d'ensembles, le niveau, les membres, le nombre de copies, les tailles, le mapping des emplacements physiques et le chemin du filesystem. La documentation doit permettre de distinguer les membres même si l'ordre /dev/sdX change.

Utilisez des disques adaptés et surveillés (SMART ou mécanismes du fournisseur), des sauvegardes hors du domaine de panne, des alertes testées et des exercices de restauration. Ne considérez pas un RAID 0 comme une protection des données.

Vérifiez la compatibilité de l'architecture au moment du déploiement : RAID matériel, stockage virtuel, thin provisioning, LUKS et LVM peuvent changer les recommandations. Évitez d'empiler des couches de redondance sans comprendre leurs domaines de défaillance.

Sécurité, limites et retour arrière

Ce guide n'effectue aucune création réelle d'ensemble. Les commandes de modification sont limitées à un laboratoire explicitement jetable. Le dimensionnement de RAID 5 et de RAID 10 ne remplace pas des calculs adaptés au profil d'I/O, à la disposition et au risque de reconstruction.

La suppression d'un ensemble, l'effacement de superblocks, le retrait de membres et le basculement en mode dégradé sont des opérations potentiellement destructives. Aucun « rollback » générique n'est fiable après une erreur de mdadm --create sur les mauvais disques. Il faut préserver les métadonnées restantes et engager un plan de récupération fondé sur des sauvegardes.

Un RAID sain garantit seulement certains scénarios de disponibilité, jamais l'absence de corruption ni la restauration d'un état antérieur.

Références officielles

Conclusion

RAID 0, 1, 5 et 10 répondent à des compromis différents entre capacité, débit et tolérance aux pannes. Avec mdadm, une mise en œuvre fiable commence par l'identification des membres, se poursuit par la vérification du niveau et de la synchronisation, et repose durablement sur la supervision.

Un RAID n'est pas une sauvegarde : il faut toujours préparer une restauration indépendante. Dans le #50, nous étudierons le cas qui met cette architecture à l'épreuve : diagnostiquer un RAID dégradé.