Como recuperar uma matriz RAID5 do Linux md com falha?

Question

Algum tempo atrás, eu tinha um sistema RAID5 em casa. Um dos 4 discos falhou, mas depois de removê-lo e colocá-lo de volta, pareceu-me bem, por isso iniciei uma ressincronização. Quando terminou, percebi, para meu horror, que 3 dos 4 discos falharam. No entanto, não acredito que isso seja possível. Existem várias partições nos discos de cada parte de uma matriz RAID diferente.

• md0 é um array RAID1 composto por sda1, sdb1, sdc1 e sdd1.
• md1 é um array RAID5 composto por sda2, sdb2, sdc2 e sdd2.
• md2 é um array RAID0 composto por sda3, sdb3, sdc3 e sdd3.

md0 e md2 informam todos os discos enquanto o md1 reporta 3 com falha (sdb2, sdc2, sdd2). É meu entendimento que, quando os discos rígidos falham, todas as partições devem ser perdidas, não apenas as do meio.

Nesse momento, desliguei o computador e desconectei as unidades. Desde então, eu estava usando esse computador com um novo disco menor.

Existe alguma esperança de recuperar os dados? Posso de alguma forma convencer o mdadm de que meus discos estão de fato funcionando? O único disco que pode realmente ter um problema é o sdc, mas esse também é informado pelos outros arrays.

Atualizar

Eu finalmente tive a chance de conectar os discos antigos e inicializar esta máquina a partir do SystemRescueCd. Tudo acima foi escrito da memória. Agora eu tenho alguns dados concretos. Aqui está a saída de mdadm --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

Parece que as coisas mudaram desde a última inicialização. Se eu estiver lendo isso corretamente, sda2, sdb2 e sdc2 estão funcionando e contêm dados sincronizados e o sdd2 é de reposição. Lembro-me distintamente de ver três discos com defeito, mas isso é uma boa notícia. No entanto, o array ainda não está funcionando:

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 parece ser renomeado para md127. md125 e md126 são muito estranhos. Eles devem ser um array, não dois. Isso costumava ser chamado md1. md2 foi completamente embora, mas essa foi minha troca, então não me importo.

Eu posso entender os nomes diferentes e isso realmente não importa. Mas por que uma matriz com 3 discos de "sincronização ativa" é ilegível? E o que acontece com o sdd2 estar em uma matriz separada?

Atualizar

Eu tentei o seguinte depois de fazer o backup dos superblocos:

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

Até aí tudo bem. Como o sdd2 é de reposição, não quero adicioná-lo ainda.

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

Aparentemente, não posso fazer isso.

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>

Isso também não funcionou. Vamos tentar com todos os discos.

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>

Sem sorte. Com base em esta resposta , estou planejando para tentar:

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

É seguro?

Atualizar

Eu publico o script do analisador de superblocos que usei para fazer essa tabela no meu comentário. Talvez alguém ache útil. Obrigado por toda sua ajuda.

    

Answer 1

Primeiro, verifique os discos, tente executar o autoteste inteligente

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

Pode demorar algumas horas para terminar, mas verifique o status de teste de cada unidade a cada alguns minutos, ou seja,

smartctl -l selftest /dev/sda

Se o status de um disco não for concluído devido a erros de leitura, este disco deve ser considerado inseguro para a remontagem de md1. Após o término do autoteste, você pode começar a tentar remontar sua matriz. Opcionalmente, se você quiser ser mais cauteloso, mova os discos para outra máquina antes de continuar (apenas no caso de memória RAM / controladora / etc).

Recentemente, tive um caso exatamente como este. Uma unidade falhou, eu adicionei novamente na matriz, mas durante a reconstrução, 3 de 4 unidades falharam completamente. O conteúdo de / proc / mdadm era o mesmo que o seu (talvez não na mesma ordem)

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

Mas eu tive sorte e reagrupei o array com isso

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

Olhando para a saída --examine que você forneceu, eu posso dizer que o seguinte cenário aconteceu: sdd2 falhou, você removeu e adicionou novamente, então ele se tornou uma unidade sobressalente tentando reconstruir. Mas enquanto reconstrução sda2 falhou e, em seguida, sdb2 falhou. Portanto, o contador de eventos é maior em sdc2 e sdd2, que são as últimas unidades ativas na matriz (embora o sdd não tenha a chance de ser reconstruído e, portanto, é o mais desatualizado de todos). Por causa das diferenças nos contadores de eventos, --force será necessário. Então você também pode tentar isso

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

Para concluir, acho que se o comando acima falhar, você deve tentar recriar o array assim:

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

Se você fizer o --create , a parte missing é importante, não tente adicionar uma quarta unidade na matriz, porque a construção começará e você perderá seus dados . Criar a matriz com uma unidade ausente não alterará seu conteúdo e você terá a chance de obter uma cópia em outro lugar (o raid5 não funciona da mesma maneira que o raid1).

Se isso falhar em trazer a matriz, tente esta solução (script perl) aqui Recriando uma matriz

Se você finalmente conseguir trazer a matriz para cima, o sistema de arquivos ficará sujo e provavelmente corrompido. Se um disco falhar durante a reconstrução, espera-se que o array pare e congele sem fazer gravações nos outros discos. Nesse caso, dois discos falharam, talvez o sistema estava executando solicitações de gravação que não puderam ser concluídas; portanto, há uma pequena chance de você perder alguns dados, mas também uma chance de nunca perceber : -)

edit: alguns esclarecimentos adicionados.

    

Answer 2

Eu tive muitos problemas enquanto usei mdadm , mas nunca perdi dados. Você deve evitar a opção --force , ou usá-la com muito cuidado, porque você pode perder todos os seus dados. Por favor, poste seu /etc/mdadm/mdadm.conf