mdadm raid5 recupera falha de disco duplo - com um toque (ordem da unidade)

Em primeiro lugar, reconheço que cometi erros e que tenho um backup para a maioria, mas não todos os dados deste RAID. Ainda tenho esperança de recuperar o restante dos dados. Não tenho dinheiro para levar as unidades a uma empresa especialista em recuperação.

Erro nº 0, não tendo um backup 100%. Eu sei.

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

Eventos recentes

O RAID fica degradado após uma falha de duas unidades. Uma unidade [/ dev / sdc] realmente desapareceu, a outra [/ dev / sde] voltou a funcionar 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 unidades ativas [/ dev / sdb e / dev / sdd].

Erro nº 1, não usando cópias em dd das unidades para restaurar o RAID. Eu não tinha as unidades ou o tempo. Erro nº 2, não fazendo backup do superbloco e mdadm -Edas unidades restantes.

Tentativa de recuperação

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/sdcpor um sobressalente; esvaziar; unidade idêntica.

Eu removi o antigo /dev/sdc1do RAID

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

Erro nº 3, não fazer isso antes de substituir a unidade

Particionei o novo /dev/sdce o adicionei ao RAID.

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

Em seguida, começou a restaurar o RAID. ETA 300 minutos. Eu segui o processo /proc/mdstataté 2% e depois fui fazer outras coisas.

Verificando o resultado

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

Aqui é onde o problema realmente começa

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

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

No entanto, /dev/sde1agora foi marcado como sobressalente. Por isso, decidi recriar toda a matriz usando --assume-clean usando o que eu achava que era a ordem certa e com /dev/sdc1falta.

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 ao tentar montar. (Deveria ter sido EXT4).

Ordem do dispositivo

Em seguida, verifiquei um backup recente que tinha /proc/mdstate localizei a ordem da unidade.

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 havia sofrido uma perda de unidade há cerca de um ano e me recuperei ao substituir a unidade defeituosa por uma sobressalente. Isso pode ter mexido um pouco na ordem do dispositivo ... então não havia unidade [3], mas apenas [0], [1], [2] e [4].

Tentei encontrar a ordem das unidades com o script Permute_array: https://raid.wiki.kernel.org/index.php/Permute_array.pl, mas essa não encontrou a ordem correta.

Questões

Agora tenho duas perguntas principais:

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

   mdadm --create --assume-clean
   

   comandos (então eu não deveria ter sobrescrito os dados /dev/sd[bde]1. Estou certo de que, em teoria, o RAID pode ser restaurado [supondo por um momento que /dev/sde1seja bom] se eu apenas encontrar a ordem correta do dispositivo?

2. É importante que /dev/sde1seja fornecido 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]falta [1] /dev/sdd1[2] /dev/sde1[4]? Se eu conseguisse fazer isso funcionar, poderia iniciá-lo no modo degradado, adicionar a nova unidade /dev/sdc1e deixá-la ressincronizar novamente.

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

Para responder suas perguntas,

1. Pode ser restaurado?

   • A primeira coisa é a primeira - PARE, sente-se e pense um pouco. Sim, o algoritmo, o tamanho do bloco e a ordem do disco são vitais para que o sistema de arquivos que estava presente seja reinstalado adequadamente. Mas como você substituiu os superblocos, agora fica com tentativa e erro.
   • Segundo, existe alguma maneira de recuperar o layout de disco anterior? Eu sempre faço um mdadm --detail> backupfile apenas para manter esse layout de disco em algum lugar seguro. Verifique dmesg, / var / log para qualquer evidência de como os discos foram configurados no ataque.
   • Por fim, se você corresponder ao tamanho anterior do bloco e à ordem do disco, poderá ter danificado o superbloco ext4 - existem maneiras de verificar rapidamente outros superblocos (e há um programa bacana chamado TestDisk que procura por superblocos de sistemas de arquivos existentes e tenta procurá-los manualmente: http://www.cgsecurity.org/wiki/Main_Page )

2. Como o sdc é novo, eu continuaria tentando montar manualmente através da cláusula ausente e, sim, o sde deve estar na ordem correta para que seja montado no modo degradado. Depois de encontrar o layout correto - copie todos os dados da matriz e comece novamente, documentando o layout (para que você não se depare com esse problema novamente).

Boa sorte

Antes de fazer qualquer outra coisa, capture um 'mdadm --examine / dev / sdX1' para cada uma das unidades que estavam na sua matriz e um 'mdadm --detail / dev / md0' a partir disso, você poderá determinar o layout exato.

Eu só tinha que fazer isso sozinho para recuperar uma matriz Synology em uma pergunta separada:

Como recuperar uma matriz mdadm no Synology NAS com a unidade no estado "E"?

Edit: Desculpe, acabei de ver 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 pedido possível e, em seguida, ver se você pode montar e acessar o sistema de arquivos neles somente leitura.

Esta pergunta é antiga e tenho certeza que ninguém pode ajudá-lo agora, mas para outros que estão lendo:

o erro mais perigoso que você cometeu não foi o que você numerou, que deveria ser executado:

mdadm --create ...

nos discos originais, antes de estar preparado para saber o que fazer. Isso substituiu os metadados, para que você não tenha um registro da ordem da unidade, deslocamento dos dados, tamanho do pedaço, etc.

Para recuperar isso, você precisa substituí-los novamente pelos valores corretos. A maneira mais fácil de saber isso é examinar os metadados, mas você já os destruiu. A próxima maneira é 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 uma 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 conhece 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 de trabalho que você pode fsck ou montar e verificar (por exemplo, verifique a soma de verificação de um arquivo grande o suficiente para abranger todos os membros da invasão como um iso que você deveria ter armazenado com sua soma de verificação / pgp assinatura, ou descompacte -t ​​ou gunzip -ta arquivo grande)