OK, parece que agora temos acesso ao ataque. Pelo menos os primeiros arquivos verificados pareciam bons. Então, aqui está o que fizemos:
O artigo de recuperação do RAID no wiki do kernel.org sugere duas possíveis soluções para o nosso problema:
-
usando
--assemble --force(também mencionado por derobert)
O artigo diz:[...] If the event count differs by less than 50, then the information on the drive is probably still ok. [...] If the event count closely matches but not exactly, use "mdadm --assemble --force /dev/mdX " to force mdadm to assemble the array [...]. If the event count of a drive is way off [...] that drive [...] shouldn't be included in the assembly.
No nosso caso, a unidade
sdeteve uma diferença de eventos de 9. Portanto, havia uma boa chance de que--forcefuncionasse. No entanto, depois de executarmos o comando--add, a contagem de eventos caiu para 0 e a unidade foi marcada como sobressalente.Então é melhor desistirmos de usar
--force. -
recriar a matriz
Essa solução é explicitamente marcada como perigosa porque você pode perder dados se fizer algo errado. No entanto, esta parecia ser a única opção que tínhamos.A idéia é criar um novo ataque nos dispositivos raid existentes (que está sobrescrevendo os superblocos do dispositivo) com a mesma configuração do antigo raid e informar explicitamente ao mdadm que o ataque já existia e deve ser considerado limpo.
Como a diferença na contagem de eventos foi de apenas 9 e o único problema foi que perdemos o superbloco de
sde. Houve boas chances de que escrever novos superblocos nos permitisse acessar nossos dados ... e funcionou: -)
Nossa solução
Observação: essa solução foi especialmente voltada para nosso problema e pode não funcionar em sua configuração. Você deve tomar essas notas para ter uma ideia de como as coisas podem ser feitas. Mas você precisa pesquisar o que há de melhor no seu caso.
Backup
Nós já perdemos um superbloco. Desta vez, nós salvamos o primeiro e último gigabyte de cada dispositivo de ataque ( sd[acdefghij] ) usando o dd antes de trabalhar no ataque. Fizemos isso para cada dispositivo de ataque:
# save the first gigabyte of sda
dd if=/dev/sda of=bak_sda_start bs=4096 count=262144
# determine the size of the device
fdisk -l /dev/sda
# In this case the size was 4000787030016 byte.
# To get the last gigabyte we need to skip everything except the last gigabyte.
# So we need to skip: 4000787030016 byte - 1073741824 byte = 3999713288000 byte
# Since we read blocks auf 4096 byte we need to skip 3999713288000/4096=976492502 blocks.
dd if=/dev/sda of=bak_sda_end bs=4096 skip=976492502
Reunir informações
Ao recriar o ataque, é importante usar a mesma confusão que o antigo ataque. Isso é especialmente importante se você quiser recriar a matriz em outra máquina usando uma versão diferente do mdadm. Nesse caso, os valores padrão do mdadm podem ser diferentes e podem criar superquadros que não se encaixam no raid existente (veja o artigo do wiki).
No nosso caso, usamos a mesma máquina (e, portanto, a mesma versão do mdadm) para recriar a matriz. No entanto, o array foi criado por uma ferramenta de terceiros em primeiro lugar. Portanto, não queríamos confiar nos valores padrão aqui e precisávamos coletar algumas informações sobre o ataque existente.
Da saída de mdadm --examine /dev/sd[acdefghij] obtemos as seguintes informações sobre o raid (Nota: sdb era o ssd que contém o sistema operacional e não fazia parte do raid):
Raid Level : raid5
Raid Devices : 9
Used Dev Size : 7814034432 (3726.02 GiB 4000.79 GB)
Data Offset : 2048 sectors
Super Offset : 8 sectors
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 0
O Used Dev Size é denominado em blocos de 512 bytes. Você pode verificar isso: 7814034432*512/1000000000 ~= 4000.79
Mas o mdadm requer o tamanho no Kibibytes: 7814034432*512/1024 = 3907017216
Importante é o Device Role . No novo ataque, cada dispositivo deve ter o mesmo papel de antes. No nosso caso:
device role
------ ----
sda 0
sdc 1
sdd 2
sde 3
sdf 4
sdg 5
sdh 6
sdi spare
sdj 8
Nota: as letras de unidade (e, portanto, a ordem) podem mudar após a reinicialização!
Também precisamos do layout e do tamanho do bloco na próxima etapa.
Recriar o ataque
Agora podemos usar as informações da última etapa para recriar a matriz:
mdadm --create --assume-clean --level=5 --raid-devices=9 --size=3907017216 \
--chunk=512 --layout=left-symmetric /dev/md127 /dev/sda /dev/sdc /dev/sdd \
/dev/sde /dev/sdf /dev/sdg /dev/sdh missing /dev/sdj
É importante passar os dispositivos na ordem correta!
Além disso, não adicionamos sdi , pois a contagem de eventos foi muito baixa. Então, definimos o sétimo slot raid como missing . Assim, o raid5 contém 8 de 9 dispositivos e será montado no modo degradado. E como não tem um dispositivo reserva, nenhuma reconstrução será iniciada automaticamente.
Em seguida, usamos --examine para verificar se os novos superblocos se encaixam em nossos superblocos antigos. E ele fez :-) Conseguimos montar o sistema de arquivos e ler os dados. O próximo passo é fazer backup dos dados e, em seguida, adicionar de volta sdi e iniciar a reconstrução.