Debian 13 mdadm RAID dégradé : remplacer et reconstruire sans perte de données

octobre 10, 2025 • février 3, 2026 • Lecture : 31 min • Views: 7

Cet article vous a aidé ?

Votre pager sonne. Le graphique de stockage affiche « tout va bien » (comme toujours), mais la latence de votre application augmente et un nœud renvoie des erreurs disque.
Vous vous connectez et vous le voyez : [U_], [UU_U] ou le redoutable ensemble « inactive ».
Vous pouvez reconstruire proprement — ou transformer un seul disque défaillant en incident majeur avec perte de données permanente.

Ceci est un guide de production pour Debian 13 et le RAID logiciel mdadm : diagnostic rapide, remplacement sûr, surveillance de la reconstruction,
et les pièges sur lesquels les gens se blessent. C’est volontairement direct parce que le système de fichiers se moque de vos sentiments.

Règles de base : ce que « dégradé » signifie vraiment

« Dégradé » n’est pas une impression. C’est un état précis : un ensemble (array) manque au moins un membre, a expulsé un membre, ou possède un membre
présent mais pas suffisamment fiable pour la lecture. L’ensemble peut toujours servir des lectures et écritures. C’est la bonne nouvelle.
La mauvaise nouvelle est que votre budget de redondance est déjà consommé.

L’objectif est simple : restaurer la redondance sans introduire d’incertitude supplémentaire. Concrètement, cela signifie :

Ne devinez pas quel disque a échoué. Identifiez par attributs stables (numéro de série, WWN, emplacement baie).
Ne « forcez pas l’assemblage » sauf si vous comprenez les métadonnées et le mode de panne. « Force » est un outil puissant.
Ne reconstruisez pas sur un disque qui est silencieusement malade. SMART dissimule par omission, pas par commission.
Ne changez pas deux choses en même temps. Remplacez un disque ; vérifiez ; puis continuez.

Si vous utilisez RAID5/6 et que vous êtes déjà dégradé, le système vit sur du temps emprunté. Les lectures solliciteront tous les disques restants,
votre taux d’erreurs grimpera, et la fenêtre de reconstruction devient une loterie de fiabilité. Vous pouvez encore gagner. Vous ne pouvez juste pas être désinvolte.

Playbook de diagnostic rapide (premier/deuxième/troisième)

La manière la plus rapide de réparer un RAID dégradé est d’éviter de « faire des choses » tant que vous ne savez pas lequel des cas suivants vous avez :
(1) un disque réellement mort, (2) un problème de connectivité, (3) un changement de nom de périphérique/kernel, (4) des erreurs médias latentes révélées par la charge,
ou (5) un humain qui a déjà tenté une réparation.

Premier : confirmer l’état de l’ensemble et s’il est en resync actif

Vérifiez /proc/mdstat pour degraded, resync, recovery, reshape ou check.
Confirmez quels périphériques md existent et leurs types (raid1/5/6/10).
Décidez : geler les changements jusqu’à la fin du resync, ou intervenir maintenant ?

Deuxième : identifier le membre défaillant par une identité stable, pas par /dev/sdX

Mappez les membres md → partitions → périphériques bloc sous-jacents.
Collectez le numéro de série/WWN et, si applicable, le mapping d’emplacement en baie.
Décidez : le disque « manquant » est-il réellement absent, ou juste non assemblé ?

Troisième : classer le mode de défaillance

Défaillance matérielle: erreurs I/O, périphérique disparu, SMART indique « failing now ». Remplacez le disque.
Problème de chemin/câble/HBA : réinitialisations de lien, erreurs CRC, périphérique instable. Corrigez la connectivité d’abord.
Métadonnées/assemblage : mauvais UUID, superbloc ancien, initramfs non à jour. Corrigez la configuration mdadm et assemblez en sécurité.
Problème de cohérence : nombre discordant, arrêt non propre. Lancez un check après restauration de la redondance.

Blague #1 : RAID signifie « Redundant Array of Inexpensive Disks », mais pendant la reconstruction cela veut souvent dire « Really Anxious IT Department ».

Faits et histoire intéressants (pourquoi mdadm se comporte ainsi)

Linux MD a précédé mdadm. Les premiers RAID logiciels Linux utilisaient raidtools ; mdadm est devenu le standard pratique à mesure que les métadonnées et l’assemblage se sont améliorés.
Les versions de superbloc ont de l’importance. Le metadata 0.90 vit à la fin du périphérique (compatibilité ancienne), tandis que 1.x se trouve près du début ; cela change le comportement au démarrage et la facilité avec laquelle de vieilles métadonnées survivent aux effacements.
Le « write hole » existe vraiment. Le RAID5 classique peut perdre la cohérence lors d’un crash au milieu d’une mise à jour de stripe ; le journaling et les write-intent bitmaps aident, mais ne défient pas la physique.
Les bitmaps n’ont pas toujours été courants. Les write-intent bitmaps réduisent dramatiquement le temps de resync après un arrêt non propre en suivant les régions sales plutôt qu’en scannant tout l’ensemble.
MD peut reshaper en ligne. Changer la disposition, le nombre de disques, ou le niveau RAID est possible mais risqué et lourd en performances — surtout quand c’est dégradé.
Les modes « check » et « repair » de MD sont distincts. Un check peut être non destructif ; repair peut écrire des corrections. Les confondre est la manière dont les gens « réparent » des données pour les rendre incorrectes.
Les noms de périphériques ne sont pas des identités. /dev/sda est une suggestion du noyau basée sur l’ordre de découverte ; le WWN est une identité portée par le matériel.
Debian a historiquement été conservateur. Les valeurs par défaut de Debian (et la culture qui les entoure) favorisent généralement la correction et la stabilité plutôt que l’« automatisation utile » qui masque l’état.

