Ok - quelque chose me turlupinait à propos de votre problème, alors j'ai démarré une VM pour plonger dans le comportement qui devrait être attendu. J'en viens à ce qui me chiffonnait dans une minute, mais laissez-moi d'abord vous dire ceci :

Sauvegardez ces disques avant de tenter quoi que ce soit !

Vous avez peut-être déjà fait des dégâts au-delà de ce que la resynchronisation a fait ; pouvez-vous clarifier ce que vous vouliez dire quand vous avez dit :

Selon les suggestions, j'ai nettoyé les superblocs et recréé le tableau avec l'option --assume-clean mais sans succès.

Si vous avez exécuté un mdadm --misc --zero-superblock alors vous devriez vous en sortir.

Quoi qu'il en soit, récupérez de nouveaux disques et récupérez les images actuelles exactes de ces disques avant de faire quoi que ce soit qui puisse encore écrire sur ces disques.

dd if=/dev/sdd of=/path/to/store/sdd.img

Ceci étant dit il semble que les données stockées sur ces choses soient étonnamment résistantes aux resynchronisations intempestives. Continuez à lire, il y a de l'espoir, et c'est peut-être le jour où je vais atteindre la limite de longueur des réponses.

Le meilleur scénario

J'ai créé une machine virtuelle pour recréer votre scénario. Les disques ne font que 100 Mo, donc je n'attendrais pas une éternité à chaque resynchronisation, mais cela devrait être une représentation assez précise.

Construit le tableau de façon aussi générique et par défaut que possible - 512k chunks, disposition symétrique à gauche, disques dans l'ordre des lettres rien de spécial.

root@test:~# mdadm --create /dev/md0 --chunk=512 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md0 started.
root@test:~# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md0 : active raid5 sdd1[3] sdc1[1] sdb1[0]
      203776 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]

unused devices: <none>

Jusqu'ici, tout va bien ; créons un système de fichiers, et mettons-y des données.

root@test:~# mkfs.ext4 /dev/md0
mke2fs 1.41.14 (22-Dec-2010)
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
Stride=512 blocks, Stripe width=1024 blocks
51000 inodes, 203776 blocks
10188 blocks (5.00%) reserved for the super user
First data block=1
Maximum filesystem blocks=67371008
25 block groups
8192 blocks per group, 8192 fragments per group
2040 inodes per group
Superblock backups stored on blocks:
        8193, 24577, 40961, 57345, 73729

Writing inode tables: done
Creating journal (4096 blocks): done
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 30 mounts or
180 days, whichever comes first.  Use tune2fs -c or -i to override.
root@test:~# mkdir /mnt/raid5
root@test:~# mount /dev/md0 /mnt/raid5
root@test:~# echo "data" > /mnt/raid5/datafile
root@test:~# dd if=/dev/urandom of=/mnt/raid5/randomdata count=10000
10000+0 records in
10000+0 records out
5120000 bytes (5.1 MB) copied, 0.706526 s, 7.2 MB/s
root@test:~# sha1sum /mnt/raid5/randomdata
847685a5d42524e5b1d5484452a649e854b59064  /mnt/raid5/randomdata

Ok. Nous avons un système de fichiers et des données ("data" dans le texte anglais). datafile et 5 Mo de données aléatoires avec ce hachage SHA1 dans le fichier de données. randomdata ) sur elle ; voyons ce qui se passe lorsque nous faisons une re-création.

root@test:~# umount /mnt/raid5
root@test:~# mdadm --stop /dev/md0
mdadm: stopped /dev/md0
root@test:~# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
unused devices: <none>
root@test:~# mdadm --create /dev/md1 --chunk=512 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: /dev/sdb1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 21:07:06 2012
mdadm: /dev/sdc1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 21:07:06 2012
mdadm: /dev/sdd1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 21:07:06 2012
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md1 : active raid5 sdd1[2] sdc1[1] sdb1[0]
      203776 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]

unused devices: <none>

La resynchronisation s'est terminée très rapidement avec ces disques minuscules, mais elle a eu lieu. Donc, voici ce qui m'embêtait tout à l'heure ; ton fdisk -l sortie. N'ayant pas de table de partition sur le md n'est pas du tout un problème, c'est attendu. Votre système de fichiers réside directement sur le faux périphérique de bloc, sans table de partition.

root@test:~# fdisk -l
...
Disk /dev/md1: 208 MB, 208666624 bytes
2 heads, 4 sectors/track, 50944 cylinders, total 407552 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 524288 bytes / 1048576 bytes
Disk identifier: 0x00000000

Disk /dev/md1 doesn't contain a valid partition table

Oui, pas de table de partition. Mais...

root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
/dev/md1: clean, 12/51000 files, 12085/203776 blocks

Système de fichiers parfaitement valide, après une resynchronisation. Donc c'est bon, vérifions nos fichiers de données :

root@test:~# mount /dev/md1 /mnt/raid5/
root@test:~# cat /mnt/raid5/datafile
data
root@test:~# sha1sum /mnt/raid5/randomdata
847685a5d42524e5b1d5484452a649e854b59064  /mnt/raid5/randomdata

Solide - pas de corruption de données du tout ! Mais ceci avec exactement les mêmes paramètres, donc rien n'a été mappé différemment entre les deux groupes RAID. Laissons tomber ce truc avant d'essayer de le casser.

root@test:~# umount /mnt/raid5
root@test:~# mdadm --stop /dev/md1

Prendre un peu de recul

Avant d'essayer d'y mettre fin, expliquons pourquoi il est difficile de le faire. Le RAID 5 fonctionne en utilisant un bloc de parité qui protège une zone de la même taille que le bloc sur chaque autre disque de la matrice. La parité ne se trouve pas uniquement sur un disque spécifique, elle est répartie uniformément sur les disques afin de mieux répartir la charge de lecture sur les disques en fonctionnement normal.

