Recuperação Superblock MDADM

6

Após um ciclo de energia, descobri que meu RAID 5 Array não está mais funcionando. Eu tentei vários métodos para remontar a matriz, mas nada funcionou até agora. Eu acredito que eu preciso recriar os superblocos e UUIDs de alguma forma , mas estava relutante em entrar em algo para não perder um monte de dados. Obrigado pela leitura.

cat /etc/mdadm/mdadm.conf :

DEVICE partitions
ARRAY /dev/md0 level=raid5 num-devices=4 metadata=0.90 UUID=fd522a0f:2de72d76:f2afdfe9:5e3c9df1
MAILADDR root

O que é normal. Deve ter 4x2000GB drives (sda, sdc, sde, sdd).

cat /proc/mdstat :

Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] 
md0 : inactive sdd[1](S)
  1953514496 blocks

unused devices: <none>

Isso é um problema. Ela mostra apenas uma unidade na matriz e também está inativa. O array deve ter sda, sdc e sde lá também. Quando eu faço um mdadm --examine /dev/sdd tudo parece bem. Nas outras unidades, examine diz sem superbloco RAID em / dev / sdX .

mdadm --examine --scan :

ARRAY /dev/md0 level=raid5 num-devices=4 metadata=0.90 UUID=fd522a0f:2de72d76:f2afdfe9:5e3c9df1

Não há ajuda.

mdadm --assemble --scan -v :

mdadm: looking for devices for /dev/md0
mdadm: no RAID superblock on /dev/sde
mdadm: /dev/sde has wrong uuid.
mdadm: cannot open device /dev/sdd: Device or resource busy
mdadm: /dev/sdd has wrong uuid.
mdadm: no RAID superblock on /dev/sdc
mdadm: /dev/sdc has wrong uuid.
mdadm: cannot open device /dev/sdb5: Device or resource busy
mdadm: /dev/sdb5 has wrong uuid.
mdadm: no RAID superblock on /dev/sdb2
mdadm: /dev/sdb2 has wrong uuid.
mdadm: cannot open device /dev/sdb1: Device or resource busy
mdadm: /dev/sdb1 has wrong uuid.
mdadm: cannot open device /dev/sdb: Device or resource busy
mdadm: /dev/sdb has wrong uuid.
mdadm: no RAID superblock on /dev/sda
mdadm: /dev/sda has wrong uuid.

A partir disso, parece que não tenho UUIDs nem Superblocks para sda, sdc e sde.

sudo fdisk -l

Disk /dev/sda: 2000.4 GB, 2000397852160 bytes
255 heads, 63 sectors/track, 243201 cylinders, total 3907027055 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: 0x00000000

Disk /dev/sda doesn't contain a valid partition table

Disk /dev/sdb: 250.1 GB, 250058268160 bytes
255 heads, 63 sectors/track, 30401 cylinders, total 488395055 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: 0x353cf669

Device Boot      Start         End      Blocks   Id  System
/dev/sdb1              63   476327249   238163593+  83  Linux
/dev/sdb2       476327250   488392064     6032407+   5  Extended
/dev/sdb5       476327313   488392064     6032376   82  Linux swap / Solaris

Disk /dev/sdc: 2000.4 GB, 2000397852160 bytes
255 heads, 63 sectors/track, 243201 cylinders, total 3907027055 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: 0x00000000

Disk /dev/sdc doesn't contain a valid partition table

Disk /dev/sdd: 2000.4 GB, 2000398934016 bytes
255 heads, 63 sectors/track, 243201 cylinders, total 3907029168 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: 0x00000000

Disk /dev/sdd doesn't contain a valid partition table

Disk /dev/sde: 2000.4 GB, 2000397852160 bytes
255 heads, 63 sectors/track, 243201 cylinders, total 3907027055 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: 0x00000000

Disk /dev/sde doesn't contain a valid partition table

Então, a partir disso, parece que nenhum dos meus discos RAID tem uma tabela de partição ou UUID. A coisa mais próxima que encontrei do meu problema foi este tópico , que sugeriu a execução de mdadm --create /dev/md0 -v -l 5 -n 4 /dev/sda /dev/sdc /dev/sde /dev/sdd e verificando um sistema de arquivos válido com fsck -fn /dev/md0 . No entanto, o primeiro comando cuspiu mdadm: no raid-devices specified. Eu tentei novamente o comando usando sda1, sdc1, etc, mas depois recebo isto:

