Récupérer la matrice RAID5 du logiciel Linux après la mise à niveau du serveur

J'ai récemment mis à niveau un serveur de Fedora 6 vers Fedora 14. En plus du disque dur principal sur lequel le système d'exploitation est installé, j'ai 3 disques durs de 1 To configurés pour RAID5 (via le logiciel). Après la mise à niveau, j'ai remarqué que l'un des disques durs avait été retiré du tableau RAID. J'ai essayé de le rajouter avec mdadm --add, mais il l'a simplement mis en réserve. Je pensais y revenir plus tard.

Ensuite, lors du redémarrage, le système ne pouvait pas du tout monter le tableau RAID. Je l'ai retiré du fstab pour pouvoir démarrer le système, et j'essaie maintenant de restaurer le tableau RAID.

J'ai couru ce qui suit:

mdadm --create /dev/md0 --assume-clean --level=5 --chunk=64 --raid-devices=3 missing /dev/sdc1 /dev/sdd1

Je sais que ma taille de bloc est de 64 Ko et que "manquant" concerne le lecteur qui a été expulsé du tableau (/ dev / sdb1).

Cela a semblé fonctionner et mdadm a signalé que la baie de disques est en cours d'exécution "en mode minimal, avec dégradation" avec le lecteur manquant.

Cependant, je ne peux pas monter le tableau RAID. Quand j'essaye:

mount -t ext3 /dev/md0 /mnt/foo

Je reçois:

mount: wrong fs type, bad option, bad superblock on /dev/md0,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

et / var / log / messages affiche:

EXT3-fs (md0): error: can't find ext3 filesystem on dev md0.

Quelqu'un at-il une idée de ce qu'il faut essayer ensuite?

Vous pouvez avoir le missing sur la mauvaise position. Seule la position correcte des lecteurs et missing marchera. Il suffit de courir:

mdadm --examine  /dev/sdb1

Ceci produira (entre autres) l’information dont le numéro dans le RAID est vraiment manquant. Cherchez le this ligne:

      Number   Major   Minor   RaidDevice State
this     0     253       13        0      active sync   /dev/dm-13

Dans ce cas, il s’agit du numéro 0 (= premier appareil) et active comme mon RAID est en ligne en ce moment. Maintenant, vous savez quel lecteur doit être spécifié comme missing.

Mais vous avez encore 2 choix: L'ordre des travail les lecteurs peuvent également avoir besoin d'être échangés. Cette information est cependant perdue car elle a été écrasée par votre tentative de réassemblage.

l'une des choses que j'ai trouvées est que mdadm --create /dev/md0 --assume-clean ne fonctionnera correctement que si vous utilisez la même version (ou fermez) de mdadm qui a été utilisée pour créer le tableau original. C'est parce qu'ils utilisent différents décalages pour les données et les métadonnées, même si la même version de superbloc (comme 1.2)

Le problème est que la sortie de mdadm indiquera toujours que le tableau recréé est correct, mais que les données contenues dans / dev / md0 seront fausses.

Par exemple, utiliser les versions récentes de mdadm 3.3.2 ou même de la version 3.2.5 précédente ne fonctionnait pas pour moi, mais le retour à mdadm 3.1.4 (qui a créé le tableau) fonctionnait parfaitement.

Notez que j’ai également pris soin de spécifier les lecteurs dans le bon ordre (comme indiqué dans mdadm --examine /dev/sd? ) lorsque vous recréez un tableau et utilisez des fichiers de superposition pour tous les tests (afin de ne pas augmenter les dégâts), en suivant les instructions https://raid.wiki.kernel.org/index.php/Recovering_a_failed_software_RAID

Dans mon cas, le problème était le RAID5 à 6 disques, qui passait à 7 disques, mais il ne progressait pas du tout, il a donc été abandonné et ne pouvait plus être assemblé avec mdadm: Failed to restore critical section for reshape, sorry., et --force et --invalid-backup n'aidaient pas non plus, alors j'ai dû utiliser --create --assume-clean