L'opération XOR pour calculer la parité ressemble à ceci :

DISK1  DISK2  DISK3  DISK4  PARITY
1      0      1      1    = 1
0      0      1      1    = 0
1      1      1      1    = 0

Ainsi, la parité est répartie sur les disques.

DISK1  DISK2  DISK3  DISK4  DISK5
DATA   DATA   DATA   DATA   PARITY
PARITY DATA   DATA   DATA   DATA
DATA   PARITY DATA   DATA   DATA

Une resynchronisation est généralement effectuée lors du remplacement d'un disque mort ou manquant ; elle est également effectuée sur mdadm create pour s'assurer que les données sur les disques correspondent à ce que la géométrie du RAID est supposée être. Dans ce cas, le dernier disque dans la spécification de la matrice est celui qui est "synchronisé" - toutes les données existantes sur les autres disques sont utilisées pour la synchronisation.

Ainsi, toutes les données du "nouveau" disque sont effacées et reconstruites, soit en créant de nouveaux blocs de données à partir de blocs de parité pour ce qui aurait dû être là, soit en créant de nouveaux blocs de parité.

Ce qui est cool, c'est que la procédure pour ces deux choses est exactement la même : une opération XOR sur les données du reste des disques. Dans ce cas, le processus de resynchronisation peut avoir dans sa configuration qu'un certain bloc devrait être un bloc de parité, et penser qu'il construit un nouveau bloc de parité, alors qu'en fait il recrée un ancien bloc de données. Ainsi, même s'il pense c'est de construire ça :

DISK1  DISK2  DISK3  DISK4  DISK5
PARITY DATA   DATA   DATA   DATA
DATA   PARITY DATA   DATA   DATA
DATA   DATA   PARITY DATA   DATA

...c'est peut-être juste une reconstruction DISK5 de la mise en page ci-dessus.

Il est donc possible que les données restent cohérentes même si la matrice est mal construite.

Lancer un singe dans les travaux

(pas une clé, le singe entier)

Test 1 :

Faisons le tableau dans le mauvais ordre ! sdc entonces sdd entonces sdb ..

root@test:~# mdadm --create /dev/md1 --chunk=512 --level=5 --raid-devices=3 /dev/sdc1 /dev/sdd1 /dev/sdb1
mdadm: /dev/sdc1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 23:06:34 2012
mdadm: /dev/sdd1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 23:06:34 2012
mdadm: /dev/sdb1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 23:06:34 2012
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md1 : active raid5 sdb1[3] sdd1[1] sdc1[0]
      203776 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]

unused devices: <none>

Ok, c'est très bien comme ça. Avons-nous un système de fichiers ?

root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
fsck.ext4: Superblock invalid, trying backup blocks...
fsck.ext4: Bad magic number in super-block while trying to open /dev/md1

The superblock could not be read or does not describe a correct ext2
filesystem.  If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>

Non ! Pourquoi cela ? Parce que même si toutes les données sont là, elles sont dans le mauvais ordre ; ce qui était auparavant 512KB de A, puis 512KB de B, A, B, et ainsi de suite, a maintenant été mélangé en B, A, B, A. Le disque ressemble maintenant à du charabia pour le vérificateur de système de fichiers, il ne fonctionnera pas. La sortie de mdadm --misc -D /dev/md1 nous donne plus de détails ; cela ressemble à ceci :

Number   Major   Minor   RaidDevice State
   0       8       33        0      active sync   /dev/sdc1
   1       8       49        1      active sync   /dev/sdd1
   3       8       17        2      active sync   /dev/sdb1

Alors que ça devrait ressembler à ça :

Number   Major   Minor   RaidDevice State
   0       8       17        0      active sync   /dev/sdb1
   1       8       33        1      active sync   /dev/sdc1
   3       8       49        2      active sync   /dev/sdd1

Donc, c'est très bien comme ça. On a écrasé tout un tas de blocs de données avec de nouveaux blocs de parité cette fois. Re-créer, avec le bon ordre maintenant :

root@test:~# mdadm --stop /dev/md1
mdadm: stopped /dev/md1
root@test:~# mdadm --create /dev/md1 --chunk=512 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: /dev/sdb1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 23:11:08 2012
mdadm: /dev/sdc1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 23:11:08 2012
mdadm: /dev/sdd1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 23:11:08 2012
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
/dev/md1: clean, 12/51000 files, 12085/203776 blocks

Neat, il y a toujours un système de fichiers là ! Tu as toujours des données ?

root@test:~# mount /dev/md1 /mnt/raid5/
root@test:~# cat /mnt/raid5/datafile
data
root@test:~# sha1sum /mnt/raid5/randomdata
847685a5d42524e5b1d5484452a649e854b59064  /mnt/raid5/randomdata

Succès !

Test 2

Ok, changeons la taille des morceaux et voyons si cela nous permet d'obtenir de la casse.

root@test:~# umount /mnt/raid5
root@test:~# mdadm --stop /dev/md1
mdadm: stopped /dev/md1
root@test:~# mdadm --create /dev/md1 --chunk=64 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: /dev/sdb1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 23:21:19 2012
mdadm: /dev/sdc1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 23:21:19 2012
mdadm: /dev/sdd1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 23:21:19 2012
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
fsck.ext4: Superblock invalid, trying backup blocks...
fsck.ext4: Bad magic number in super-block while trying to open /dev/md1

The superblock could not be read or does not describe a correct ext2
filesystem.  If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>

Ouais, ouais, c'est foutu quand c'est réglé comme ça. Mais, pouvons-nous récupérer ?

