Recuperação RAID de Software Linux

Question

Estou vendo uma discrepância entre a saída de mdadm --detail e mdadm --examine, e não entendo o motivo.

Esta saída

mdadm --detail /dev/md2
/dev/md2:
        Version : 0.90
  Creation Time : Wed Mar 14 18:20:52 2012
     Raid Level : raid10
     Array Size : 3662760640 (3493.08 GiB 3750.67 GB)
  Used Dev Size : 1465104256 (1397.23 GiB 1500.27 GB)
   Raid Devices : 5
  Total Devices : 5
Preferred Minor : 2
    Persistence : Superblock is persistent

Parece contradizer isso. (o mesmo para todos os discos da matriz)

mdadm --examine /dev/sdc2
/dev/sdc2:
          Magic : a92b4efc
        Version : 0.90.00
           UUID : 1f54d708:60227dd6:163c2a05:89fa2e07 (local to host)
  Creation Time : Wed Mar 14 18:20:52 2012
     Raid Level : raid10
  Used Dev Size : 1465104320 (1397.23 GiB 1500.27 GB)
     Array Size : 2930208640 (2794.46 GiB 3000.53 GB)
   Raid Devices : 5
  Total Devices : 5
Preferred Minor : 2

O array foi criado assim.

mdadm -v --create  /dev/md2 \
  --level=raid10 --layout=o2 --raid-devices=5 \
  --chunk=64 --metadata=0.90 \
 /dev/sdg2 /dev/sdf2 /dev/sde2 /dev/sdd2 /dev/sdc2 

Cada uma das cinco unidades individuais tem partições como esta.

Disk /dev/sdc: 1500.3 GB, 1500301910016 bytes
255 heads, 63 sectors/track, 182401 cylinders, total 2930277168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00057754

   Device Boot      Start         End      Blocks   Id  System
/dev/sdc1            2048       34815       16384   83  Linux
/dev/sdc2           34816  2930243583  1465104384   fd  Linux raid autodetect

História de fundo

Portanto, o controlador SATA falhou em uma caixa para a qual eu ofereço suporte. A falha foi uma unidade feia e tão individual caiu fora da matriz um pouco de cada vez. Embora existam backups, não são realmente feitos com a frequência que realmente precisamos. Existem alguns dados que estou tentando recuperar, se puder.

Consegui hardware adicional e consegui acessar as unidades novamente. As unidades parecem estar bem, e eu posso colocar a matriz e o sistema de arquivos ativos e montados (usando o modo somente leitura). Eu consigo acessar alguns dados no sistema de arquivos e copiei isso, mas estou vendo muitos erros quando tento copiar os dados mais recentes.

Quando estou tentando acessar os dados mais recentes, estou recebendo erros como o abaixo, o que me faz pensar que a discrepância no tamanho da matriz pode ser o problema.

Mar 14 18:26:04 server kernel: [351588.196299] dm-7: rw=0, want=6619839616, limit=6442450944
Mar 14 18:26:04 server kernel: [351588.196309] attempt to access beyond end of device
Mar 14 18:26:04 server kernel: [351588.196313] dm-7: rw=0, want=6619839616, limit=6442450944
Mar 14 18:26:04 server kernel: [351588.199260] attempt to access beyond end of device
Mar 14 18:26:04 server kernel: [351588.199264] dm-7: rw=0, want=20647626304, limit=6442450944
Mar 14 18:26:04 server kernel: [351588.202446] attempt to access beyond end of device
Mar 14 18:26:04 server kernel: [351588.202450] dm-7: rw=0, want=19973212288, limit=6442450944
Mar 14 18:26:04 server kernel: [351588.205516] attempt to access beyond end of device
Mar 14 18:26:04 server kernel: [351588.205520] dm-7: rw=0, want=8009695096, limit=6442450944

    

Answer 1

Tem certeza da sua linha de comando para criar o array? Meu palpite é que era um array "padrão" de 4 drives raid10 com um drive hot spare, o que explicaria o resultado de / dev / sdc2

Você pode nos dizer o resultado de:

cat /proc/mdstat
cat /etc/mdadm.conf
mdadm --examine /dev/sdx2 ( each drive )

Com isso, você pode adivinhar qual disco era o hot spare e, assim, poderá reconstruir o array adequadamente. Naturalmente, como afirmado por 3dinfluence, você deve duplicar os dados antes de tentar reconfigurar o array.

Editar: também não é provavelmente um desperdício de tempo para executar: smartctl -a /dev/sdx em cada unidade (verifique no final da saída se os erros foram relatados) e, em seguida, smartcl -t long /dev/sdx e 3 ou 4 horas um smartctl -a novamente para verificar se os 5 discos estão realmente bem. Se um disco estiver relatando erros, talvez ele tenha sido detectado como defeituoso pelo mdadm e, portanto, o mdadm tenha ligado a unidade sobressalente (sempre um palpite)

Editar 2: se vgs reportar: vgdisplay mostra Alloc PE / Tamanho 3.00 TiB, PE Livre / Tamanho 421.08 Isto significa que o seu PV cresceu misteriosamente de 421G .. Eu suporto o meu caso: o crescimento "misterioso" é uma configuração errada da sua matriz. O tamanho real da sua matriz é 3T. Você não remontou corretamente, então está corrompido. Para remontá-lo corretamente, você precisa recuperar a configuração original e qual das unidades era a unidade sobressalente. Boa sorte.

    

Answer 2

Se você pode clonar as unidades com dd, então eu faria isso. Mantenha seus drives originais tão inalterados quanto possível.

Então este é um tiro total da coisa do quadril, mas é o que eu tentaria se estivesse nessa situação. Com as unidades clonadas no sistema, eu apagaria todos os metadados RAID usando.
mdadm --zero-superblock /dev/sdx#
em cada uma das unidades envolvidas.

Em seguida, use o comando para recriar o array.
mdadm -v --create /dev/md2 \
--level=raid10 --layout=o2 --raid-devices=5 \
--chunk=64 --metadata=0.90 --assume-clean \
/dev/sdg2 /dev/sdf2 /dev/sde2 /dev/sdd2 /dev/sdc2

Isso deve eliminar todos os problemas do nível de ataque. De lá, você pode tentar remontar os sistemas de arquivos e ver o que resta. E se isto não funcionar, volte a clonar os seus discos e tente outra coisa:)