By using a combination of following commands, I was soon aware of the gravity of the situation:

cat /proc/mdstat
mdadm --examine /dev/sda1

My /dev/sda1 disk was kicked out of the array, so I did the right stuff which consisted of reconstructing the array:

mdadm /dev/md0 -a /dev/sda1

Then, in an unlucky combination of cosmic ray bombardment, spooky action at a distance and astrological misalignment, half-way to the end of the rebuilding process (which can take up to 5 hours), another disk failed ! It was late, I was tired and utterly worried about losing 1.5 To of precious data. In such a bad shape, I was afraid to worsen the situation. So I decided to shutdown the server and sleep on the problem.

The next day I tried to boot my server to find it (surprise !) stuck in the middle of the boot process, with the famous message:

hit control-D to continue or give root password to fix manually

This is “normal” as my server tried to mount the ext3 filesystem from the /dev/md0 partition that was just assembled by mdadm. Of course md0, if assembled and available to the system, was not running because only one disk, out of three, was in a clean state.

I skip here the epic substory in which I wasted days in a search of a working keyboard, but I let you imagine how such adventures makes my week…

Eventually, I was able to analyze the situation in details. My first reflex ? Check that disks are not physically dead:

fdisk -l /dev/sda
fdisk -l /dev/sdb
fdisk -l /dev/sdc

“Linux raid partitions” (type code “fd“) are still there. Good. I assumed here that disks where not physically damaged. Maybe I should have looked at S.M.A.R.T. datas and statistics (via smartmontools). But remember, I’m lazy (and a bit crazy).

The next step was to get informations about the RAID array itself using:

mdadm --detail /dev/md0

which output the status table below (probably inaccurate as I reconstructed it afterwards):

Number   Major   Minor   RaidDevice State
   0       0        0        0      removed
   1       0        0        1      faulty removed
   2       8       33        2      active sync   /dev/sdc1
   3       8       17        3      spare

What this table told us ?