root@test:~# mdadm --stop /dev/md1
mdadm: stopped /dev/md1
root@test:~# mdadm --create /dev/md1 --chunk=512 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: /dev/sdb1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 23:21:51 2012
mdadm: /dev/sdc1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 23:21:51 2012
mdadm: /dev/sdd1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 23:21:51 2012
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
/dev/md1: clean, 12/51000 files, 12085/203776 blocks
root@test:~# mount /dev/md1 /mnt/raid5/
root@test:~# cat /mnt/raid5/datafile
data
root@test:~# sha1sum /mnt/raid5/randomdata
847685a5d42524e5b1d5484452a649e854b59064  /mnt/raid5/randomdata

Succès, encore !

Test 3

C'est celui dont je pensais qu'il tuerait les données à coup sûr - faisons un algorithme de mise en page différent !

root@test:~# umount /mnt/raid5
root@test:~# mdadm --stop /dev/md1
mdadm: stopped /dev/md1
root@test:~# mdadm --create /dev/md1 --chunk=512 --level=5 --layout=right-asymmetric --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: /dev/sdb1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 23:32:34 2012
mdadm: /dev/sdc1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 23:32:34 2012
mdadm: /dev/sdd1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 23:32:34 2012
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md1 : active raid5 sdd1[3] sdc1[1] sdb1[0]
      203776 blocks super 1.2 level 5, 512k chunk, algorithm 1 [3/3] [UUU]

unused devices: <none>
root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
fsck.ext4: Superblock invalid, trying backup blocks...
Superblock has an invalid journal (inode 8).

Effrayant et mauvais - il pense avoir trouvé quelque chose et veut le réparer ! Ctrl + C !

Clear<y>? cancelled!

fsck.ext4: Illegal inode number while checking ext3 journal for /dev/md1

Ok, crise évitée. Voyons si les données sont toujours intactes après avoir resynchronisé avec la mauvaise disposition :

root@test:~# mdadm --stop /dev/md1
mdadm: stopped /dev/md1
root@test:~# mdadm --create /dev/md1 --chunk=512 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: /dev/sdb1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 23:33:02 2012
mdadm: /dev/sdc1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 23:33:02 2012
mdadm: /dev/sdd1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 23:33:02 2012
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
/dev/md1: clean, 12/51000 files, 12085/203776 blocks
root@test:~# mount /dev/md1 /mnt/raid5/
root@test:~# cat /mnt/raid5/datafile
data
root@test:~# sha1sum /mnt/raid5/randomdata
847685a5d42524e5b1d5484452a649e854b59064  /mnt/raid5/randomdata

Succès !

Test 4

Prouvons aussi rapidement que la mise à zéro des superblocs n'est pas nuisible :

root@test:~# umount /mnt/raid5
root@test:~# mdadm --stop /dev/md1
mdadm: stopped /dev/md1
root@test:~# mdadm --misc --zero-superblock /dev/sdb1 /dev/sdc1 /dev/sdd1
root@test:~# mdadm --create /dev/md1 --chunk=512 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
/dev/md1: clean, 12/51000 files, 12085/203776 blocks
root@test:~# mount /dev/md1 /mnt/raid5/
root@test:~# cat /mnt/raid5/datafile
data
root@test:~# sha1sum /mnt/raid5/randomdata
847685a5d42524e5b1d5484452a649e854b59064  /mnt/raid5/randomdata

Ouais, pas de problème.

Test 5

Lançons-y tout ce que nous avons. Les 4 tests précédents, combinés.

• Mauvais ordre des dispositifs
• Taille incorrecte des morceaux
• Algorithme de mise en page erroné
• Superblocs mis à zéro (nous le ferons entre les deux créations)

En avant !

root@test:~# umount /mnt/raid5
root@test:~# mdadm --stop /dev/md1
mdadm: stopped /dev/md1
root@test:~# mdadm --misc --zero-superblock /dev/sdb1 /dev/sdc1 /dev/sdd1
root@test:~# mdadm --create /dev/md1 --chunk=64 --level=5 --raid-devices=3 --layout=right-symmetric /dev/sdc1 /dev/sdd1 /dev/sdb1
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md1 : active raid5 sdb1[3] sdd1[1] sdc1[0]
      204672 blocks super 1.2 level 5, 64k chunk, algorithm 3 [3/3] [UUU]

unused devices: <none>
root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
fsck.ext4: Superblock invalid, trying backup blocks...
fsck.ext4: Bad magic number in super-block while trying to open /dev/md1

The superblock could not be read or does not describe a correct ext2
filesystem.  If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>
root@test:~# mdadm --stop /dev/md1
mdadm: stopped /dev/md1

Le verdict ?

root@test:~# mdadm --misc --zero-superblock /dev/sdb1 /dev/sdc1 /dev/sdd1
root@test:~# mdadm --create /dev/md1 --chunk=512 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md1 : active raid5 sdd1[3] sdc1[1] sdb1[0]
      203776 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]

unused devices: <none>

root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
/dev/md1: clean, 13/51000 files, 17085/203776 blocks
root@test:~# mount /dev/md1 /mnt/raid5/
root@test:~# cat /mnt/raid5/datafile
data
root@test:~# sha1sum /mnt/raid5/randomdata
847685a5d42524e5b1d5484452a649e854b59064  /mnt/raid5/randomdata

Wow.

Il semble donc qu'aucune de ces actions n'ait corrompu les données de quelque manière que ce soit. J'ai été assez surpris par ce résultat, franchement ; je m'attendais à des chances modérées de perte de données lors du changement de taille des morceaux, et à une perte certaine lors du changement de disposition. J'ai appris quelque chose aujourd'hui.

Alors Comment puis-je obtenir mes données ?

Toutes les informations dont vous disposez sur l'ancien système vous seraient extrêmement utiles. Si vous connaissez le type de système de fichiers, si vous avez d'anciennes copies de votre /proc/mdstat avec des informations sur l'ordre des lecteurs, l'algorithme, la taille des morceaux et la version des métadonnées. Les alertes e-mail de mdadm sont-elles configurées ? Si c'est le cas, trouvez-en une ancienne ; sinon, vérifiez les points suivants /var/spool/mail/root . Vérifiez votre ~/.bash_history pour voir si votre construction originale est là-dedans.

