Cet article présente la manipulation permettant de remplacer un disque dur dans une grappe RAID1 avec mdadm pour le système de fichiers Linux racine utilisé pour booter. Si vous êtes dans cette configuration avec un serveur Kimsufi ou OVH et que vous ne souhaitez pas faire de fausse manipulation à distance, cet article est pour vous.

Tout d’abord, les disques durs sont généralement remplacés dans une grappe RAID lorsqu’il sont défectueux, ou encore mieux dès lors qu’ils montrent les premiers signes de fatigue selon leurs attributs SMART.

La difficulté de la manipulation qui suit est de conserver le caractère bootable du RAID qui contient la partition Linux racine dont le /boot. Et cela, dans le but de redonder les données de la racine / autant que /boot.

Sommaire

Retrait du disque souhaité

Le disque dur le plus mal en point pourra être marqué « défaillant » puis retiré de la grappe RAID comme ceci. L’option --set-faulty  est équivalente à --fail  ou -f .

Éventuellement vous pouvez éteindre l’ordinateur, remplacer le disque dur et redémarrer. Avec un peu de chance, mdadm détectera le retrait du disque dur.

On peut ainsi voir l’état du RAID comme ceci avec le fameux [_U]  qui signifie qu’un disque est défaillant.

 

Préparation du disque dur de remplacement

Respect de la table des partitions

Selon les distributions Linux et les installations, on peut constituer le RAID à partir de disques durs entiers ou de partitions de disque dur au format fd « Linux raid autodetect ». L’utilisation de partitions confère un avantage : on peut affecter des portions de disques durs au RAID, comme par exemple une partition pour la racine / et une autre pour le SWAP. Si les disques durs sont de  tailles différentes, on pourra utiliser une partition et limiter sa taille au plus petit des deux disques.

Les préconisations standard appellent à utiliser le type de partition fd (Linux raid autodetect) et à utiliser l’indicateur d’amorçage sur la partition (commande a sur fdisk, et astérisque dans la colonne Boot). A ce jour j’ignore si cela est vraiment nécessaire pour booter sur le RAID1 ou pas.

Le bon sens veut également que le disque dur de remplacement ait strictement la même table de partitions que le disque d’origine. A mon avis on pourrait utiliser des partitions  plus grosses, mais c’est un cas que je n’ai pas testé.

Voici une commande permettant de copier la tables des partitions du disque sdb vers sda avec le respect de l’indicateur d’amorçage (adapter en fonction de votre cas de figure).

Ajout de la partition à la grappe

La commande d’ajout de la partition à la grappe RAID1 est simple :

On vérifie ensuite que le processus suit son cours.

Lorsque cela est terminé le fichier mdstat doit se trouver comme ceci (on remarque le [UU]  qui indique que deux disques sont dans le RAID).

Vérification du MBR et de la table des partitions

La commande mdadm --examine --verbose  doit afficher un résultat différent selon si elle est lancée sur un disque ou une partition.

Sur un disque :

Sur une partition :

Si vous ne constatez pas cette différence sur un des disques durs, vous avez probablement oublié de dupliquer la table des partitions avant d’ajouter le disque à l’array RAID. Le redémarrage du serveur échouera probablement sur le disque en question.

Installation du chargeur de démarrage GRUB

Le chargeur de démarrage GRUB doit se trouver sur tous les disques qui constituent le RAID1 logiciel. Le BIOS ne pouvant pas voir d’array RAID /dev/md1 il démarrera sur l’un des disques durs qui constituent le RAID. Pour cette raison, GRUB sait booter sur du RAID1 en n’utilisant qu’un des disques durs, mais il ne sait pas booter sur du RAID0 ou RAID5. Le cas du RAID matériel est différent puisqu’il trombe le BIOS en lui faisant croire que le RAID est un disque physique.

Alternativement on peut peut lancer grub-install /dev/sda  et grub-install /dev/sdb .

Préalablement, il n’est pas idiot de regénérer l’image initrd avec update-initramfs -u  et de recréer la configuration GRUB avec update-grub2 .

Si vous rencontrez un message du type Impossible de trouver le volume physique « (null) » ou Couldn’t find physical volume `(null)’, cela est du au cache sda1 et sdb1 qui n’est pas cohérent. Cela peut se résoudre avec la commande blockdev --flushbufs /dev/sda1  (source).