mdadm: layout defaults to left-symmetric
mdadm: chunk size defaults to 512K
mdadm: layout defaults to left-symmetric
mdadm: layout defaults to left-symmetric
mdadm: super1.x cannot open /dev/sda1: No such file or directory
mdadm: ddf: Cannot open /dev/sda1: No such file or directory
mdadm: Cannot open /dev/sda1: No such file or directory
mdadm: device /dev/sda1 not suitable for any style of array

Se eu criar e deixar o sda1 como uma variável "ausente" no comando, ele diz o mesmo para o sdc1.

Tenho certeza de que estou tornando isso mais complicado do que precisa ser. Alguém com experiência pode me ajudar? Obrigado pelo seu tempo de antecedência.

* editar * Quando eu corro dumpe2fs /dev/sda i get:

dumpe2fs 1.41.14 (22-Dec-2010)
Filesystem volume name:   <none>
Last mounted on:          <not available>
Filesystem UUID:          bbe6fb91-d37c-414a-8c2b-c76a30b9b5c5
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype     needs_recovery sparse_super large_file
Filesystem flags:         signed_directory_hash 
Default mount options:    (none)
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              366288896
Block count:              1465135872
Reserved block count:     73256793
Free blocks:              568552005
Free inodes:              366066972
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      674
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512
Filesystem created:       Wed Oct 28 12:23:09 2009
Last mount time:          Tue Oct 18 13:59:36 2011
Last write time:          Tue Oct 18 13:59:36 2011
Mount count:              17
Maximum mount count:      26
Last checked:             Fri Oct 14 17:04:16 2011
Check interval:           15552000 (6 months)
Next check after:         Wed Apr 11 17:04:16 2012
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:           256
Required extra isize:     28
Desired extra isize:      28
Journal inode:            8
Default directory hash:   half_md4
Directory Hash Seed:      17e784d8-012e-4a29-9bbd-c312de282588
Journal backup:           inode blocks
Journal superblock magic number invalid!

Então, as coisas ainda estão lá. Ainda pesquisando ...

    
por Teque5 19.10.2011 / 06:12

3 respostas

4

Gosta! Que salmoura. vamos ver se conseguimos te organizar. Começando com uma recapitulação dos seus discos e tabelas de partições:

sda - no partition table
sdb - sdb1 [Linux] sdb2 [Linux extended] sdb5 [swap]
sdc - no partition table
sdd - no partition table
sde - no partition table
  1. Nenhum destes está marcado como fd autodetect do raid do Linux , que é o padrão
  2. Você não está usando partições para organizar seu espaço em disco [0]
  3. Parece que você tem todo o disco formatado para ext2 / 3 e estão usando todo o disco como parte do raidset

O último ponto é onde eu acho que você foi desfeito. Os initscripts provavelmente achavam que você estava precisando de um fsck, a sanidade verificou os volumes e eliminou o superbloco MD no processo. dumpe2fs não deve retornar nada para volumes do conjunto RAID .

Tome meu RAID por exemplo:

root@mark21:/tmp/etc/udev# fdisk -l /dev/sda

Disk /dev/sda: 640.1 GB, 640135028736 bytes
255 heads, 63 sectors/track, 77825 cylinders, total 1250263728 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: 0x0000ffc4

Device Boot      Start         End      Blocks   Id  System
/dev/sda1            2048  1240233983   620115968   fd  Linux raid autodetect

root@mark21:/tmp/etc/udev# dumpe2fs /dev/sda1
dumpe2fs 1.41.14 (22-Dec-2010)
dumpe2fs: Bad magic number in super-block while trying to open /dev/sda
Couldn't find valid filesystem superblock.

O fato de você conseguir recriar o conjunto de RAIDs é extremamente sortudo, mas isso não altera as falhas fundamentais da sua implantação. Isso acontecerá novamente .