Donc, la liste des choses que vous devriez faire :

1. Sauvegarder les disques avec dd avant d'entreprendre quoi que ce soit !
2. Essayez de fsck le md actuel, actif - il se peut que vous ayez juste construit dans le même ordre qu'avant. Si vous connaissez le type de système de fichiers, c'est utile ; utilisez ce type de système de fichiers spécifique. fsck Outil. Si l'un de ces outils propose de réparer quelque chose, ne le laissez pas faire à moins d'être sûr qu'il a réellement trouvé le système de fichiers valide ! Si un fsck propose de réparer quelque chose pour vous, n'hésitez pas à laisser un commentaire pour demander s'il vous aide vraiment ou s'il est sur le point de détruire vos données.
3. Essayez de construire le tableau avec des paramètres différents. Si vous avez un ancien /proc/mdstat Dans le cas contraire, vous êtes dans le noir - essayer tous les différents ordres de disques est raisonnable, mais vérifier toutes les tailles de morceaux possibles avec tous les ordres possibles est futile. Pour chacun, fsck pour voir si vous obtenez quelque chose de prometteur.

Donc, c'est ça. Désolé pour le roman, n'hésitez pas à laisser un commentaire si vous avez des questions, et bonne chance !

note de bas de page : moins de 22 000 caractères, soit 8 000+ de moins que la limite de longueur.

J'ai eu un problème similaire :
après une défaillance d'un réseau RAID5 logiciel, j'ai tiré mdadm --create sans lui donner --assume-clean et ne pouvait plus monter la matrice. Après deux semaines de recherches, j'ai finalement restauré toutes les données. J'espère que la procédure ci-dessous permettra à quelqu'un de gagner du temps.

Long Story Short

Le problème a été causé par le fait que mdadm --create a créé un nouveau tableau qui était différent de l'original sur deux points :

• ordre différent des partitions
• décalage différent des données RAID

Comme cela a été montré dans le brillant réponse de Shane Madden , mdadm --create ne détruit pas les données dans la plupart des cas ! Après avoir trouvé l'ordre des partitions et le décalage des données, j'ai pu restaurer le tableau et en extraire toutes les données.

Conditions préalables

Je n'avais pas de sauvegardes des superblocs RAID, donc tout ce que je savais, c'était qu'il s'agissait d'une matrice RAID5 sur 8 partitions créée pendant l'installation de Xubuntu 12.04.0. Il avait un système de fichiers ext4. Un autre élément de connaissance important était la copie d'un fichier qui était également stocké sur la matrice RAID.

Outils

Le CD live Xubuntu 12.04.1 a été utilisé pour effectuer tout le travail. En fonction de votre situation, vous aurez peut-être besoin de certains des outils suivants :

version de mdadm qui permet de spécifier le décalage des données

sudo apt-get install binutils-dev git
git clone -b data_offset git://neil.brown.name/mdadm
cd mdadm
make

bgrep - recherche de données binaires

curl -L 'https://github.com/tmbinc/bgrep/raw/master/bgrep.c' | gcc -O2 -x c -o bgrep -

hexdump, e2fsck, mount et une calculatrice hexadécimale - outils standard des dépôts

Commencez par une sauvegarde complète

Nommage des fichiers du dispositif, par ex. /dev/sda2 /dev/sdb2 etc., n'est pas permanent, il est donc préférable de noter les numéros de série de vos disques donnés par

sudo hdparm -I /dev/sda

Ensuite, connectez un disque dur externe et sauvegardez chaque partition de votre matrice RAID comme ceci :

sudo dd if=/dev/sda2 bs=4M | gzip > serial-number.gz

Déterminer la disposition originale du RAID5

Différentes mises en page sont décrites ici : http://www.accs.com/p_and_p/RAID/LinuxRAID.html
Pour découvrir comment les bandes de données étaient organisées sur le tableau d'origine, vous avez besoin d'une copie d'un fichier aléatoire dont vous savez qu'il était stocké sur le tableau. La taille par défaut des morceaux actuellement utilisée par mdadm est de 512KB. Pour un tableau de N partitions, vous avez besoin d'un fichier d'une taille d'au moins (N+1)*512KB. Un jpeg ou une vidéo convient bien car il fournit des sous-chaînes relativement uniques de données binaires. Supposons que notre fichier s'appelle picture.jpg . Nous lisons 32 octets de données à N+1 positions en partant de 100k et en incrémentant de 512k :

hexdump -n32 -s100k -v -e '/1 "%02X"' picture.jpg ; echo
DA1DC4D616B1C71079624CDC36E3D40E7B1CFF00857C663687B6C4464D6C77D2
hexdump -n32 -s612k -v -e '/1 "%02X"' picture.jpg ; echo
AB9DDDBBB05CA915EE2289E59A116B02A26C82C8A8033DD8FA6D06A84B6501B7
hexdump -n32 -s1124k -v -e '/1 "%02X"' picture.jpg ; echo
BC31A8DC791ACDA4FA3E9D3406D5639619576AEE2E08C03C9EF5E23F0A7C5CBA
...

Nous recherchons ensuite les occurrences de tous ces bytestrings sur toutes nos partitions brutes, donc au total (N+1)*N commandes, comme ceci :