Tâches pratiques (commandes, sorties, décisions)

Ci‑dessous se trouvent des tâches concrètes à exécuter sur Debian 13. Chaque tâche inclut : une commande, ce que signifie une sortie typique, et la décision à prendre.
Si vous traitez ceci comme une liste de contrôle plutôt qu’un buffet, vous dormirez mieux.

Tâche 1 : lire `/proc/mdstat` comme un adulte

cr0x@server:~$ cat /proc/mdstat
Personalities : [raid1] [raid6] [raid5] [raid10]
md0 : active raid1 sda1[0] sdb1[1]
      976630336 blocks super 1.2 [2/1] [U_]
      bitmap: 2/8 pages [8KB], 65536KB chunk

unused devices: <none>

Ce que cela signifie : md0 est un RAID1 avec deux membres attendus. [2/1] veut dire 2 emplacements, 1 périphérique opérationnel. [U_] signifie que le premier disque est en ligne, le second est absent/défectueux.

Décision : L’ensemble fonctionne mais n’a pas de redondance. Priorisez la restauration d’un miroir. Ne lancez pas d’autres maintenances risquées maintenant.

Tâche 2 : obtenir l’état autoritatif depuis mdadm

cr0x@server:~$ sudo mdadm --detail /dev/md0
/dev/md0:
           Version : 1.2
     Creation Time : Mon Sep  2 11:40:18 2024
        Raid Level : raid1
        Array Size : 976630336 (931.51 GiB 1000.20 GB)
     Used Dev Size : 976630336 (931.51 GiB 1000.20 GB)
      Raid Devices : 2
     Total Devices : 1
       Persistence : Superblock is persistent

       Update Time : Mon Dec 29 09:11:22 2025
             State : clean, degraded
    Active Devices : 1
   Working Devices : 1
    Failed Devices : 0
     Spare Devices : 0

              Name : server:0
              UUID : 3b0d0f3b:5f2e6d7a:8c6c9b9b:9dd5a1d2
            Events : 41290

    Number   Major   Minor   RaidDevice State
       0       8        1        0      active sync   /dev/sda1
       1       0        0        1      removed

Ce que cela signifie : mdadm confirme clean, degraded (pas de resync). Le membre manquant est « removed », pas « failed ». Cela arrive souvent après des erreurs I/O répétées ou un retrait manuel.

Décision : Planifiez un remplacement contrôlé. Demandez aussi : pourquoi a‑t‑il été retiré ? Vérifiez les logs avant de vous déclarer victorieux.

Tâche 3 : trouver les périphériques membres et leurs identités stables

cr0x@server:~$ ls -l /dev/disk/by-id/ | grep -E 'sda|sdb'
lrwxrwxrwx 1 root root  9 Dec 29 09:03 ata-SAMSUNG_MZ7L3960HCGR-00005_S4JNNX0T123456 -> ../../sda
lrwxrwxrwx 1 root root  9 Dec 29 09:03 ata-SAMSUNG_MZ7L3960HCGR-00005_S4JNNX0T789012 -> ../../sdb

Ce que cela signifie : Vous avez deux numéros de série distincts. Même si /dev/sdX change après un reboot, ces chemins by-id persistent.

Décision : Dorénavant, dans vos notes ou plan d’action, utilisez le numéro de série/WWN, pas sdb.

Tâche 4 : confirmer quelles partitions appartiennent à MD et si quelque chose manque

cr0x@server:~$ lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS,UUID
NAME        SIZE TYPE FSTYPE            MOUNTPOINTS UUID
sda       931.5G disk
├─sda1    931.5G part linux_raid_member            3b0d0f3b-5f2e-6d7a-8c6c-9b9b9dd5a1d2
└─sda2      512M part vfat              /boot/efi   1A2B-3C4D
sdb       931.5G disk
└─sdb1    931.5G part
md0       931.5G raid1 ext4             /          7b1e4d2d-6ad0-4f1e-bb0d-3b51f7e0f88a

Ce que cela signifie : sda1 est un membre RAID ; sdb1 existe mais n’a pas de signature linux_raid_member. Cela peut signifier qu’il est neuf/non partitionné, ou que c’est l’ancien disque qui a perdu sa table de partitions (moins probable, mais n’assumez pas).

Décision : Si sdb est destiné à être le remplacement, vous le partitionnerez pour correspondre à sda, puis l’ajouterez à l’ensemble. Si sdb est un membre existant qui est « tombé », investiguez pourquoi il a perdu ses métadonnées.

Tâche 5 : lire les logs du noyau pour la vraie cause

cr0x@server:~$ sudo journalctl -k -b | grep -E 'md0|sdb|I/O error|reset|fail' | tail -n 30
Dec 29 08:52:11 server kernel: ata2.00: exception Emask 0x10 SAct 0x0 SErr 0x4050000 action 0x6 frozen
Dec 29 08:52:11 server kernel: ata2.00: irq_stat 0x08000000, interface fatal error
Dec 29 08:52:12 server kernel: ata2: hard resetting link
Dec 29 08:52:17 server kernel: sd 1:0:0:0: [sdb] tag#19 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
Dec 29 08:52:17 server kernel: blk_update_request: I/O error, dev sdb, sector 1953525160 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
Dec 29 08:52:17 server kernel: md/raid1:md0: Disk failure on sdb1, disabling device.
Dec 29 08:52:17 server kernel: md/raid1:md0: Operation continuing on 1 devices.

