Comment récupérer une matrice Linux md RAID5 en panne?

Il y a quelque temps, j'avais un système RAID5 à la maison. L'un des 4 disques est tombé en panne, mais après l'avoir retiré et remis en place, il semblait être correct, alors j'ai commencé une resynchronisation. Quand il a fini, j'ai réalisé, à ma grande horreur, que 3 disques sur 4 ont échoué. Mais je ne crois pas que ce soit possible. Il existe plusieurs partitions sur les disques, chaque partie d'une matrice RAID différente.

• md0 est une matrice RAID1 composée de sda1, sdb1, sdc1 et sdd1.
• md1 est une matrice RAID5 composée de sda2, sdb2, sdc2 et sdd2.
• md2 est une matrice RAID0 composée de sda3, sdb3, sdc3 et sdd3.

md0 et md2 signale tous les disques alors que md1 signale 3 échecs (sdb2, sdc2, sdd2). C'est ma compréhension que lorsque les disques durs échouent, toutes les partitions doivent être perdues, pas seulement celles du milieu.

À ce stade, j'ai éteint l'ordinateur et débranché les disques. Depuis lors, j'utilisais cet ordinateur avec un nouveau disque plus petit.

Y a-t-il un espoir de récupérer les données? Puis-je en quelque sorte convaincre mdadm que mes disques fonctionnent en fait? Le seul disque qui peut vraiment avoir un problème est sdc mais celui-là aussi est signalé par les autres baies.

Mise à jour

J'ai enfin eu la chance de connecter les anciens disques et de démarrer cette machine à partir de SystemRescueCd. Tout ce qui précède a été écrit de mémoire. Maintenant, j'ai des données solides. Voici la sortie demdadm --examine /dev/sd*2

/dev/sda2:
          Magic : a92b4efc
        Version : 0.90.00
           UUID : 53eb7711:5b290125:db4a62ac:7770c5ea
  Creation Time : Sun May 30 21:48:55 2010
     Raid Level : raid5
  Used Dev Size : 625064960 (596.11 GiB 640.07 GB)
     Array Size : 1875194880 (1788.33 GiB 1920.20 GB)
   Raid Devices : 4
  Total Devices : 4
Preferred Minor : 1

    Update Time : Mon Aug 23 11:40:48 2010
          State : clean
 Active Devices : 3
Working Devices : 4
 Failed Devices : 1
  Spare Devices : 1
       Checksum : 68b48835 - correct
         Events : 53204

         Layout : left-symmetric
     Chunk Size : 64K

      Number   Major   Minor   RaidDevice State
this     0       8        2        0      active sync   /dev/sda2

   0     0       8        2        0      active sync   /dev/sda2
   1     1       8       18        1      active sync   /dev/sdb2
   2     2       8       34        2      active sync   /dev/sdc2
   3     3       0        0        3      faulty removed
   4     4       8       50        4      spare   /dev/sdd2
/dev/sdb2:
          Magic : a92b4efc
        Version : 0.90.00
           UUID : 53eb7711:5b290125:db4a62ac:7770c5ea
  Creation Time : Sun May 30 21:48:55 2010
     Raid Level : raid5
  Used Dev Size : 625064960 (596.11 GiB 640.07 GB)
     Array Size : 1875194880 (1788.33 GiB 1920.20 GB)
   Raid Devices : 4
  Total Devices : 4
Preferred Minor : 1

    Update Time : Mon Aug 23 11:44:54 2010
          State : clean
 Active Devices : 2
Working Devices : 3
 Failed Devices : 1
  Spare Devices : 1
       Checksum : 68b4894a - correct
         Events : 53205

         Layout : left-symmetric
     Chunk Size : 64K

      Number   Major   Minor   RaidDevice State
this     1       8       18        1      active sync   /dev/sdb2

   0     0       0        0        0      removed
   1     1       8       18        1      active sync   /dev/sdb2
   2     2       8       34        2      active sync   /dev/sdc2
   3     3       0        0        3      faulty removed
   4     4       8       50        4      spare   /dev/sdd2
/dev/sdc2:
          Magic : a92b4efc
        Version : 0.90.00
           UUID : 53eb7711:5b290125:db4a62ac:7770c5ea
  Creation Time : Sun May 30 21:48:55 2010
     Raid Level : raid5
  Used Dev Size : 625064960 (596.11 GiB 640.07 GB)
     Array Size : 1875194880 (1788.33 GiB 1920.20 GB)
   Raid Devices : 4
  Total Devices : 4