sudo ./bgrep DA1DC4D616B1C71079624CDC36E3D40E7B1CFF00857C663687B6C4464D6C77D2 /dev/sda2
sudo ./bgrep DA1DC4D616B1C71079624CDC36E3D40E7B1CFF00857C663687B6C4464D6C77D2 /dev/sdb2
...
sudo ./bgrep DA1DC4D616B1C71079624CDC36E3D40E7B1CFF00857C663687B6C4464D6C77D2 /dev/sdh2
/dev/sdh2: 52a7ff000
sudo ./bgrep AB9DDDBBB05CA915EE2289E59A116B02A26C82C8A8033DD8FA6D06A84B6501B7 /dev/sda2
/dev/sdb2: 52a87f000
...

Ces commandes peuvent être exécutées en parallèle pour différents disques. L'analyse d'une partition de 38 Go a pris environ 12 minutes. Dans mon cas, chaque chaîne de 32 octets a été trouvée une seule fois sur les huit disques. En comparant les offsets retournés par bgrep, on obtient une image comme celle-ci :

| offset \ partition | b | d | c | e | f | g | a | h |
|--------------------+---+---+---+---+---+---+---+---|
| 52a7ff000          | P |   |   |   |   |   |   | 1 |
| 52a87f000          | 2 | 3 | 4 | 5 | 6 | 7 | 8 | P |
| 52a8ff000          |   |   |   |   |   |   | P | 9 |

Nous voyons une personne normale symétrique gauche qui est la disposition par défaut pour mdadm . Plus important encore, nous connaissons maintenant l'ordre des partitions. Cependant, nous ne savons pas quelle partition est la première dans le tableau, car elles peuvent être décalées cycliquement.

Notez également la distance entre les décalages trouvés. Dans mon cas, c'était 512KB. La taille des morceaux peut en fait être inférieure à cette distance, auquel cas la disposition réelle sera différente.

Trouver la taille originale des morceaux

Nous utilisons le même fichier picture.jpg pour lire 32 octets de données à des intervalles différents les uns des autres. Nous savons d'après ce qui précède que la donnée à l'offset 100k se trouve sur /dev/sdh2 à l'offset 612k est à /dev/sdb2 et à 1124k, il est à /dev/sdd2 . Cela montre que la taille du morceau n'est pas supérieure à 512KB. Nous vérifions qu'elle n'est pas inférieure à 512Ko. Pour cela, nous vidons le bytestring à l'offset 356k et regardons sur quelle partition il se trouve :

hexdump -n32 -s356k -v -e '/1 "%02X"' P1080801.JPG ; echo
7EC528AD0A8D3E485AE450F88E56D6AEB948FED7E679B04091B031705B6AFA7A
sudo ./bgrep 7EC528AD0A8D3E485AE450F88E56D6AEB948FED7E679B04091B031705B6AFA7A /dev/sdb2
/dev/sdb2: 52a83f000

Il se trouve sur la même partition que l'offset 612k, ce qui indique que la taille du chunk n'est pas de 256KB. Nous éliminons les tailles de morceaux plus petites de la même manière. J'ai fini par trouver que les morceaux de 512KB étaient la seule possibilité.

Trouver la première partition dans la mise en page

Maintenant nous connaissons l'ordre des partitions, mais nous ne savons pas quelle partition devrait être la première, et quel offset de données RAID a été utilisé. Pour trouver ces deux inconnues, nous allons créer une matrice RAID5 avec une disposition correcte des morceaux et un petit décalage des données, et chercher le début de notre système de fichiers dans cette nouvelle matrice.

Pour commencer, nous créons un tableau avec l'ordre correct des partitions, que nous avons trouvé plus tôt :

sudo mdadm --stop /dev/md126
sudo mdadm --create /dev/md126 --assume-clean --raid-devices=8 --level=5  /dev/sdb2 /dev/sdd2 /dev/sdc2 /dev/sde2 /dev/sdf2 /dev/sdg2 /dev/sda2 /dev/sdh2

Nous vérifions que l'ordre est respecté en émettant

sudo mdadm --misc -D /dev/md126
...
Number   Major   Minor   RaidDevice State
   0       8       18        0      active sync   /dev/sdb2
   1       8       50        1      active sync   /dev/sdd2
   2       8       34        2      active sync   /dev/sdc2
   3       8       66        3      active sync   /dev/sde2
   4       8       82        4      active sync   /dev/sdf2
   5       8       98        5      active sync   /dev/sdg2
   6       8        2        6      active sync   /dev/sda2
   7       8      114        7      active sync   /dev/sdh2

Maintenant, nous déterminons les décalages des N+1 bytestrings connus dans la matrice RAID. Je lance un script pour une nuit (le Live CD ne demande pas de mot de passe sur sudo :) :

#!/bin/bash
echo "1st:"
sudo ./bgrep DA1DC4D616B1C71079624CDC36E3D40E7B1CFF00857C663687B6C4464D6C77D2 /dev/md126
echo "2nd:"
sudo ./bgrep AB9DDDBBB05CA915EE2289E59A116B02A26C82C8A8033DD8FA6D06A84B6501B7 /dev/md126
echo "3rd:"
sudo ./bgrep BC31A8DC791ACDA4FA3E9D3406D5639619576AEE2E08C03C9EF5E23F0A7C5CBA /dev/md126
...
echo "9th:"
sudo ./bgrep 99B5A96F21BB74D4A630C519B463954EC096E062B0F5E325FE8D731C6D1B4D37 /dev/md126

Sortie avec commentaires :

1st:
/dev/md126: 2428fff000 # 1st
2nd:
/dev/md126: 242947f000 # 480000 after 1st
3rd:                   # 3rd not found
4th:
/dev/md126: 242917f000 # 180000 after 1st
5th:
/dev/md126: 24291ff000 # 200000 after 1st
6th:
/dev/md126: 242927f000 # 280000 after 1st
7th:
/dev/md126: 24292ff000 # 300000 after 1st
8th:
/dev/md126: 242937f000 # 380000 after 1st
9th:
/dev/md126: 24297ff000 # 800000 after 1st