Ce que cela signifie : Ce n’est pas « mdadm qui fait des siennes ». Ce sont des réinitialisations de lien et des erreurs I/O. C’est souvent le disque, mais ça peut être un câble, un backplane ou un port HBA.

Décision : Avant de reconstruire, décidez si vous faites confiance au chemin. Si c’est une baie hot-swap, reseatez ou déplacez le disque dans une baie connue saine. Si c’est un serveur avec des câbles SATA anciens, remplacez le câble. Les reconstructions excellent à transformer du marginal en mort.

Tâche 6 : lancer SMART sur le périphérique suspect (et l’interpréter comme un pessimiste)

cr0x@server:~$ sudo smartctl -a /dev/sdb | sed -n '1,120p'
smartctl 7.4 2023-08-01 r5530 [x86_64-linux-6.12.0-amd64] (local build)
=== START OF INFORMATION SECTION ===
Model Number:                       SAMSUNG MZ7L3960HCGR-00005
Serial Number:                      S4JNNX0T789012
Firmware Version:                   EDA7902Q
User Capacity:                      960,197,124,096 bytes [960 GB]
SMART overall-health self-assessment test result: PASSED

=== START OF SMART DATA SECTION ===
Critical Warning:                   0x00
Media and Data Integrity Errors:    14
Error Information Log Entries:      27
Warning  Comp. Temperature Time:    0
Unsafe Shutdowns:                   9

Ce que cela signifie : « PASSED » n’est pas un certificat de santé parfait. Les périphériques NVMe/SATA peuvent « passer » tout en enregistrant des erreurs médias. Media and Data Integrity Errors > 0 est un signal d’alerte dans un ensemble dégradé.

Décision : Si le périphérique enregistre des erreurs médias/intégrité, remplacez‑le. Si SMART est propre mais que les logs du noyau montrent des réinitialisations de lien, priorisez les vérifications du chemin/matériel.

Tâche 7 : vérifier que l’ensemble est monté et ne fait rien de dangereux

cr0x@server:~$ findmnt -no SOURCE,TARGET,FSTYPE,OPTIONS /
/dev/md0 / ext4 rw,relatime,errors=remount-ro

Ce que cela signifie : Le root est sur /dev/md0. Cela compte parce que vous ne pouvez pas arrêter l’ensemble à la légère.

Décision : Tout plan de reconstruction doit être en ligne et prudent. Si vous devez arrêter/assembler, vous le ferez depuis un média de secours — ne faites pas d’improvisation sur un ensemble racine actif.

Tâche 8 : confirmer que la config mdadm connaît l’ensemble (vérification du démarrage)

cr0x@server:~$ grep -R "UUID=3b0d0f3b" /etc/mdadm /etc/mdadm/mdadm.conf
/etc/mdadm/mdadm.conf:ARRAY /dev/md0 metadata=1.2 UUID=3b0d0f3b:5f2e6d7a:8c6c9b9b:9dd5a1d2 name=server:0

Ce que cela signifie : Bien : l’ensemble est déclaré. Mal : s’il manque, l’assemblage au démarrage peut devenir « au mieux » aléatoire, ce qui parfois veut dire « mauvais disque, mauvais jour ».

Décision : Si l’entrée manque ou est obsolète, mettez‑la à jour et reconstruisez l’initramfs une fois le système stable.

Tâche 9 : vérifier les « métadonnées fantômes » sur le disque de remplacement avant de l’ajouter

cr0x@server:~$ sudo mdadm --examine /dev/sdb1
mdadm: No md superblock detected on /dev/sdb1.

Ce que cela signifie : Parfait pour une addition propre. Si vous voyez un ancien superbloc avec un UUID différent, il faudra le zéroter ou vous risquez un assemblage erroné ou un refus d’ajout.

Décision : Procédez au partitionnement et à l’ajout. Si de vieilles métadonnées existent, arrêtez et nettoyez délibérément (voir checklist).

Tâche 10 : cloner la table de partitions du disque sain sur le nouveau disque

cr0x@server:~$ sudo sfdisk -d /dev/sda | sudo sfdisk /dev/sdb
Checking that no-one is using this disk right now ... OK

Disk /dev/sdb: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Disk model: SAMSUNG MZ7L3960HCGR-00005
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

sfdisk: Successfully wrote the new partition table.
Syncing disks.

Ce que cela signifie : Le nouveau disque correspond maintenant au layout connu bon. C’est plus sûr que d’éditer manuellement les starts/ends et risquer une désalignement ou une différence de taille.

Décision : Relisez les partitions et vérifiez qu’elles existent avant d’ajouter au md.

Tâche 11 : relire les partitions et confirmer que le noyau voit la nouvelle partition

cr0x@server:~$ sudo partprobe /dev/sdb
cr0x@server:~$ lsblk /dev/sdb
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
sdb      8:16   0 931.5G  0 disk
├─sdb1   8:17   0 931.5G  0 part
└─sdb2   8:18   0   512M  0 part

Ce que cela signifie : Les partitions sont présentes. Si partprobe échoue car le disque est « busy », un reboot peut être nécessaire — mais ne redémarrez pas un système dégradé à la légère sauf si vous avez validé l’assemblage au démarrage.