O que eu recomendaria é:

  1. Fazer backup de tudo nesse conjunto de invasores
  2. Destrua o array e apague o superbloco md de cada dispositivo (man mdadm)
  3. Zero esses discos: dd if=/dev/zero of=/dev/sdX bs=1M count=100
  4. Crie partições em sda, sdc, sdd e & amp; sdf que abrangem 99% do disco [0]
  5. Marque essas partições como type fd wiki linux-raid
  6. nunca formata essas partições com qualquer tipo de sistema de arquivos
  7. Crie um novo RAID 5: mdadm --criar / dev / md0 -v -f -l 5 -n 4 / dev / sda1 / dev / sdc1 / dev / sdd1 / dev / sde1
  8. Atualize o novo UUID em /etc/mdadm.conf
  9. Viver feliz para sempre

Eu presumo da sua descrição que o sdb é o disco do seu sistema, e tudo bem. Apenas certifique-se de não incluir isso acidentalmente na sua criação do conjunto de raid. Depois disso, você deve estar no caminho certo e nunca mais encontrará esse problema.

[0] Eu encontrei uma falha muito desagradável uma vez em discos SATA que tinham muitos blocos ruins. Depois de usar a ferramenta do fornecedor para reconstituir o disco. Meu conjunto de discos uma vez idêntico era agora único, o disco defeituoso agora tinha alguns blocos a menos do que antes do início do formato de baixo nível, o que naturalmente arruinou minha tabela de partições e impediu que o disco fosse re-ligado ao conjunto RAID MD.

Os discos rígidos geralmente têm uma "lista livre" de blocos de backup usados apenas por uma ocasião. Minha teoria é que essa lista deve ter sido esgotada, e como isso não era um disco corporativo, em vez de falhar e permitir a oportunidade de enviá-la para recuperação de dados, ela decidiu truncar meus dados e redimensionar a totalidade disco em.

Portanto, eu nunca mais uso o disco inteiro ao criar um conjunto RAID e, em vez disso, uso de 95 a 99% do espaço livre disponível ao criar uma partição que normalmente ocuparia todo o disco. Isso também lhe dá alguma flexibilidade adicional ao substituir membros com falha. Por exemplo, nem todos os discos de 250 GB têm a mesma quantidade de blocos livres, portanto, se você ultrapassar o máximo por uma margem confortável, poderá usar quase qualquer marca de disco para substituir um membro com falha.

    
por ppetraki 29.11.2011 / 14:26
1

Eu tive o mesmo problema antes, e não documentei isso (e foi há um tempo atrás).

Eu me lembro de algo sobre como usar e2fsck -b <superblockSector> /dev/sdX e tentar setores de superblocos de backup

você também pode dar uma olhada em TestDisk

    
por Thermionix 19.10.2011 / 09:00
1

Já faz um tempo desde o seu post, mas vou escrever isso:

"mdadm: não é possível abrir o dispositivo / dev / sdb1: dispositivo ou recurso ocupado"

é bom verificar

cat / proc / mdstat

Eu acho que sua unidade está ligada a algum ataque ex. / dev / md126

Se sim, pare de invadir

mdadm --stop / dev / md125

e, em seguida, tente remontar você raid / dev / md0

mdadm --assemble --verbose --expêndios de atualização / dev / md0 / dev / sda3 / dev / sdb3 / dev / sdc3 / dev / sdd3

MAS: Questão mais importante:

NÃO USE O RAID 5 COM DISCO SUPERIOR A 1,5 TB !!!

Taxa de erro de bits irrecuperável

Esta é a taxa na qual uma unidade não poderá recuperar dados após a aplicação de códigos de verificação de redundância cíclica (CRC) e várias tentativas. A taxa UBE (Erro de bit irrecuperável) é normalmente especificada em 1 bit em 10 ^ 15 para unidades de classe empresarial (SCSI, FC, SAS) e 1 bit em 10 ^ 14 para unidades de classe de desktop (IDE / ATA / PATA, SATA) . (então cada ~ 1,7 TB)

Portanto, se um dos drives falhar, há ~ 55% de chance de que NÃO reconstrua (para UBE 10 ^ -14) Boa sorte ...

mais aqui: link

    
por sirkubax 18.06.2012 / 12:24