Sur la base de ces données, nous voyons que la 3ème corde n'a pas été trouvée. Cela signifie que le chunk à /dev/sdd2 est utilisé pour la parité. Voici une illustration des positions de parité dans le nouveau tableau :

| offset \ partition | b | d | c | e | f | g | a | h |
|--------------------+---+---+---+---+---+---+---+---|
| 52a7ff000          |   |   | P |   |   |   |   | 1 |
| 52a87f000          | 2 | P | 4 | 5 | 6 | 7 | 8 |   |
| 52a8ff000          | P |   |   |   |   |   |   | 9 |

Notre objectif est de déduire à partir de quelle partition il faut commencer le tableau, afin de placer les morceaux de parité au bon endroit. Puisque la parité doit être décalée de deux morceaux vers la gauche, la séquence de partition doit être décalée de deux pas vers la droite. Ainsi, la disposition correcte pour ce décalage de données est ahbdcefg :

sudo mdadm --stop /dev/md126
sudo mdadm --create /dev/md126 --assume-clean --raid-devices=8 --level=5  /dev/sda2 /dev/sdh2 /dev/sdb2 /dev/sdd2 /dev/sdc2 /dev/sde2 /dev/sdf2 /dev/sdg2 

À ce stade, notre réseau RAID contient des données sous la bonne forme. Vous aurez peut-être la chance que le décalage des données du RAID soit le même que celui de la matrice d'origine, et vous serez alors probablement en mesure de monter la partition. Malheureusement, ce n'était pas mon cas.

Vérifier la cohérence des données

Nous vérifions que les données sont cohérentes sur une bande de morceaux en extrayant une copie de picture.jpg du tableau. Pour cela, nous situons le décalage de la chaîne de 32 octets à 100k :

sudo ./bgrep DA1DC4D616B1C71079624CDC36E3D40E7B1CFF00857C663687B6C4464D6C77D2 /dev/md126

Nous soustrayons ensuite 100*1024 du résultat et utilisons la valeur décimale obtenue en skip= pour dd . Le site count= est la taille de picture.jpg en octets :

sudo dd if=/dev/md126 of=./extract.jpg bs=1 skip=155311300608 count=4536208

Vérifiez que extract.jpg est la même chose que picture.jpg .

Trouver l'offset de données RAID

Remarque : le décalage des données par défaut pour mdadm La version 3.2.3 est de 2048 secteurs. Mais cette valeur a été modifiée au fil du temps. Si le tableau d'origine utilisait un décalage de données plus petit que votre mdadm entonces mdadm --create sin --assume-clean peut écraser le début du système de fichiers.

Dans la section précédente, nous avons créé une matrice RAID. Vérifiez quel offset de données RAID il avait en émettant pour certaines des partitions individuelles :

sudo mdadm --examine /dev/sdb2
...
    Data Offset : 2048 sectors
...

2048 secteurs de 512 octets représentent 1MB. Comme la taille des morceaux est de 512KB, le décalage actuel des données est de deux morceaux.

Si à ce stade vous avez un décalage de deux morceaux, il est probablement assez petit et vous pouvez sauter ce paragraphe.
Nous créons une matrice RAID5 avec le décalage des données d'un morceau de 512KB. Commencer un morceau plus tôt déplace la parité d'un pas vers la gauche, donc nous compensons en déplaçant la séquence de partition d'un pas vers la gauche. Ainsi, pour un décalage de données de 512 Ko, la disposition correcte est la suivante hbdcefga . Nous utilisons une version de mdadm qui prend en charge le décalage des données (voir la section Outils). Il prend le décalage en kilobytes :

sudo mdadm --stop /dev/md126
sudo ./mdadm --create /dev/md126 --assume-clean --raid-devices=8 --level=5  /dev/sdh2:512 /dev/sdb2:512 /dev/sdd2:512 /dev/sdc2:512 /dev/sde2:512 /dev/sdf2:512 /dev/sdg2:512 /dev/sda2:512

Maintenant, nous recherchons un superbloc ext4 valide. La structure du superbloc peut être trouvée ici : https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout#The_Super_Block
Nous recherchons au début du tableau les occurrences du nombre magique. s_magic suivi par s_state y s_errors . Les bytestrings à rechercher sont :

53EF01000100
53EF00000100
53EF02000100
53EF01000200
53EF02000200

Exemple de commande :

sudo ./bgrep 53EF01000100 /dev/md126
/dev/md126: 0dc80438

Le nombre magique commence 0x38 octets dans le superbloc, donc nous soustrayons 0x38 pour calculer le décalage et examiner le superbloc entier :

sudo hexdump -n84 -s0xDC80400 -v /dev/md126
dc80400 2000 00fe 1480 03f8 cdd3 0032 d2b2 0119
dc80410 ab16 00f7 0000 0000 0002 0000 0002 0000
dc80420 8000 0000 8000 0000 2000 0000 b363 51bd
dc80430 e406 5170 010d ffff ef53 0001 0001 0000
dc80440 3d3a 50af 0000 0000 0000 0000 0001 0000
dc80450 0000 0000                              

Cela semble être un superbloc valide. s_log_block_size en 0x18 est 0002, ce qui signifie que la taille du bloc est de 2^(10+2)=4096 octets. s_blocks_count_lo à 0x4 est de 03f81480 blocs qui est de 254GB. Cela semble bon.

Nous recherchons maintenant les occurrences des premiers octets du superbloc pour trouver ses copies. Notez l'inversion des octets par rapport à la sortie hexdump :

sudo ./bgrep 0020fe008014f803d3cd3200 /dev/md126
/dev/md126: 0dc80400    # offset by 1024 bytes from the start of the FS        
/dev/md126: 15c80000    # 32768 blocks from FS start
/dev/md126: 25c80000    # 98304
/dev/md126: 35c80000    # 163840
/dev/md126: 45c80000    # 229376
/dev/md126: 55c80000    # 294912
/dev/md126: d5c80000    # 819200
/dev/md126: e5c80000    # 884736
/dev/md126: 195c80000
/dev/md126: 295c80000

