Como recuperar uma matriz Linux md RAID5 com falha?

17

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 parecia bom, então iniciei uma ressincronização. Quando terminou, percebi, para meu horror, que 3 em cada 4 discos falharam. No entanto, eu não acredito que isso seja possível. Existem várias partições nos discos, cada parte de uma matriz RAID diferente.

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

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

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

Existe alguma esperança de recuperar os dados? De alguma forma, posso convencer o mdadm de que meus discos estão realmente funcionando? O único disco que pode realmente ter um problema é o sdc, mas esse também é relatado pelas outras matrizes.

Atualizar

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

Parece que as coisas mudaram desde a última inicialização. Se estou lendo isso corretamente sda2, sdb2 e sdc2 estão funcionando e contêm dados sincronizados e sdd2 é sobressalente. Lembro-me claramente de ter visto 3 discos com falha, mas esta é uma boa notícia. No entanto, a matriz 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 ter sido renomeado para md127. MD125 e MD126 são muito estranhos. Eles devem ser uma matriz e não duas. Isso costumava ser chamado md1. MD2 se foi completamente, mas essa foi a minha troca, então eu não me importo.

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

Atualizar

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

Por enquanto, tudo bem. Como o sdd2 é sobressalente, 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 nesta resposta, pretendo 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 publicar o roteiro analisador superbloco eu costumava fazer essa mesa no meu comentário. Talvez alguém ache útil. Obrigado por toda sua ajuda.

stribika
fonte
Eu acho mdadm --re-addque não é o que você está procurando. Você fez um teste de memória recentemente? Você tem alguma mensagem de log relacionada à falha da matriz?
Gilles 'SO- stop be evil'
@ Gilles: Não tenho registros anteriores à falha, pois eles foram armazenados na matriz com falha. E acho que não posso consertá-lo com a interface mdadm padrão. Qualquer tipo de operação que envolva uma ressincronização é impossível com 1 de 4 discos. Eu acho que os 3 discos "com falha" contêm informações suficientes para restaurar tudo. Por exemplo, eu posso lê-los com dd. O "bom" pode estar fora de sincronia. Farei um teste de mem mas a máquina agora está funcionando perfeitamente com um novo disco.
stribika
2
Você tentou parar o array e remontar um novo com mdadm -A /dev/md1 /dev/sd{b,c,d}2(talvez --force)? (Se você não tiver, faça o backup dos superblocos primeiro.)
Gilles 'SO- stop be evil'
@ Gilles: atualizei minha pergunta com informações atualizadas. Do que preciso fazer backup exatamente? Os primeiros blocos dos discos ou existe uma ferramenta específica para isso?
stribika
@ stribika: O superbloco é o último bloco completo de 64kB alinhado em um limite de 64kB na partição. Eu não tenho idéia de como /dev/sdd2pode estar em uma matriz separada, apesar de ter o mesmo UUID que sd{a,b,c}2.
Gilles 'SO- stop be evil'

Respostas:

12

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 levar algumas horas para terminar, mas verifique o status de teste de cada unidade a cada poucos minutos, ou seja,

smartctl -l selftest /dev/sda

Se o status de um relatório de disco não for concluído devido a erros de leitura, esse disco deverá ser considerado inseguro para a remontagem md1. Após a conclusão 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 uma ram / controlador ruim / 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 tive sorte e remontei a matriz com este

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

Observando a saída --examine que você forneceu, posso dizer que o seguinte cenário aconteceu: sdd2 falhou, você a removeu e a adicionou novamente, tornando-se uma unidade sobressalente tentando reconstruir. Mas durante a reconstrução do sda2 falhou e, em seguida, o 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 tido a chance de reconstruir e, portanto, seja o mais desatualizado de todos). Devido às 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 a matriz assim:

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

Se você fizer isso --create, a missingpeça é 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 mudará seu conteúdo e você terá a chance de obter uma cópia em outro lugar (o raid5 não funciona da mesma forma que o raid1).

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

Se você finalmente conseguir criar a matriz, o sistema de arquivos será impuro e provavelmente corrompido. Se um disco falhar durante a reconstrução, é esperado que a matriz pare e congele, não fazendo gravações nos outros discos. Nesse caso, dois discos falharam, talvez o sistema esteja 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 você nunca notá-los :-)

editar: alguns esclarecimentos adicionados.

forcefsck
fonte
mdadm --assemble /dev/md1 /dev/sd[abc]2 --forcetrabalhou. Obrigado. Você salvou meus dados! :) Não tentarei adicionar o quarto disco porque os três primeiros não são tão bons quanto eu pensava anteriormente. O autoteste revelou que cada um tem 10 a 20 blocos ilegíveis. Eu me sinto estúpido por não ter verificado isso primeiro.
stribika
Obrigado por uma resposta abrangente. Recompensado com 50 representantes de mim.
0xC0000022L
Permute_array.pl funcionou muito bem para mim. Nota para outros usuários: a matriz de dispositivos que espera ver inclui todas as unidades, incluindo qualquer unidade morta que você possa ter removido.
"Se você criar o --create, a parte que falta é importante, não tente adicionar uma quarta unidade na matriz, porque a construção começará e você perderá seus dados." - BS. Se você especificou --assume-clean( você especificou ), isso não acontecerá.
poige
1

Tive muitos problemas enquanto usava mdadm, mas nunca perdi dados. Você deve evitar a --forceopção ou usá-la com muito cuidado, pois pode perder todos os seus dados. Por favor, publique seu/etc/mdadm/mdadm.conf

Glendyr
fonte