Décision : Si les partitions existent, continuez. Si elles n’existent pas, arrêtez et corrigez avant de toucher au md.

Tâche 12 : ajouter le nouveau membre à l’ensemble et observer le début de la reconstruction

cr0x@server:~$ sudo mdadm --add /dev/md0 /dev/sdb1
mdadm: added /dev/sdb1
cr0x@server:~$ cat /proc/mdstat
Personalities : [raid1] [raid6] [raid5] [raid10]
md0 : active raid1 sdb1[2] sda1[0]
      976630336 blocks super 1.2 [2/1] [U_]
      [=>...................]  recovery =  7.3% (71680000/976630336) finish=58.4min speed=258432K/sec
      bitmap: 2/8 pages [8KB], 65536KB chunk

unused devices: <none>

Ce que cela signifie : La récupération est en cours. Notez : il affiche toujours [U_] au début ; une fois que suffisamment de régions sont synchronisées, il devrait devenir [UU] à la fin.

Décision : Ne le touchez pas sauf en cas de nécessité. Votre travail est maintenant de surveiller les erreurs et de maintenir le système calme (CPU, I/O, thermiques).

Tâche 13 : surveiller la progression de la reconstruction avec plus de contexte

cr0x@server:~$ watch -n 2 'cat /proc/mdstat; echo; sudo mdadm --detail /dev/md0 | egrep "State|Rebuild|Resync|Raid Devices|Active Devices|Working Devices|Failed Devices"'
Every 2.0s: cat /proc/mdstat; echo; sudo mdadm --detail /dev/md0 | egrep "State|Rebuild|Resync|Raid Devices|Active Devices|Working Devices|Failed Devices"

md0 : active raid1 sdb1[2] sda1[0]
      976630336 blocks super 1.2 [2/2] [UU]
      bitmap: 0/8 pages [0KB], 65536KB chunk

             State : clean
      Raid Devices : 2
    Active Devices : 2
   Working Devices : 2
    Failed Devices : 0

Ce que cela signifie : L’ensemble est revenu à l’état clean, les deux membres sont actifs, aucun périphérique défaillant. C’est l’état souhaité avant de lancer des vérifications de cohérence.

Décision : Une fois la redondance restaurée, planifiez un scrub/check puis corrigez la cause racine (monitoring, câblage, firmware, pièces de rechange).

Tâche 14 : mettre à jour la configuration mdadm et l’initramfs pour que le prochain reboot ne soit pas épicé

cr0x@server:~$ sudo mdadm --detail --scan | sudo tee /etc/mdadm/mdadm.conf
ARRAY /dev/md0 metadata=1.2 UUID=3b0d0f3b:5f2e6d7a:8c6c9b9b:9dd5a1d2 name=server:0
cr0x@server:~$ sudo update-initramfs -u
update-initramfs: Generating /boot/initrd.img-6.12.0-amd64

Ce que cela signifie : initramfs contient maintenant les informations d’assemblage mdadm actuelles. Cela réduit les surprises du type « ne démarre plus après échange de disque ».

Décision : Si c’est un ensemble racine, cette étape n’est pas optionnelle. Les reconstructions rétablissent la redondance ; initramfs évite les surprises demain matin.

Tâche 15 : lancer un contrôle de cohérence non destructif (après la reconstruction)

cr0x@server:~$ echo check | sudo tee /sys/block/md0/md/sync_action
check
cr0x@server:~$ cat /proc/mdstat
Personalities : [raid1] [raid6] [raid5] [raid10]
md0 : active raid1 sdb1[2] sda1[0]
      976630336 blocks super 1.2 [2/2] [UU]
      [==>.................]  check = 11.6% (113246208/976630336) finish=45.2min speed=317120K/sec

unused devices: <none>

Ce que cela signifie : Ceci lit et compare les miroirs. Sur RAID5/6, check lit la parité ; il peut mettre en évidence des erreurs latentes.

Décision : Si le compteur de mismatches augmente (voir tâche suivante), investiguez la cause. Quelques mismatches après un arrêt non propre peuvent se produire ; des mismatches persistants ou croissants signifient problème.

Tâche 16 : lire les compteurs de mismatch (et décider d’un éventuel « repair »)

cr0x@server:~$ cat /sys/block/md0/md/mismatch_cnt
0

Ce que cela signifie : Zéro mismatch est ce que vous voulez. Sur RAID5/6, des mismatches peuvent indiquer write hole, RAM/controller défaillant, ou un disque/contrôleur instable sous charge.

Décision : Ne lancez pas repair par réflexe. Repair écrit des corrections — ne l’utilisez que quand vous savez quel côté est correct (souvent : après validation matérielle et avec des sauvegardes).

Listes de contrôle / plan étape par étape (remplacement sûr de disque)

Voici un plan qui fonctionne sous pression. Il est volontairement ennuyeux. L’ennui, c’est bien ; l’ennui protège vos données.

Checklist A : Avant de toucher à quoi que ce soit

Confirmez que les sauvegardes existent réellement. Pas « on a des snapshots ». Une récupération testée pour les données de cet ensemble.
Capturez l’état courant : /proc/mdstat, mdadm --detail, lsblk, logs récents du noyau.
Identifiez le chemin défaillant par numéro de série/WWN. Écrivez‑le. Prenez une photo de l’étiquette du châssis si c’est physique.
Vérifiez si l’ensemble est déjà en resync. Si oui, votre intervention peut le ralentir ou le déstabiliser.
Fixez les attentes. Sur RAID5/6, le temps de reconstruction en charge n’est pas le chiffre du brochure du vendeur.