Preferred Minor : 1

    Update Time : Mon Aug 23 11:44:54 2010
          State : clean
 Active Devices : 1
Working Devices : 2
 Failed Devices : 2
  Spare Devices : 1
       Checksum : 68b48975 - correct
         Events : 53210

         Layout : left-symmetric
     Chunk Size : 64K

      Number   Major   Minor   RaidDevice State
this     2       8       34        2      active sync   /dev/sdc2

   0     0       0        0        0      removed
   1     1       0        0        1      faulty removed
   2     2       8       34        2      active sync   /dev/sdc2
   3     3       0        0        3      faulty removed
   4     4       8       50        4      spare   /dev/sdd2
/dev/sdd2:
          Magic : a92b4efc
        Version : 0.90.00
           UUID : 53eb7711:5b290125:db4a62ac:7770c5ea
  Creation Time : Sun May 30 21:48:55 2010
     Raid Level : raid5
  Used Dev Size : 625064960 (596.11 GiB 640.07 GB)
     Array Size : 1875194880 (1788.33 GiB 1920.20 GB)
   Raid Devices : 4
  Total Devices : 4
Preferred Minor : 1

    Update Time : Mon Aug 23 11:44:54 2010
          State : clean
 Active Devices : 1
Working Devices : 2
 Failed Devices : 2
  Spare Devices : 1
       Checksum : 68b48983 - correct
         Events : 53210

         Layout : left-symmetric
     Chunk Size : 64K

      Number   Major   Minor   RaidDevice State
this     4       8       50        4      spare   /dev/sdd2

   0     0       0        0        0      removed
   1     1       0        0        1      faulty removed
   2     2       8       34        2      active sync   /dev/sdc2
   3     3       0        0        3      faulty removed
   4     4       8       50        4      spare   /dev/sdd2

Il semble que les choses aient changé depuis le dernier démarrage. Si je lis correctement sda2, sdb2 et sdc2 fonctionnent et contiennent des données synchronisées et sdd2 est de rechange. Je me souviens clairement d'avoir vu 3 disques en panne, mais c'est une bonne nouvelle. Pourtant, le tableau ne fonctionne toujours pas:

Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] 
md125 : inactive sda2[0](S) sdb2[1](S) sdc2[2](S)
      1875194880 blocks

md126 : inactive sdd2[4](S)
      625064960 blocks

md127 : active raid1 sda1[0] sdd1[3] sdc1[2] sdb1[1]
      64128 blocks [4/4] [UUUU]

unused devices: <none>

md0 semble avoir été renommé md127. md125 et md126 sont très étranges. Ils doivent être un tableau et non deux. Cela s'appelait autrefois md1. md2 a complètement disparu, mais c'était mon échange, donc je m'en fiche.

Je peux comprendre les différents noms et ça n'a pas vraiment d'importance. Mais pourquoi un tableau avec 3 disques de "synchronisation active" est-il illisible? Et que se passe-t-il avec sdd2 dans un tableau séparé?

Mise à jour

J'ai essayé ce qui suit après avoir sauvegardé les superblocs:

root@sysresccd /root % mdadm --stop /dev/md125
mdadm: stopped /dev/md125
root@sysresccd /root % mdadm --stop /dev/md126
mdadm: stopped /dev/md126

Jusqu'ici tout va bien. Puisque sdd2 est disponible, je ne veux pas encore l'ajouter.

root@sysresccd /root % mdadm --assemble /dev/md1 /dev/sd{a,b,c}2 missing 
mdadm: cannot open device missing: No such file or directory
mdadm: missing has no superblock - assembly aborted

Apparemment, je ne peux pas faire ça.

root@sysresccd /root % mdadm --assemble /dev/md1 /dev/sd{a,b,c}2        
mdadm: /dev/md1 assembled from 1 drive - not enough to start the array.
root@sysresccd /root % cat /proc/mdstat 
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] 
md1 : inactive sdc2[2](S) sdb2[1](S) sda2[0](S)
      1875194880 blocks

md127 : active raid1 sda1[0] sdd1[3] sdc1[2] sdb1[1]
      64128 blocks [4/4] [UUUU]

unused devices: <none>

Cela n'a pas fonctionné non plus. Essayons avec tous les disques.

mdadm --stop /dev/md1
mdadm: stopped /dev/md1
root@sysresccd /root % mdadm --assemble /dev/md1 /dev/sd{a,b,c,d}2
mdadm: /dev/md1 assembled from 1 drive and 1 spare - not enough to start the array.
root@sysresccd /root % cat /proc/mdstat                           
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] 
md1 : inactive sdc2[2](S) sdd2[4](S) sdb2[1](S) sda2[0](S)
      2500259840 blocks