Cela s'aligne parfaitement avec les positions attendues des superblocs de secours :

sudo mke2fs -n /dev/md126
...
Block size=4096 (log=2)
...
Superblock backups stored on blocks: 
    32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
    4096000, 7962624, 11239424, 20480000, 23887872

Par conséquent, le système de fichiers commence à l'offset 0xdc80000, c'est-à-dire à 225792KB du début de la partition. Comme nous avons 8 partitions dont une pour la parité, nous divisons le décalage par 7, ce qui donne un décalage de 33030144 octets sur chaque partition, soit exactement 63 morceaux RAID. Et comme le décalage actuel des données RAID est d'un chunk, nous en concluons que le décalage original des données était de 64 chunks, soit 32768KB. Déplacement de hbdcefga 63 fois à droite donne la disposition bdcefgah .

Nous construisons enfin la bonne matrice RAID :

sudo mdadm --stop /dev/md126
sudo ./mdadm --create /dev/md126 --assume-clean --raid-devices=8 --level=5  /dev/sdb2:32768 /dev/sdd2:32768 /dev/sdc2:32768 /dev/sde2:32768 /dev/sdf2:32768 /dev/sdg2:32768 /dev/sda2:32768 /dev/sdh2:32768
sudo fsck.ext4 -n /dev/md126
e2fsck 1.42 (29-Nov-2011)
Warning: skipping journal recovery because doing a read-only filesystem check.
/dev/md126: clean, 423146/16654336 files, 48120270/66589824 blocks
sudo mount -t ext4 -r /dev/md126 /home/xubuntu/mp

Voilà !

Si vous êtes chanceux vous pourriez réussir à récupérer vos fichiers avec un logiciel de récupération capable de lire une matrice RAID-5 cassée. Recouvrement par hypothèse zéro est une méthode avec laquelle j'ai déjà eu du succès.

Cependant, je ne suis pas sûr que le processus de création d'un nouveau tableau ait détruit toutes les données, il s'agit donc d'un effort de la dernière chance.

J'ai eu un problème similaire. J'ai formaté et réinstallé mon OS/disque de démarrage avec une installation propre d'Ubuntu 12.04, puis j'ai lancé la commande mdadm --create... et je n'ai pas pu le monter.

Il a dit qu'il n'y avait pas de superbloc ou de partition valide.

De plus, lorsque j'ai arrêté le raid mdadm, je ne pouvais plus monter le périphérique ordinaire.

J'ai pu réparer le superbloc avec mke2fs et e2fsck :

root@blackbox:~# mke2fs -n /dev/sdc1
mke2fs 1.42 (29-Nov-2011)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
91578368 inodes, 366284000 blocks
18314200 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=4294967296
11179 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks: 
  32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
  4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, 
  102400000, 214990848

Puis a couru :

e2fsck -b 32768 -y /dev/sdc1

Cela a restauré le superbloc pour que je puisse monter et lire le disque.

Pour faire fonctionner le tableau sans détruire le superbloc ou les partitions, j'ai utilisé build :

mdadm --build /dev/md0 --level=mirror --assume-clean --raid-devices=2  /dev/sdc1 missing 

Après avoir vérifié les données, je vais ajouter l'autre disque :

mdadm --add /dev/md0 /sdd1

Je ne fais que mettre à jour certaines des informations données précédemment. J'avais une matrice raid5 à 3 disques qui fonctionnait bien quand ma carte mère est morte. La matrice contenait /dev/md2 comme partition /home 1.2TB et /dev/md3 comme partition /var 300GB.

J'avais deux sauvegardes de choses "importantes" et un tas de choses aléatoires que j'avais récupérées à divers endroits sur Internet et que j'aurais vraiment dû parcourir et jeter de manière sélective. La plupart des sauvegardes étaient divisées en fichiers .tar.gz de 25 Go ou moins, et une copie séparée de /etc était également sauvegardée.

Le reste du système de fichiers se trouvait sur deux petits disques raid0 de 38 Go.

Ma nouvelle machine était similaire à l'ancien matériel, et j'ai pu la faire fonctionner en branchant les cinq disques et en sélectionnant un vieux noyau générique. J'avais donc cinq disques avec des systèmes de fichiers propres, mais je ne pouvais pas être certain que les disques étaient dans le bon ordre, et j'ai dû installer une nouvelle version de Debian Jessie pour être sûr de pouvoir mettre la machine à niveau si nécessaire, et résoudre d'autres problèmes.

Avec le nouveau système générique installé sur deux disques Raid0, j'ai commencé à remonter les matrices. Je voulais être sûr que les disques étaient dans le bon ordre. Ce que j'aurais dû faire, c'est émettre :

mdadm --assemble /dev/md3 -o --no-degraded --uuid=82164ae7:9af3c5f1:f75f70a5:ba2a159a

Mais je ne l'ai pas fait. Il semble que mdadm soit assez intelligent et qu'avec un uuid, il puisse déterminer quels lecteurs vont où. Même si le bios désigne /dev/sdc comme /sda, mdadm les assemblera correctement (YMMV cependant).

Au lieu de cela, j'ai émis : mdadm --create /dev/md2 without the --assume-clean et a permis à la resynchronisation sur /dev/sde1 de se terminer. L'erreur suivante que j'ai faite a été de travailler sur /dev/sdc1 au lieu du dernier lecteur dans le /dev/md2, /sde1. Chaque fois que mdadm pense qu'il y a un problème, c'est le dernier disque qui est expulsé ou resynchronisé.

Après cela, mdadm n'a pas pu trouver de superbloc, et e2fsck -n n'a pas pu non plus.