Checklist B : Si le disque est encore visible mais « faulty »

Si md a marqué un membre comme faulty mais que le noyau montre encore le périphérique, retirez‑le proprement. Cela empêche md d’essayer de parler à un disque déjà erratique.

cr0x@server:~$ sudo mdadm --detail /dev/md0 | egrep "faulty|removed|active"
      RaidDevice State
      active sync   /dev/sda1
      removed
cr0x@server:~$ sudo mdadm /dev/md0 --fail /dev/sdb1
mdadm: set /dev/sdb1 faulty in /dev/md0
cr0x@server:~$ sudo mdadm /dev/md0 --remove /dev/sdb1
mdadm: hot removed /dev/sdb1 from /dev/md0

Interprétation : Marquer comme faulty puis retirer crée un emplacement propre. Cela empêche aussi des lectures partielles aléatoires depuis un disque mourant.

Décision : Si la suppression échoue parce que le périphérique a disparu, très bien — poursuivez le remplacement. Si elle échoue parce qu’il est « busy », arrêtez et revérifiez que vous avez ciblé le bon membre.

Checklist C : préparer correctement le disque de remplacement

Il y a deux grandes règles : reproduire la table de partitions, et s’assurer qu’aucune ancienne métadonnée RAID ne subsiste.

Partitionnez pour correspondre au membre existant. Utilisez le clonage sfdisk, pas une édition manuelle.
Effacez les anciens superblocs md si présents. Utilisez mdadm --zero-superblock sur les partitions membres, pas sur le disque entier si possible.
Vérifiez les tailles de secteur. Un disque 4Kn mis dans un array 512e peut poser des problèmes de compatibilité selon le contrôleur et le partitionnement.

cr0x@server:~$ sudo mdadm --examine /dev/sdb1
/dev/sdb1:
          Magic : a92b4efc
        Version : 1.2
           UUID : 11111111:22222222:33333333:44444444
     Device Role : Active device 1
   Array State : AA ('A' == active, '.' == missing)
cr0x@server:~$ sudo mdadm --zero-superblock /dev/sdb1
mdadm: Unrecognised md component device - /dev/sdb1
cr0x@server:~$ sudo wipefs -n /dev/sdb1
offset               type
0x00000400           linux_raid_member   [raid]

Interprétation : L’exemple montre les signaux contradictoires que vous verrez en situation réelle : métadonnées obsolètes et outils en désaccord quand les périphériques sont à moitié initialisés.
Si wipefs -n affiche linux_raid_member, vous devez le supprimer avant d’ajouter le disque au nouvel ensemble.

Décision : Utilisez wipefs pour effacer la signature, puis re‑vérifiez avec mdadm --examine pour vous assurer qu’elle a bien disparu.

cr0x@server:~$ sudo wipefs -a /dev/sdb1
/dev/sdb1: 8 bytes were erased at offset 0x00000400 (linux_raid_member): a9 2b 4e fc 00 00 00 00
cr0x@server:~$ sudo mdadm --examine /dev/sdb1
mdadm: No md superblock detected on /dev/sdb1.

Checklist D : ajouter le disque et contrôler l’impact de la reconstruction

Les reconstructions sont intensives en I/O. Vous pouvez échanger vitesse contre sécurité (charge plus faible) ou vitesse contre risque (tout saturer).
En production, je préfère « finir de façon fiable », pas « finir vite et peut‑être mourir en chemin ».

cr0x@server:~$ cat /proc/sys/dev/raid/speed_limit_min
1000
cr0x@server:~$ cat /proc/sys/dev/raid/speed_limit_max
200000
cr0x@server:~$ echo 50000 | sudo tee /proc/sys/dev/raid/speed_limit_max
50000

Interprétation : Il s’agit de limites en KiB/s. Limiter la vitesse max peut préserver une latence acceptable pour les clients et réduire le stress thermique. Cela allongera le temps de reconstruction.

Décision : Si c’est une machine base de données en production, limitez la vitesse et survivez. Si c’est une fenêtre de maintenance, ouvrez le débit.

cr0x@server:~$ sudo mdadm --add /dev/md0 /dev/sdb1
mdadm: added /dev/sdb1

Checklist E : après la reconstruction, durcir pour ne pas recommencer la semaine suivante

Mettre à jour mdadm.conf et régénérer l’initramfs.
Lancer un check et passer en revue les compteurs de mismatch.
Corriger la cause racine : remplacer câble/backplane, mettre à jour le firmware, ajuster le monitoring.
Configurer la surveillance des événements md et des avertissements SMART.

cr0x@server:~$ sudo systemctl enable --now mdadm --quiet || true
cr0x@server:~$ sudo systemctl status mdadm --no-pager
● mdadm.service - MD array assembly and monitoring
     Loaded: loaded (/lib/systemd/system/mdadm.service; enabled; preset: enabled)
     Active: active (exited) since Mon 2025-12-29 09:30:14 UTC; 2min ago

Interprétation : Sur Debian, le comportement du service peut être « active (exited) » et rester correct ; il assemble et délègue la surveillance à d’autres unités/config.

Décision : Confirmez que vous avez un véritable système d’alerte (email, exporteur Prometheus, ou votre pile). « Enabled » sans destinataire, c’est de la mise en scène.

