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.
fonte
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?mdadm -A /dev/md1 /dev/sd{b,c,d}2(talvez--force)? (Se você não tiver, faça o backup dos superblocos primeiro.)/dev/sdd2pode estar em uma matriz separada, apesar de ter o mesmo UUID quesd{a,b,c}2.Respostas:
Primeiro verifique os discos, tente executar o autoteste inteligente
Pode levar algumas horas para terminar, mas verifique o status de teste de cada unidade a cada poucos minutos, ou seja,
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)
Mas tive sorte e remontei a matriz com este
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
Para concluir, acho que se o comando acima falhar, você deve tentar recriar a matriz assim:
Se você fizer isso
--create, amissingpeç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.
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.--assume-clean( você especificou ), isso não acontecerá.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.conffonte