☰

Recuperação de dados na partição raid5 + lvm reiserfs, após problemas de raid5

tag-icon • tag-icon linux lvm data-recovery reiserfs
Recuperação de dados na partição raid5 + lvm reiserfs, após problemas de raid5

Eu tenho um servidor com 3 discos rígidos sata. Cada um tem 2 partições: uma pequena faz parte de /dev/md0, um array raid1 (/boot), o restante faz parte de um array raid5 (/dev/md1), que é um volume físico lvm. Dentro dele estão 3 volumes lógicos (IIRC). Um deles é um reiserfs 3.6 fs contendo cerca de 100 gigas de dados.

Ontem este servidor travou. Ao ligar, a SMART me disse que uma das unidades estava morta. Ele estava realmente fazendo barulhos muito ruins. Então removi a unidade com falha e tentei reiniciar o sistema nos 2 discos restantes. O que falhou.

Com um live cd, iniciei e tentei reiniciar o array. Infelizmente, o mdadm recusou-se a fazê-lo, porque considerou que um dos 2 discos restantes também falhou.

Então, seguindo os conselhos encontrados emComo recuperar um array Linux md RAID5 com falha?que parecia que poderia se aplicar à minha situação, fiz algo que provavelmente foi simplesmente estúpido: corri

mdadm --create /dev/md1 --assume-clean -l5 -n3 -c64 /dev/sd[ab]2 missing

Agora, posso realmente iniciar esse array, mas as ferramentas lvm (vgscan, vgdisplay, pvck) não conseguem encontrar nada relacionado ao lvm no array e não consigo acessar meus dados. Acabei de limpar todos os metadados do lvm?

Minha sensação é que os dados reais ainda estão lá, sem danos (além dos metadados lvm). Existe uma chance de recuperar os dados? Como?

ATUALIZAR:

Seguindo o conselho de psusi (abaixo), tentei cada uma das seguintes maneiras de recriar o array:

mdadm --create /dev/md1 --assume-clean -l5 -n3 -c64 /dev/sda2 /dev/sdb2 missing
mdadm --create /dev/md1 --assume-clean -l5 -n3 -c64 /dev/sdb2 /dev/sda2 missing
mdadm --create /dev/md1 --assume-clean -l5 -n3 -c64 /dev/sda2 missing /dev/sdb2
mdadm --create /dev/md1 --assume-clean -l5 -n3 -c64 /dev/sdb2 missing /dev/sda2
mdadm --create /dev/md1 --assume-clean -l5 -n3 -c64 missing /dev/sda2 /dev/sdb2
mdadm --create /dev/md1 --assume-clean -l5 -n3 -c64 missing /dev/sdb2 /dev/sda2

mdadm --create /dev/md1 --assume-clean -l5 -n3 -c512 /dev/sda2 /dev/sdb2 missing
mdadm --create /dev/md1 --assume-clean -l5 -n3 -c512 /dev/sdb2 /dev/sda2 missing
mdadm --create /dev/md1 --assume-clean -l5 -n3 -c512 /dev/sda2 missing /dev/sdb2
mdadm --create /dev/md1 --assume-clean -l5 -n3 -c512 /dev/sdb2 missing /dev/sda2
mdadm --create /dev/md1 --assume-clean -l5 -n3 -c512 missing /dev/sda2 /dev/sdb2
mdadm --create /dev/md1 --assume-clean -l5 -n3 -c512 missing /dev/sdb2 /dev/sda2

Que são basicamente todos os pedidos possíveis, tanto com -c64 quanto -c512. Após cada teste, executei um vgscan. Nenhum encontrou nada. Talvez eu não deva usar o vgscan, mas alguma outra ferramenta?

ATUALIZAÇÃO 2:

Tentei reconectar o disco rígido com falha. E, milagre, parece funcionar de alguma forma. Pelo menos, o suficiente para examiná-lo:

root@debian:~# mdadm --examine /dev/sda2
/dev/sda2:
          Magic : a92b4efc
        Version : 0.90.00
           UUID : 1f5462ab:6945560d:019b01a5:914dd464
  Creation Time : Fri Oct 17 12:40:40 2008
     Raid Level : raid5
  Used Dev Size : 160015360 (152.60 GiB 163.86 GB)
     Array Size : 320030720 (305.21 GiB 327.71 GB)
   Raid Devices : 3
  Total Devices : 3
Preferred Minor : 1

    Update Time : Tue Apr 12 08:15:03 2011
          State : active
 Active Devices : 3
Working Devices : 3
 Failed Devices : 0
  Spare Devices : 0
       Checksum : 64d514fb - correct
         Events : 137

         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

Então, existe uma maneira de copiar esse superbloco para os outros 2 dispositivos, para que eu possa iniciar o array "corretamente"?

Responder1

Eu tenho uma configuração semelhante e recomendo ter um Linux completo na pequena partição de cada unidade enãoespelhe essas pequenas partições, mas faça com que elas sejam totalmente inicializáveis ​​separadamente.

Você pode fazer synca configuração excluindo alguns arquivos cruciais ( /etc/fstab, configuração do grub). Isso ocupa mais espaço do que apenas, /bootmas economiza muito tempo quando surgem problemas.

Responder2

Você provavelmente não montou as unidades na mesma ordem ou usando o mesmo tamanho de bloco de antes. Você precisa descobrir qual era a ordem anterior e usar a mesma ordem ao recriar o array. Em outras palavras, pode não ter sido o terceiro disco que morreu, mas sim o primeiro ou o segundo, ou você pode ter confundido sda e sdb.

Responder3

Como @psusi sugeriuo formato de metadados é o kye, ao que parece - agora "1.2" é o padrão, não "0.9". É uma pena dizer, mas isso pode levar à perda de dados, já que 1,2 usa deslocamento de 4 KiB:

1, 1.0, 1.1, 1.2 padrão Use o novo superbloco de formato da versão 1. Isso tem menos restrições. Ele pode ser facilmente movido entre hosts com endian diferentes e uma operação de recuperação pode ser verificada e reiniciada. As diferentes subversões armazenam o superbloco em diferentes locais do dispositivo, seja no final (para 1.0), no início (para 1.1) ou 4K desde o início (para 1.2).

Um conselho (infelizmente, tardio): nunca se apresse em recriar um array sem tentar com -B- build:

   -B, --build
          Build a legacy array without superblocks

Atualização.: acabou -Bse recusando a construir o RAID-5… :-/

informação relacionada