Cas particuliers : RAID1 vs RAID5/6 vs RAID10, bitmaps et reshape

RAID1 : la reconstruction la plus simple, et donc celle où on devient négligent

Les reconstructions RAID1 sont simples : md copie des blocs du disque sain vers le nouveau disque. Votre plus grand risque est humain :
remplacer le mauvais disque ou reconstruire depuis le mauvais côté en cas de split‑brain (rare sur un hôte unique, mais cela arrive après
des réinitialisations de contrôleur étranges et des reboots paniqués).

Un ensemble RAID1 peut être clean, degraded et rester cohérent. Ne confondez pas « dégradé » avec « sale ».
La reconstruction doit être sûre tant que le disque restant est sain.

RAID5/6 : dégradé signifie que chaque lecture devient un travail d’équipe

Avec un RAID parité, un disque manquant signifie reconstruction à la volée sur les lectures (ou lectures sur les disques restants) et I/O lourde.
Pendant la reconstruction, vous sollicitez tous les disques survivants — le moment précis où vous découvrez lesquels étaient marginaux.

Implications pratiques :

La cadence des scrubs compte. Si vous ne faites jamais de scrub, vous trouverez des erreurs latentes pendant la reconstruction. C’est le pire moment.
Les performances fluctueront. Attendez‑vous à des pics de latence. Planifiez la limitation de la reconstruction.
Ayez une condition d’arrêt. Si un deuxième disque commence à signaler des erreurs pendant une reconstruction RAID5, arrêtez et réévaluez. Continuer peut détruire ce qui reste.

RAID10 : les reconstructions sont localisées, mais ne vous laissez pas rassurer

RAID10 reconstruit par paires miroir. C’est généralement plus rapide et moins stressant que RAID5/6, mais ce n’est pas magique.
Si vous perdez un disque dans une paire et que le partenaire survivant est ancien, la reconstruction lit tout le partenaire — encore une fois, stress.

Bitmaps : votre allié après un arrêt non propre

Les bitmaps internes enregistrent quelles régions peuvent être désynchronisées, permettant un resync plus rapide. Si vos ensembles sont grands et vos arrêts
pas parfaitement propres (les coupures de courant arrivent, les humains aussi), les bitmaps peuvent vous faire gagner des heures.

Mais les bitmaps ne sont pas gratuits : ils ajoutent une surcharge d’écriture et de la complexité. En pratique, pour la plupart des ensembles de production où la haute disponibilité compte,
je préfère les avoir.

Reshape : ne le faites pas quand c’est déjà dégradé à moins d’aimer le suspense

mdadm peut reshaper des ensembles : changer le niveau RAID, ajouter des disques, modifier la taille de chunk, etc. C’est puissant.
C’est aussi le type d’opération où « presque correct » n’est pas une note acceptable.

Règle : Restaurez d’abord la redondance, puis reshapez. Si vous êtes déjà dégradé, reshaper augmente les pièces mobiles et la surface de défaillance.

Trois mini-récits d’entreprise depuis les tranchées

Mini-récit 1 : L’incident causé par une mauvaise hypothèse

Une entreprise SaaS de taille moyenne faisait tourner des serveurs Debian avec mdadm RAID1 pour le boot et RAID10 pour les données. Un nœud a signalé un RAID1 dégradé sur md0.
L’ingénieur d’astreinte a vu /dev/sdb manquant et a supposé « disque 2 mort », parce que c’est l’histoire qu’on se raconte :
Linux nomme les disques dans un ordre raisonnable et l’univers est gentil.

Ils ont remplacé le disque en baie 2, ont redémarré et l’ensemble était toujours incorrect. Par frustration, ils l’ont « réparé » en ajoutant le « nouveau disque »
à l’ensemble et en le laissant reconstruire. La machine est revenue propre. Tout le monde a soufflé.

Deux jours plus tard, un reboot planifié a eu lieu. Le système est tombé dans l’initramfs en se plaignant de ne pas pouvoir assembler le root.
Qu’est‑ce qui a changé ? L’énumération. Une mise à jour du firmware et un ordre de découverte légèrement différent ont inversé /dev/sda et /dev/sdb.
Le disque qui avait été reconstruit n’était pas celui que tout le monde pensait. L’ensemble n’avait pas été assemblé de façon cohérente parce que mdadm.conf
n’avait pas été mis à jour et l’initramfs contenait des indices obsolètes d’assemblage.

La récupération n’a pas été héroïque ; elle a été prudente. Ils ont démarré depuis un média de secours, assemblé par UUID, confirmé quel membre avait le dernier event count,
et reconstruit le miroir approprié. La vraie leçon n’était pas « Linux est aléatoire ». La leçon était : /dev/sdX n’est pas une identité.

Après cela, ils ont étiqueté les baies avec les numéros de série et mis à jour leur runbook : chaque opération disque commence par /dev/disk/by-id,
et chaque modification mdadm se termine par update-initramfs -u.

Mini-récit 2 : L’optimisation qui s’est retournée contre eux

Une autre organisation avait une charge d’analytique lourde et voulait que les reconstructions se terminent plus vite. Quelqu’un a trouvé les limites de vitesse md et a monté
speed_limit_max à une grosse valeur sur toute la flotte. Lors de la prochaine panne, la reconstruction a foncé.
Le dashboard était beau. Le temps vers la redondance a chuté. Des fist bumps dans un canal de chat.