• The array is up, but not running. One of its device (sdc1) was clean and active, but it’s not enough to get a working RAID-5.
• My first attempt to rebuild the array lead to an unexpected result: it added sda1 as a spare device (in slot #3).
• It confirm that sdb1 unexpectedly failed and is now in a bad state (“faulty removed“).

Then I stopped the array and tried to fearlessly (re)assemble it using 3 differents methods:

mdadm -S /dev/md0
mdadm -A /dev/md0
mdadm --assemble /dev/md0 --verbose /dev/sd[abc]1
mdadm --assemble --force --scan /dev/md0 --verbose

It always failed with messages like:

mdadm: failed to RUN_ARRAY /dev/md0: Input/output error
mdadm: /dev/md0 assembled from 1 drives and 1 spare - not enough to start the array.

So I examined each drive from mdadm‘s point of view:

mdadm -E /dev/sda1
mdadm -E /dev/sdb1
mdadm -E /dev/sdc1
mdadm -E /dev/sd[abc]1 | grep Event

The lastest command compare the “Event” attribute of all devices. It output something like:

Events : 0.53120
Events : 0.53108
Events : 0.53120

which indicate that sda1 and sdc1 are somewhat synced (share the same number) and sdb1 “late” (lower number).

Here I’ve got the idea of recreating the raid array without sdb1, relying only on sda1 and sdc1, by using the “magic” (hence dangerous) --assume-clean option. The latter doesn’t build, erase or initialize a new array. It just try to assemble it “as is”. Here is the command:

mdadm --create /dev/md0 --assume-clean --level=5 --verbose --raid-devices=3 /dev/sda1 missing /dev/sdc1

And it worked !

I mounted the md0 partition and cleaned it up:

fsck.ext3 -v /dev/md0
mount /dev/md0

I updated my mdadm configuration before rebooting my server:

mdadm --detail --scan >> /etc/mdadm/mdadm.conf
vi /etc/mdadm/mdadm.conf
reboot

But history repeat itself, and again, the system hang up during boot. Except this time I knew what was happening: the boot process detected the remaining sdb1 device as part of the old array (the one before the regeneration I did above) and tried to run it. Remembering my last year post, I zero-ized the superblock of sdb1:

mdadm -S /dev/md0
mdadm --zero-superblock /dev/sdb1

A server reboot proved I was right and my md0 partition was automagically mounted in altered state:

localhost:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 sdb1[3] sda1[0] sdc1[2]
      1465143808 blocks level 5, 64k chunk, algorithm 2 [3/2] [U_U]

unused devices: <none>

I just had to re-add sdb1 to fill the available slot and update the mdadm configuration to get back my array in its initial state:

mdadm --manage /dev/md0 --add /dev/sdb1
mdadm --detail --scan >> /etc/mdadm/mdadm.conf
vi /etc/mdadm/mdadm.conf

Assuming that this situation was about an inconsistent file index, I decided to reset the superblocks of the remaining physical disks:

mdadm --zero-superblock /dev/hdc1
mdadm --zero-superblock /dev/hdb1

I don’t know why I decided to do so, but it was the stupidest idea of the week. After such a violent treatment, my array refused to start:

[root@localhost ~]$ mdadm --assemble /dev/md0 --auto --scan --update=summaries --verbose
mdadm: looking for devices for /dev/md0
mdadm: no RAID superblock on /dev/hdc1
mdadm: /dev/hdc1 has wrong raid level.
mdadm: no RAID superblock on /dev/hdb1
mdadm: /dev/hdb1 has wrong raid level.
mdadm: no devices found for /dev/md0

At this moment I was sure that all my data assets were lost. I was desperate. My only alternative was to ask Google. So I did.

I spend several minutes browsing the web without hope. I finally found someone in the same situation as mine (sorry, in french) on debian-user-french mailing list.

The solution was to recreate the RAID array. This sound counter-intuitive: if we recreate a raid array over an existing one, it will be erased ! Right ? Wrong ! As it is said on debian-user-french, mdadm is smart enough to “see” that HDD of the new array were elements of a previous one. Knowing that, mdadm will try to do its best (i.e. if parameters match the previous array configuration) and rebuild the new array upon the previous one in a non-destructive way, by keeping HDD content.

So, here is how I finally recovered my RAID array:

[root@localhost ~]$ mdadm --create /dev/md0 --verbose --level=5 --raid-devices=3 /dev/hdc1 missing /dev/hdb1
mdadm: layout defaults to left-symmetric
mdadm: chunk size defaults to 64K
mdadm: size set to 312568576K
mdadm: array /dev/md0 started.

Of course this doesn’t solve my initial problem about the /dev/md0 file system: it is still in an altered state. Maybe it’s too late to recover data. But at least I reverted all my today’s mistakes, and the situation will not deteriorate until I power up my RAID !

Mise à jour: Le but initial était d’utiliser des boîtiers externes USB pour construire une matrice RAID. En réalité je n’ai jamais pu obtenir de résultats convaincants car les disques USB ne sont pas aussi fiables que des disques dur IDE classique. Je m’explique: une partie seulement des instructions IDE trouvent leurs équivalents dans le protocole USB, limitant ainsi l’accès bas niveau aux disques durs externes par le kernel linux. Voila pourquoi cet article reste inachevé et que certaines parties ci-dessous peuvent paraître décousues.

Pour commencer une explication de la technologie RAID et de ses intérêts n’est pas superflu.

Je dispose de 2 disques durs de 120 Go, que je met chacun dans un boîtier externe USB 2. Je les branche ensuite sur mon OpenBrick NG qui possède sur son port IDE0 un disque dur de 160 Go qui héberge l’OS. L’OS en question est une Mandrakelinux 10.0 installée sur les 40 premiers gigas du disque IDE, dans des partitions classiques qui ne seront pas protégées par le RAID. J’ai choisi une Mandrakelinux 10.0 car à l’époque la Mandriva 2005 n’était pas encore disponible et la Mandrake 10.1 à un udev buggé qui ne créée pas les devices RAID (donc impossibilité d’activer automatiquement le RAID au démarrage).

Supposons à partir de maintenant que l’OS est installé, pour nous concentrer uniquement sur la configuration et la mise en route du RAID.

Étape 1: Formater les partitions

J’ai donc les devices suivants:

• /dev/hda -> DD de 160 Go (40 Go pour l’OS et 120 Go de libre)
• /dev/sda -> DD externe de 120 Go n°1
• /dev/sdb -> DD externe de 120 Go n°2

Nous voulons créer une matrice RAID 5 à partir de 3 x 120 Go. Plutôt que de faire une seule grosse partition de 120 Go par disque, nous allons créer dans chacun des disques trois partitions de 40 Go (3 x 3 x 40 Go = 3 x 120 Go). Nous construirons ensuite 3 unités RAID 5 de 3 x 40 Go puis nous les assemblerons via LVM. L’intérêt de diviser nos grosses partitions en plus petites est de réduire considérablement (par un facteur 3 dans notre cas) le temps de régénération de nos unités RAID en cas de corruption d’une partition.

Les partitions à créer sont de type Linux RAID. On pourra éventuellement faire cela avec drakconf.

Étape 2: Configuration de la matrice RAID

Nous utiliserons mdadm pour la gestion de notre RAID.

Note: A partir de la 10.1, la version de webmin fournie avec la Mandrake supporte mdadm. Pour arriver à nos fins par ce moyen, on pourras s’inspirer d’un article sur la mise en place d’un RAID via webmin.

Installation de mdadm:

urpmi mdadm

Création des matrices:

mdadm --create --verbose /dev/md0 --level=5 --raid-devices=3 /dev/hda2 /dev/sda2 /dev/sdb2
mdadm --create --verbose /dev/md1 --level=5 --raid-devices=3 /dev/hda3 /dev/sda1 /dev/sdb1
mdadm --create --verbose /dev/md2 --level=5 --raid-devices=3 /dev/hda4 /dev/sda3 /dev/sdb3

Lors de la création, les paramètres par défaut sont suffisants. Pour information, les paramètres optimaux sont:

• Parity: left symetric
• Persistent super block
• Chunk size: 32kb ou 64kb (pour nos partitions de 40 Go)

Éditons le fichier de configuration /etc/mdadm.conf:

DEVICE          /dev/sda*
DEVICE          /dev/sdb*
DEVICE          /dev/hda2
DEVICE          /dev/hda3
DEVICE          /dev/hda4
ARRAY           /dev/md0 devices=/dev/hda2,/dev/sda2,/dev/sdb2
ARRAY           /dev/md1 devices=/dev/hda3,/dev/sda1,/dev/sdb1
ARRAY           /dev/md2 devices=/dev/hda4,/dev/sda3,/dev/sdb3

Avant d’aller plus loin, il faut attendre que les matrices soient construites:

watch -n1 'cat /proc/mdstat'

Dans mon cas, cela à nécessité entre deux et trois heures pour chaque unité RAID.

Note: avec la Mandrake 10.1, lors de la création des matrices RAID, on aurait eu des problèmes du type raidstart failed : /dev/md1: No such file or directory, qui peuvent être résolus en créant les device manuellement:

mknod /dev/md0 b 9 0
mknod /dev/md1 b 9 1
mknod /dev/md2 b 9 2

Ces commandes créent les unités RAID dont nous avons besoin. Malheureusement elles ne sont pas autodetectées au démarrage donc, dans le cas d’une mdk 10.1, il aurait fallu faire cette manip à chaque démarrage de la machine. Voila une bonne raison pour ne pas utiliser la version 10.1.

Étape 3: Agréger les matrices RAID via LVM

J’ai choisi LVM pour agréger les unités RAID, pour bénéficier d’un redimensionnement flexible de mon espace disque, avant de parer à tous les scénarios possibles auxquels je serais confronté dans le futur. Il est tout à fait possible de faire la même chose avec du RAID linéaire (voir l’étape “3-bis” ci-après), mais dans ce cas on perd la une certaine souplesse au niveau des partitions.

Installation de LVM:

urpmi lvm2

On peut consulter la liste des disques parents sur le système avec lvmdiskscan.

Ensuite il faut créer un volume physique (PV = Physical Volume) pour chaque unité RAID:

pvcreate /dev/md0
pvcreate /dev/md1
pvcreate /dev/md2

Créons maintenant un groupe de volumes contenant nos trois partitions :

vgcreate vg01 /dev/md0 /dev/md1 /dev/md2

(marche pas ???)

Étape 3-bis: Agréger les matrices avec du RAID linéaire au lieu d’utiliser LVM

Si vous voulez utiliser du RAID linéaire plutôt que LVM, il faut créer une nouvelle unité RAID sur la base des trois premières:

mdadm --create --verbose /dev/md3 --level=linear --raid-devices=3 /dev/md0 /dev/md1 /dev/md2

Puis penser à mettre à jour /etc/mdadm.conf:

DEVICE          /dev/sda*
DEVICE          /dev/sdb*
DEVICE          /dev/hda2
DEVICE          /dev/hda3
DEVICE          /dev/hda4
DEVICE          /dev/md0
DEVICE          /dev/md1
DEVICE          /dev/md2
ARRAY           /dev/md0 devices=/dev/hda2,/dev/sda2,/dev/sdb2
ARRAY           /dev/md1 devices=/dev/hda3,/dev/sda1,/dev/sdb1
ARRAY           /dev/md2 devices=/dev/hda4,/dev/sda3,/dev/sdb3
ARRAY           /dev/md3 devices=/dev/md0,/dev/md1,/dev/md2

Étape 4: Créer le système de fichier

Formater en xfs:

mkfs.xfs -f /dev/md3

J’ai choisi xfs comme filesystem car il peut être agrandit à chaud, lorsque la partition est montée.

Pour monter le tout:

mkdir -p /mnt/data
mount /dev/md3 /mnt/data

Et enfin, pour le montage automatique au démarrage de notre serveur, il faut ajouter la ligne suivante à notre fichier /etc/fstab:

/dev/md3 /mnt/data xfs defaults 0 0

Maintenance du système

• Réintégrer une partition dans la matrice.

  Si une partition est éjectée d’une unité raid (par exemple sda1 sur md1), il faut faire:

  cat /proc/mdstat
  mdadm --examine /dev/sda1
  mdadm /dev/md1 -a /dev/sda1
  cat /proc/mdstat
  

  La première commande montre que le RAID est dégradé. La seconde commande examine le status du disque qui à été éjecté de la matrice. La troisième ligne permet de réintégrer à chaud la partition dans la matrice. Et enfin la dernière commande nous montre l’avancement de la reconstruction de la matrice (ce qui peut prendre pas mal de temps).

• Ré-assembler une matrice.

  La commande est du type:

  mdadm --stop /dev/md0
  mdadm --assemble /dev/md0
  

  Attention --assemble se base sur le fichier /etc/mdadm.conf.

• Créer une unité RAID dégradée.

  La commande suivante créée une unité RAID 5 sur 3 disques durs, en indiquant que le premier est absent via le mot clé missing:

  mdadm --create /dev/md0 --level=5 --raid-devices=3 missing /dev/hda1 /dev/sda1
  

De la lecture complémentaire sur RAID 5 et LVM

• Notes on Building a Linux Storage Server, by Martin Smith
• Gentoo Install on Software RAID mirror and LVM2 on top of RAID
• Disks are fun
• Anatomy of a Drive Failure
• Changing RAID Drives Without Losing Data