Après avoir trouvé cette page, j'ai suivi la procédure pour essayer de trouver la séquence des disques (fait), vérifier les données valides (vérifié 6MB d'un fichier de 9MB), obtenir les disques dans la bonne séquence, cde, récupérer les uuid's de /md2 et /md3 à partir de l'ancien /etc/mdadm.conf et essayer d'assembler.

Bien, /dev/md3 a commencé, et mdadm --misc -D /dev/md3 a montré trois partitions saines, et les disques dans le bon ordre. /dev/md2 semblait également bon, jusqu'à ce que j'essaie de monter le système de fichiers.

# mdadm --create /dev/md2 --raid-devices=3 --level=5 --uuid=c0a644c7:e5bcf758:ecfbc8f3:ee0392b7 /dev/sdc1 /dev/sdd1 /dev/sde1
mdadm: /dev/sdc1 appears to be part of a raid array:
       level=raid5 devices=3 ctime=Wed Feb  3 14:05:36 2016
mdadm: /dev/sdd1 appears to contain an ext2fs file system
       size=585936896K  mtime=Thu Jan  1 01:00:00 1970
mdadm: /dev/sdd1 appears to be part of a raid array:
       level=raid5 devices=3 ctime=Wed Feb  3 14:05:36 2016
mdadm: /dev/sde1 appears to contain an ext2fs file system
       size=585936896K  mtime=Thu Jan  1 01:00:00 1970
mdadm: /dev/sde1 appears to be part of a raid array:
       level=raid5 devices=3 ctime=Wed Feb  3 14:05:36 2016
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md2 started.

Le système de fichiers a refusé d'être monté, et e2fsck n'a pas pu trouver de superblocs. De plus, en vérifiant les superblocs comme décrit ci-dessus, le nombre total de blocs trouvé comme a880 0076 ou a880 0076 ou 5500 1176 ne correspondait pas à la taille de la capacité du disque de 1199.79 signalée par mdadm. De plus, aucun des emplacements des "superblocs" ne correspond aux données des messages ci-dessus.

J'ai sauvegardé tout /var, et je me suis préparé à effacer les disques. Pour voir s'il était possible d'effacer seulement /md2, (je n'avais rien d'autre à perdre à ce stade) j'ai fait ce qui suit :

root@ced2:/home/richard# mdadm --create /dev/md2 --raid-devices=3 --level=5 --uuid=c0a644c7:e5bcf758:ecfbc8f3:ee0392b7 /dev/sdc1 /dev/sdd1 /dev/sde1
mdadm: /dev/sdc1 appears to be part of a raid array:
       level=raid5 devices=3 ctime=Wed Feb  3 14:05:36 2016
mdadm: /dev/sdd1 appears to contain an ext2fs file system
       size=585936896K  mtime=Thu Jan  1 01:00:00 1970
mdadm: /dev/sdd1 appears to be part of a raid array:
       level=raid5 devices=3 ctime=Wed Feb  3 14:05:36 2016
mdadm: /dev/sde1 appears to contain an ext2fs file system
       size=585936896K  mtime=Thu Jan  1 01:00:00 1970
mdadm: /dev/sde1 appears to be part of a raid array:
       level=raid5 devices=3 ctime=Wed Feb  3 14:05:36 2016
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md2 started.
# mkfs.ext3 /dev/md2
mke2fs 1.42.12 (29-Aug-2014)
Creating filesystem with 292902912 4k blocks and 73228288 inodes
Filesystem UUID: a54e252f-78db-4ebb-b7ca-7dcd2edf57a4
Superblock backups stored on blocks: 
    32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
    4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, 
    102400000, 214990848

Allocating group tables: done                            
Writing inode tables: done                            
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done 

# hexdump -n84 -s0x00000400 -v /dev/md2
0000400 6000 045d 5800 1175 7799 00df 6ff0 112e
0000410 5ff5 045d 0000 0000 0002 0000 0002 0000
0000420 8000 0000 8000 0000 2000 0000 10d3 56b2
0000430 10d3 56b2 0002 ffff ef53 0001 0001 0000
0000440 0c42 56b2 0000 0000 0000 0000 0001 0000
0000450 0000 0000                              
0000454

#  ./bgrep 00605D0400587511 /dev/md2
/dev/md2: 00000400
/dev/md2: 08000000
/dev/md2: 18000000
/dev/md2: 28000000
/dev/md2: 38000000
/dev/md2: 48000000
/dev/md2: c8000000
/dev/md2: d8000000
/dev/md2: 188000000
/dev/md2: 288000000
/dev/md2: 3e8000000
/dev/md2: 798000000
/dev/md2: ab8000000
etc

Tout semble correct, à l'exception de la modification de l'uuid. Donc après quelques vérifications supplémentaires, j'ai écrit 600GB de données sauvegardées sur /dev/md2. Ensuite, j'ai démonté et essayé de remonter le disque :

# mdadm --assemble /dev/md2 uuid=c0a644c7:e5bcf758:ecfbc8f3:ee0392b7
mdadm: cannot open device uuid=c0a644c7:e5bcf758:ecfbc8f3:ee0392b7: No such file or directory
mdadm: uuid=c0a644c7:e5bcf758:ecfbc8f3:ee0392b7 has no superblock - assembly aborted

Vous vous moquez de moi, ********* ? Et mes 600 Go sur le dossier ?

# mdadm --assemble /dev/md2 
mdadm: /dev/md2 not identified in config file.

Ah - facilement corrigé. Décommenté une ligne dans /etc/mdadm.conf

# mdadm --assemble /dev/md2 
mdadm: /dev/md2 has been started with 3 drives.

# e2fsck -n /dev/md2
e2fsck 1.42.12 (29-Aug-2014)
/dev/md2: clean, 731552/73228288 files, 182979586/292902912 blocks

Yippie !