Mais pendant les heures de production, la latence a aussi explosé. Pas un peu. La reconstruction a concurrencé les lectures de production, saturé la file HBA,
et augmenté la température des périphériques. Un des disques « sains » a commencé à logger des erreurs UDMA CRC — signe classique d’un lien marginal.
Puis il a commencé à timeout sous charge. md l’a expulsé. Sur RAID6 c’est tolérable ; sur RAID5, ce ne l’est pas.

Le pire : ce n’était même pas d’abord un problème de disque. Le câble était légèrement desserré depuis des mois, mais rien ne le stressait assez pour montrer des symptômes.
La reconstruction a transformé un problème latent en panne.

Ils ont annulé « l’optimisation » globale et remplacé les câblages douteux. La vraie meilleure optimisation a été une politique :
les reconstructions tournent plus lentement en heures de pointe, plus vite pendant les fenêtres de maintenance. Les vrais systèmes servent des clients.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la situation

Une équipe de services financiers utilisait mdadm RAID6 sur des disques nearline. Ils avaient deux habitudes que personne ne célébrait :
des vérifications RAID mensuelles et une procédure stricte de remplacement avec vérification du numéro de série.

Un vendredi soir, un disque a lâché. Ils l’ont remplacé et ont commencé la reconstruction. À mi‑parcours, un second disque a retourné une erreur de lecture sur un secteur.
C’est le moment où RAID6 gagne sa place : il peut tolérer deux pannes, mais uniquement si la seconde ne s’aggrave pas.

Parce qu’ils faisaient des contrôles mensuels, l’équipe savait déjà que les compteurs de mismatch étaient stables et qu’aucun autre disque n’avait de secteurs en attente.
Ils avaient aussi des baselines SMART récentes. L’erreur du second disque était nouvelle et isolée ; ils ont réduit la vitesse de reconstruction et laissé finir.
Puis ils ont planifié le remplacement contrôlé du second disque lors de la fenêtre suivante.

Pas de perte de données. Pas de weekend. Pas de drame. La raison pour laquelle ça a marché est douloureusement peu sexy :
ils n’ont pas découvert leurs erreurs médias pour la première fois pendant une reconstruction.

Citation (idée paraphrasée) d’Admiral Grace Hopper : « La phrase la plus dangereuse est ‘on a toujours fait comme ça’ ». Appliqué au stockage : vérifiez, ne vous contentez pas d’hériter.

Erreurs courantes (symptômes → cause racine → correction)

1) Symptom : L’ensemble est dégradé après un reboot ; les disques semblent « normaux »

Cause racine : mdadm.conf/initramfs n’inclut pas les définitions ARRAY correctes ; l’assemblage dépend du scan et du timing.

Correction : Régénérez la configuration et l’initramfs après stabilisation.

cr0x@server:~$ sudo mdadm --detail --scan | sudo tee /etc/mdadm/mdadm.conf
ARRAY /dev/md0 metadata=1.2 UUID=3b0d0f3b:5f2e6d7a:8c6c9b9b:9dd5a1d2 name=server:0
cr0x@server:~$ sudo update-initramfs -u
update-initramfs: Generating /boot/initrd.img-6.12.0-amd64

2) Symptom : Vous ajoutez un disque et mdadm dit « device has wrong UUID » ou refuse

Cause racine : Le disque de remplacement contient encore un ancien superbloc md ou des signatures de système de fichiers (commun avec les spares réutilisés).

Correction : Effacez les signatures sur la partition membre ciblée, puis ajoutez.

cr0x@server:~$ sudo wipefs -n /dev/sdb1
offset               type
0x00000400           linux_raid_member   [raid]
cr0x@server:~$ sudo wipefs -a /dev/sdb1
/dev/sdb1: 8 bytes were erased at offset 0x00000400 (linux_raid_member): a9 2b 4e fc 00 00 00 00
cr0x@server:~$ sudo mdadm --add /dev/md0 /dev/sdb1
mdadm: added /dev/sdb1

3) Symptom : La reconstruction est extrêmement lente et la latence système est horrible

Cause racine : La reconstruction sature l’I/O ; le scheduler/profondeur de file interagit mal avec la charge ; des erreurs de périphérique provoquent des retries.

Correction : Limitez la vitesse de reconstruction ; réduisez la charge ; vérifiez les logs pour retries/timeouts.

cr0x@server:~$ echo 20000 | sudo tee /proc/sys/dev/raid/speed_limit_max
20000
cr0x@server:~$ sudo journalctl -k -b | grep -E 'reset|timeout|I/O error' | tail -n 20
Dec 29 09:12:04 server kernel: blk_update_request: I/O error, dev sdc, sector 1234567 op 0x0:(READ)

4) Symptom : La reconstruction RAID5 échoue avec « read error » sur un autre disque

Cause racine : Secteur défectueux latent rencontré pendant la reconstruction ; RAID5 ne tolère pas une seconde panne ou une lecture irrécupérable.

Correction : Arrêtez et évaluez : tentez un remap de secteur en lisant la région fautive ; envisagez le clonage ; restaurez depuis sauvegarde si nécessaire.

Honnêteté : RAID5 n’est pas une sauvegarde, et pendant la reconstruction ce n’est même pas une histoire de redondance très convaincante. Traitez‑le comme un incident, pas un avertissement.

5) Symptom : L’ensemble indique « clean » mais le compteur de mismatch augmente pendant le check

