Q: Raid1 não inicializa após o novo disco rígido instalado

Question

No meu servidor Ubuntu, tive uma falha no disco. O novo disco rígido foi instalado rapidamente pelos técnicos do hoster.

Depois, segui as instruções da página para integrar o novo disco ao ataque. Começou semelhante com a resposta dada a esta pergunta ( Como posso copiar rapidamente um esquema de partição GPT de um disco rígido para outro? ) Copie a tabela de partições do disco antigo para o novo:

sgdisk -R /dev/sdY /dev/sdX
sgdisk -G /dev/sdY

Tenho certeza de que não misturei o antigo e o novo disco. Então eu tentei integrar o novo disco no ataque com

mdadm /dev/md0 -a /dev/sda1

Esse comando falhou. Eu reiniciei para poder chegar na nova partição em sda. Mas é aí que acabou. O sistema não inicializa mais. Eu tenho acesso a um sistema de resgate, mas não tenho a menor idéia do que preciso fazer para colocar meu sistema em funcionamento.

Parece que meu sistema de arquivos pode estar corrompido?

fsck /dev/sdb
fsck from util-linux 2.25.2
e2fsck 1.42.12 (29-Aug-2014)
ext2fs_open2: Bad magic number in super-block
fsck.ext2: Superblock invalid, trying backup blocks...
fsck.ext2: Bad magic number in super-block while trying to open /dev/sdb

Existe alguma maneira de verificar se o sistema de arquivos está realmente destruído? Eu estava correndo kvm com vários vms lá.

    

Answer 1

Eu descobri o que aconteceu. Qualquer uma das duas coisas: 1) Eu estraguei a tabela de partições ou 2) algo mais atrapalhou a tabela de partições e depois de uma reinicialização não havia NADA a ser feita.

Aqui está o que eu deveria ter feito quando um disco do raid1 morreu:

• verifique o status do raid com cat /proc/mdstat e verifique se o drive está realmente morto
• mdadm examine dá mais informações sobre o status do ataque
• enquanto o sistema ainda está em execução faça backups de material que não tenha sido feito backup corretamente (por exemplo, antes de remover o disco rígido e forçar uma reinicialização em um sistema já estressado)
• faça um backup da tabela de partições antes de fazer qualquer outra coisa (prefira usar gdisk interativamente e listar partições antes de fazer backup delas para garantir que o dispositivo / disco rígido correto seja usado)
• use mdadm para remover as partições do disco rígido com falha do raid com --fail cleanly
• em vez de copiar a tabela de partições de uma unidade para outra, use o backup para carregá-la
• Uma reinicialização pode ser necessária para configurar adequadamente as partições (certifique-se de que todas as coisas tenham sido submetidas a backup antes)
• Use mdadm para adicionar as novas partições de volta aos dispositivos de ataque f.e. %código%
• Se por algum motivo você esqueceu de executar o mdadm --add /dev/md1 /dev/sda2 você pode ser capaz de recriar os dispositivos raid com isto: --fail (estou razoavelmente certo de que não foi isso que destruiu os sistemas de arquivos no disco rígido restante

Se eu tivesse seguido o acima, nunca teria entrado na posição acima. Uma vez lá, não encontrei uma saída. Então, o que me garantiu que os dados foram eliminados?

• Em um sistema de resgate, não consegui montar nenhum dos dispositivos com mdadm --create /dev/md1 --assume-clean --level=1 --verbose --raid-devices=2 missing /dev/sdb2 . Fiquei recebendo erros que o sistema de arquivos não foi reconhecido e os números mágicos não encontrados
• O Testdisk encontrou o número errado de partições ao tentar recriar a tabela de partições
• mount -t ext4 /dev/md1 /mnt/mountpoint ao me dar locais para um monte de números mágicos não ajudou nada porque nenhum era válido, também essas posições são "fixas" dentro da partição em certas posições, então se a tabela de partições estiver errada, estas posições não se alinham mais
• dumpe2fs basicamente me disse a mesma coisa e uma partição foi sacrificada para tentar reparar o sistema de arquivos, mas cada inode gerou um erro
• Eu fiz uma varredura remota com o R-Studio (software comercial da R-Tools, a varredura e recuperação de arquivos de até 256kb é gratuita) e, enquanto no início parecia que havia arquivos recuperáveis, usei-o para baixar poucos jpgs e pngs e nenhum continha dados de imagem válidos Eu tentei uma variedade de coisas para descobrir o que deu errado com o sistema de arquivos, mas tudo voltou a uma tabela de partição desordenada e a uma falha na recuperação com o testdisk.

Então lições aprendidas: 1) manter um backup da tabela de partições em algum lugar seguro (também não no servidor) 2) quando as coisas acontecem - fazer backups primeiro 3) ter uma estratégia de backup antes que aconteça o material