md127 : active raid1 sda1[0] sdd1[3] sdc1[2] sdb1[1]
      64128 blocks [4/4] [UUUU]

unused devices: <none>

Pas de chance. Sur la base de cette réponse, je prévois d'essayer:

mdadm --create /dev/md1 --assume-clean --metadata=0.90 --bitmap=/root/bitmapfile --level=5 --raid-devices=4 /dev/sd{a,b,c}2 missing
mdadm --add /dev/md1 /dev/sdd2

Est-ce sûr?

Mise à jour

Je publie le script de l'analyseur de superbloc que j'ai utilisé pour créer ce tableau dans mon commentaire. Peut-être que quelqu'un le trouvera utile. Merci pour votre aide.

Vérifiez d'abord les disques, essayez d'exécuter l'autotest intelligent

for i in a b c d; do
    smartctl -s on -t long /dev/sd$i
done

Cela peut prendre quelques heures, mais vérifiez l'état du test de chaque lecteur toutes les quelques minutes, c'est-à-dire

smartctl -l selftest /dev/sda

Si l'état d'un disque ne se termine pas en raison d'erreurs de lecture, ce disque doit être considéré comme dangereux pour le réassemblage md1. Après l'autotest, vous pouvez commencer à réassembler votre baie. Facultativement, si vous voulez être extrêmement prudent, déplacez les disques sur une autre machine avant de continuer (juste en cas de mauvais ram / contrôleur / etc).

Récemment, j'ai eu un cas exactement comme celui-ci. Un disque a échoué, j'ai rajouté dans la baie mais pendant la reconstruction, 3 des 4 disques ont échoué. Le contenu de / proc / mdadm était le même que le vôtre (peut-être pas dans le même ordre)

md1 : inactive sdc2[2](S) sdd2[4](S) sdb2[1](S) sda2[0](S)

Mais j'ai eu de la chance et j'ai remonté le tableau avec ce

mdadm --assemble /dev/md1 --scan --force

En regardant la sortie --examine que vous avez fournie, je peux dire que le scénario suivant s'est produit: sdd2 a échoué, vous l'avez supprimé et l'ajouté à nouveau, il est donc devenu un disque de rechange essayant de reconstruire. Mais lors de la reconstruction, sda2 a échoué, puis sdb2 a échoué. Le compteur d'événements est donc plus grand dans sdc2 et sdd2 qui sont les derniers disques actifs de la matrice (bien que sdd n'ait pas eu la chance de reconstruire et qu'il soit donc le plus obsolète de tous). En raison des différences dans les compteurs d'événements, --force sera nécessaire. Vous pouvez donc également essayer ceci

mdadm --assemble /dev/md1 /dev/sd[abc]2 --force

Pour conclure, je pense que si la commande ci-dessus échoue, vous devriez essayer de recréer le tableau comme ceci:

mdadm --create /dev/md1 --assume-clean -l5 -n4 -c64 /dev/sd[abc]2 missing

Si vous faites cela --create, la missingpartie est importante, n'essayez pas d'ajouter un quatrième lecteur dans la matrice, car alors la construction commencera et vous perdrez vos données . La création de la matrice avec un disque manquant ne changera pas son contenu et vous aurez la possibilité d'en obtenir une copie ailleurs (raid5 ne fonctionne pas de la même manière que raid1).

Si cela ne parvient pas à mettre le tableau en place, essayez cette solution (script perl) ici Recréer un tableau

Si vous parvenez enfin à mettre le tableau en place, le système de fichiers sera impur et probablement corrompu. Si un disque tombe en panne pendant la reconstruction, il est prévu que la baie s'arrête et se bloque en ne faisant aucune écriture sur les autres disques. Dans ce cas, deux disques ont échoué, peut - être que le système effectuait des demandes d'écriture qui n'ont pas pu se terminer, il y a donc une petite chance que vous ayez perdu des données, mais aussi une chance que vous ne le remarquerez jamais :-)

edit: quelques éclaircissements ajoutés.

J'ai rencontré de nombreux problèmes lors de mon utilisation mdadm, mais je n'ai jamais perdu de données. Vous devez éviter cette --forceoption ou l'utiliser avec beaucoup de prudence, car vous risquez de perdre toutes vos données. Veuillez poster votre/etc/mdadm/mdadm.conf