Cause racine : Arrêt non propre antérieur, write hole (RAID5), RAM/controller instable, ou corruption silencieuse masquée auparavant.

Correction : Investiguer le matériel, lancer des tests mémoire, vérifier le câblage, et seulement ensuite envisager le repair avec des sauvegardes disponibles.

cr0x@server:~$ cat /sys/block/md0/md/mismatch_cnt
12

6) Symptom : Le disque se fait constamment expulser, mais SMART semble propre

Cause racine : Problèmes au niveau du lien (erreurs CRC), réinitialisations de contrôleur, problème de backplane, alimentation.

Correction : Remplacez le câble/la baie ; vérifiez l’alimentation ; passez en revue les logs du noyau pour les réinitialisations. Ne continuez pas à insérer des disques « bons » dans un slot défaillant.

7) Symptom : Vous ne savez pas quel disque physique est /dev/sdb

Cause racine : Pas d’étiquetage, pas de mapping d’enclosure, et dérive des noms de périphériques entre les boots.

Correction : Utilisez les chemins by-id, les propriétés udev, et (si disponible) les outils de gestion d’enclosure ; puis étiquetez le matériel.

Blague #2 : La seule chose plus fragile qu’un RAID5 dégradé, c’est la confiance de quelqu’un qui vient de taper --force.

FAQ

1) Puis‑je garder le serveur en production pendant la reconstruction ?

En général oui. mdadm est conçu pour des reconstructions en ligne. Le compromis est performance et risque : la charge de reconstruction peut révéler des problèmes latents.
Si c’est votre ensemble root, en ligne est souvent la seule option pratique sans downtime.

2) Dois‑je remplacer le disque immédiatement ou essayer de le reseater d’abord ?

Si les logs montrent des réinitialisations de lien/erreurs CRC et que le périphérique disparaît/réapparaît, reseatez et vérifiez câblage/backplane d’abord.
Si SMART montre des erreurs médias/integrity ou des secteurs réalloués/en attente (selon le type de périphérique), remplacez le disque.

3) Comment savoir quel disque retirer dans un châssis hot-swap ?

Utilisez /dev/disk/by-id et associez aux étiquettes des disques. Si vous avez le mapping d’emplacement d’enclosure (SAS expanders),
servez‑vous en. Ne vous fiez pas à /dev/sdX.

4) Quelle est la manière la plus sûre de partitionner le nouveau disque ?

Clonez la table de partitions depuis un membre connu sain avec sfdisk -d pipé dans sfdisk.
Vérifiez ensuite avec lsblk et seulement alors ajoutez au md.

5) mdadm indique « clean, degraded ». Est‑ce inquiétant ?

C’est mieux que « dirty, degraded », mais vous êtes toujours sans redondance. Une seconde défaillance peut entraîner une perte de données selon le niveau RAID.
Traitez‑le comme urgent, pas forcément panique.

6) Dois‑je lancer `sync_action=repair` après une reconstruction ?

Pas par défaut. Repair écrit des corrections. Si vous avez des mismatches, déterminez d’abord s’ils sont attendus (arrêt non propre) ou symptomatiques
(matériel/firmware). Ayez des sauvegardes avant de laisser quoi que ce soit « réparer » au niveau bloc.

7) Pourquoi la reconstruction a‑t‑elle pris si longtemps comparé au débit annoncé du disque ?

La vitesse de reconstruction est contraint par l’I/O aléatoire, l’activité du système de fichiers, les limites du contrôleur, les retries d’erreur, la chauffe, et les limites md.
Les chiffres de débit séquentiel du vendeur sont du marketing, pas votre charge.

8) Dois‑je mettre à jour l’initramfs après avoir remplacé un membre RAID ?

Si l’ensemble participe au démarrage (root, /boot), oui. Mettez à jour /etc/mdadm/mdadm.conf et exécutez update-initramfs -u.
Sinon, vous risquez une panne au démarrage ou un assemblage incohérent de l’ensemble.

9) Et si j’ai remplacé le mauvais disque ?

Stoppez. N’ajoutez rien. Identifiez les disques restants par numéro de série, examinez les superblocs, et déterminez quel membre a le plus récent event count.
Si vous n’êtes pas sûr, démarrez en rescue media et assemblez par UUID. Deviner convertit un « récupérable » en « développement de carrière ».

10) Le RAID mdadm est‑il « sûr » comparé au RAID matériel ?

mdadm est parfaitement viable en production quand il est correctement opéré : monitoring, récupération testée, et procédures disciplinées.
Le RAID matériel peut masquer des problèmes jusqu’à ce qu’il ne puisse plus. Le RAID logiciel est honnête, ce qui est inconfortable mais utile.

Conclusion : que faire ensuite

Un RAID mdadm dégradé sur Debian 13 est réparable sans drame si vous résistez aux boutons panique et suivez une séquence stricte :
identifiez le bon disque par identité stable, validez le mode de panne, remplacez proprement, reconstruisez à charge contrôlée, puis vérifiez la cohérence.

Prochaines étapes que vous devriez vraiment faire (pas seulement hocher la tête) :

Configurez la surveillance d’événements mdadm pour que « dégradé » devienne une alerte, pas une découverte archéologique.
Planifiez des check périodiques et suivez les compteurs de mismatch dans le temps.
Étiquetez les disques par numéro de série et documentez le mapping des baies. Le vous du futur offrira un café au vous du présent.
Après tout travail disque sur des ensembles de boot : mettez à jour mdadm.conf et régénérez l’initramfs.