mdadm raid5 recupera falha de disco duplo - com uma torção (ordem dos discos)

Question

Deixe-me reconhecer primeiro que cometi erros e que tenho um backup para a maioria mas não todos dos dados deste RAID. Ainda tenho esperança de recuperar o resto dos dados. Eu não tenho o tipo de dinheiro para levar as unidades para uma empresa especializada em recuperação.

Erro # 0, não tendo 100% de backup. Eu sei.

Eu tenho um sistema mdadm RAID5 de 4x3TB. Drives / dev / sd [b-e], todos com uma partição /dev/sd[b-e]1 . Estou ciente de que o RAID5 em unidades muito grandes é arriscado, mas mesmo assim o fiz.

Eventos recentes

O RAID é degradado após uma falha de duas unidades. Uma unidade [/ dev / sdc] está realmente perdida, a outra [/ dev / sde] retornou após um ciclo de energia, mas não foi automaticamente adicionada novamente ao RAID. Então fiquei com um RAID de 4 dispositivos com apenas 2 drives ativos [/ dev / sdb e / dev / sdd].

Erro # 1, não usando cópias dd das unidades para restaurar o RAID. Eu não tinha os discos nem o tempo. Erro # 2, não fazendo um backup do superbloco e mdadm -E das unidades restantes.

Tentativa de recuperação

Eu remontei o RAID no modo degradado com

mdadm --assemble --force /dev/md0, using /dev/sd[bde]1.

Eu poderia acessar meus dados. Eu substituí /dev/sdc por um sobressalente; esvaziar; unidade idêntica.

Eu removi o antigo /dev/sdc1 do RAID

mdadm --fail /dev/md0 /dev/sdc1

Erro # 3, não fazendo isso antes substituindo a unidade

Eu então particionei o novo /dev/sdc e o adicionei ao RAID.

mdadm --add /dev/md0 /dev/sdc1

Em seguida, começou a restaurar o RAID. ETA 300 min. Eu segui o processo via /proc/mdstat para 2% e depois fui fazer outras coisas.

Verificando o resultado

Várias horas (mas menos de 300 minutos) depois, verifiquei o processo. Ele parou devido a um erro de leitura em /dev/sde1 .

Aqui é onde o problema realmente começa

Em seguida, removi /dev/sde1 do RAID e o adicionei novamente. Não me lembro por que fiz isso; já era tarde.

mdadm --manage /dev/md0 --remove /dev/sde1
mdadm --manage /dev/md0 --add /dev/sde1

No entanto, /dev/sde1 foi marcado como sobressalente. Então, decidi recriar toda a matriz usando --assume-clean usando o que achei ser a ordem correta e com /dev/sdc1 ausente.

mdadm --create /dev/md0 --assume-clean -l5 -n4 /dev/sdb1 missing /dev/sdd1 /dev/sde1

Isso funcionou, mas o sistema de arquivos não foi reconhecido durante a tentativa de montagem. (Deveria ter sido EXT4).

Ordem do dispositivo

Em seguida, verifiquei um backup recente de /proc/mdstat e localizei a ordem dos discos.

md0 : active raid5 sdb1[0] sde1[4] sdd1[2] sdc1[1]
      8790402048 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/4] [UUUU]

Lembrei-me então que esse RAID sofreu uma perda de unidade há cerca de um ano e se recuperou substituindo o disco defeituoso por um de reposição. Isso pode ter embaralhado um pouco a ordem dos dispositivos ... então não havia drive [3] mas apenas [0], [1], [2] e [4].

Eu tentei encontrar a ordem das unidades com o script Permute_array: link mas isso não aconteceu encontre a ordem certa.

Perguntas

Agora tenho duas perguntas principais:

1. Eu estraguei todos os superblocos nas unidades, mas só dei:

   mdadm --create --assume-clean
   

   comandos (então eu não deveria ter sobrescrito os dados em /dev/sd[bde]1 . Eu estou certo que em teoria o RAID pode ser restaurado [assumindo por um momento que /dev/sde1 está ok] se Acabei de encontrar a ordem certa para o dispositivo?

2. É importante que /dev/sde1 receba o número do dispositivo [4] no RAID? Quando eu crio com

   mdadm --create /dev/md0 --assume-clean -l5 -n4 \
     /dev/sdb1 missing /dev/sdd1 /dev/sde1
   

   é atribuído o número [3]. Gostaria de saber se isso é relevante para o cálculo dos blocos de paridade. Se isso for importante, como posso recriar a matriz com /dev/sdb1[0] missing [1] /dev/sdd1[2] /dev/sde1[4] ? Se eu pudesse fazê-lo funcionar, eu poderia iniciá-lo no modo degradado e adicionar a nova unidade /dev/sdc1 e permitir que ela fosse novamente sincronizada.

Tudo bem se você gostaria de me indicar que isso pode não ter sido o melhor curso de ação, mas você perceberá que percebi isso. Seria ótimo se alguém tivesse alguma sugestão.

    

Answer 1

Para responder às suas perguntas,

1. Pode ser restaurado?

   • A primeira coisa é a primeira - PARE, sente-se e pense um pouco. Sim, o algoritmo, o tamanho do fragmento e a ordem do disco são vitais para a obtenção do sistema de arquivos presente, para a montagem adequada. Mas desde que você substituiu os superblocos, agora você fica com tentativa e erro.
   • Em segundo lugar, há alguma maneira de recuperar o layout de disco anterior? Eu sempre faço um mdadm - detalhe > backupfile apenas para manter esse layout de disco em algum lugar seguro. Verifique o dmesg, / var / log para qualquer evidência de como os discos foram configurados no ataque.
   • Por último, se você combinar o tamanho do bloco anterior e a ordem do disco, você pode ter danificado o superbloco ext4 - existem maneiras de procurar por outros superblocos (e há um programa bacana chamado TestDisk que procura por superblocos de sistemas de arquivos existentes e tenta para pesquisá-los manualmente: link )

2. Como o sdc é novo, continuaria a tentar montar manualmente através da cláusula ausente, e sim, o sde deve estar na ordem correta para ser montado no modo degradado. Depois de encontrar o layout correto - copie todos os dados do array e comece de novo, documentando o layout (para que você não volte a este problema).

Boa sorte

    

Answer 2

Antes de fazer QUALQUER OUTRA coisa, capture um 'mdadm --examine / dev / sdX1' para cada uma das unidades que estavam em seu array, e um 'mdadm --detail/dev/md0' disso, você deve estar capaz de determinar o layout exato.

Eu só tive que fazer isso sozinho para recuperar um array Synology em uma pergunta separada:

Como recuperar um array mdadm no Synology NAS com drive no estado "E"?

Edit: Desculpe, só vi que você disse que perdeu os superblocos em todas as unidades.

Seus comandos posteriores parecem corretos. A opção mais simples pode ser executar as criações com cada ordenação possível e, em seguida, verificar se você pode montar e acessar o sistema de arquivos nelas somente leitura.

    

Answer 3

Essa pergunta é antiga e tenho certeza de que ninguém pode ajudá-lo agora, mas para outras pessoas que leem:

o erro mais perigoso que você cometeu não é aquele que você numerou, que foi executado:

mdadm --create ...

nos discos originais, antes de você estar preparado sabendo o que fazer. Isso substituiu os metadados, portanto, você não tem registro de ordem de unidade, desvio de dados, tamanho de bloco, etc.

Para recuperar isso, você precisa sobrescrevê-los novamente com os valores corretos. A maneira mais fácil de saber isso é olhar para os metadados, mas você já destruiu isso. O próximo caminho é adivinhar. Adivinhe as diferentes combinações de um comando como este, com valores diferentes para qualquer uma das opções, exceto o que você sabe (4 dispositivos, nível 5) e também a ordem de disco diferente:

mdadm --create /dev/md0 --assume-clean --metadata=1.2 --raid-devices=4 --level=5 --layout=... --chunk=512 --data-offset=128M /dev/sdb1 missing /dev/sdd1 /dev/sde1

Mas como você NÃO sabe o resultado correto, novamente, você não deve executá-lo nos discos antigos, destruindo-os ainda mais, cometendo o mesmo erro fatal. Em vez disso, use uma sobreposição; por exemplo, este procedimento deve funcionar para manter os originais seguros.

Depois de encontrar alguns argumentos que produzem uma matriz funcional que você pode fsck ou montar e verificar (por exemplo, verificar a soma de verificação de um arquivo grande o suficiente para abranger todos os membros da raid como uma iso que você deveria ter armazenado assinatura checksum / pgp, ou unzip -t ou gunzip -ta grande arquivo)