mdadm - Acidentalmente executou “mdadm --create” em um raid-1 existente. O superbloco está corrompido e não consigo recuperar dados. Eu bork meus dados?

Question

Eu tenho /dev/sdb1 e /dev/sdc2 que foram configurados anteriormente em um RAID-1 com mdadm , mas depois reinstalei e perdi a configuração antiga. Fora de idiotice, eu corri

sudo mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sdb1 /dev/sdc1

em uma tentativa de reconfigurar o RAID. Depois que eu deixar as unidades sincronizarem (oops?), Agora nenhuma das /dev/md0 , /dev/sdb1 ou /dev/sdc2 será montada. Por /dev/md0 , ele reclama de um número mágico ruim no super bloco. Para o /dev/sd{b,c}1 , ele reclama da falta de inodes.

Em suma, a pergunta é a seguinte: Acabei de inserir todos os meus dados ou é possível recuperar o array ainda?

O seguinte é a saída de dumpe2fs para essas partições:

brent@codpiece:~$ sudo dumpe2fs /dev/md0 
dumpe2fs 1.42 (29-Nov-2011)
dumpe2fs: Bad magic number in super-block while trying to open /dev/md0
Couldn't find valid filesystem superblock.
brent@codpiece:~$ sudo dumpe2fs /dev/sdb1 
dumpe2fs 1.42 (29-Nov-2011)
Filesystem volume name:   <none>
Last mounted on:          /var/media
Filesystem UUID:          1462d79f-8a10-4590-8d63-3fcc105b601d
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash 
Default mount options:    (none)
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              61054976
Block count:              244189984
Reserved block count:     12209499
Free blocks:              59069396
Free inodes:              60960671
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      965
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512
Flex block group size:    16
Filesystem created:       Wed Feb 10 21:04:42 2010
Last mount time:          Fri May 10 20:25:34 2013
Last write time:          Sun May 12 14:41:02 2013
Mount count:              189
Maximum mount count:      38
Last checked:             Wed Feb 10 21:04:42 2010
Check interval:           15552000 (6 months)
Next check after:         Mon Aug  9 22:04:42 2010
Lifetime writes:          250 GB
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:      7cd5ce46-b823-4453-aa66-00ddaff69952
Journal backup:           inode blocks
dumpe2fs: A block group is missing an inode table while reading journal inode

Editar:

Parece que o @ hauke-laging estava correto ao criar uma versão 1.2 de metadados RAID-1 sobre o que costumava ser uma invasão de metadados 1.0. Eu tenho reran mdadm --create para a versão correta, mas agora meu sistema de arquivos está corrompido. Preciso mexer com a tabela de partições ou posso simplesmente executar fsck /dev/md0 ?

A seguir, a nova saída de fsck e dumpe2fs :

brent@codpiece:~$ sudo fsck /dev/md0 
fsck from util-linux 2.20.1
e2fsck 1.42 (29-Nov-2011)
The filesystem size (according to the superblock) is 244189984 blocks
The physical size of the device is 244189952 blocks
Either the superblock or the partition table is likely to be corrupt!

brent@codpiece:~$ sudo dumpe2fs /dev/md0
Filesystem volume name:   <none>
Last mounted on:          <not available>
Filesystem UUID:          1462d79f-8a10-4590-8d63-3fcc105b601d
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash 
Default mount options:    (none)
Filesystem state:         not clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              61054976
Block count:              244189984
Reserved block count:     12209499
Free blocks:              240306893
Free inodes:              61054965
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      965
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512
Flex block group size:    16
Filesystem created:       Wed Feb 10 21:04:42 2010
Last mount time:          n/a
Last write time:          Mon May 13 10:38:58 2013
Mount count:              0
Maximum mount count:      38
Last checked:             Wed Feb 10 21:04:42 2010
Check interval:           15552000 (6 months)
Next check after:         Mon Aug  9 22:04:42 2010
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:      7cd5ce46-b823-4453-aa66-00ddaff69952
Journal backup:           inode blocks
Journal features:         journal_incompat_revoke
Journal size:             128M
Journal length:           32768
Journal sequence:         0x00215ad3
Journal start:            0


Group 0: (Blocks 0-32767) [ITABLE_ZEROED]
  Checksum 0x4453, unused inodes 0
  Primary superblock at 0, Group descriptors at 1-59
  Reserved GDT blocks at 60-1024
  Block bitmap at 1025 (+1025), Inode bitmap at 1041 (+1041)
  Inode table at 1057-1568 (+1057)
  23513 free blocks, 8181 free inodes, 2 directories
  Free blocks: 12576-12591, 12864-12879, <...>
  Free inodes: 
Group 1: (Blocks 32768-65535) [ITABLE_ZEROED]
  Checksum 0x348a, unused inodes 0
  Backup superblock at 32768, Group descriptors at 32769-32827
  Reserved GDT blocks at 32828-33792
  Block bitmap at 1026 (bg #0 + 1026), Inode bitmap at 1042 (bg #0 + 1042)
  Inode table at 1569-2080 (bg #0 + 1569)
  31743 free blocks, 8192 free inodes, 0 directories
  Free blocks: 43232-43239, 43264-43271, <...>
  Free inodes: 
Group 2: (Blocks 65536-98303) [ITABLE_ZEROED]
  Checksum 0x2056, unused inodes 0
  Block bitmap at 1027 (bg #0 + 1027), Inode bitmap at 1043 (bg #0 + 1043)
  Inode table at 2081-2592 (bg #0 + 2081)
  32768 free blocks, 8192 free inodes, 0 directories
  Free blocks: 66417-66432, 66445-66456, 66891, <...>
  Free inodes: 23921-24576
Group 3: (Blocks 98304-131071) [ITABLE_ZEROED]
  Checksum 0x4254, unused inodes 0
  Backup superblock at 98304, Group descriptors at 98305-98363
  Reserved GDT blocks at 98364-99328
  Block bitmap at 1028 (bg #0 + 1028), Inode bitmap at 1044 (bg #0 + 1044)
  Inode table at 2593-3104 (bg #0 + 2593)
  31743 free blocks, 8192 free inodes, 0 directories
  Free blocks: 99334-99339, 99438-99443, 99456-99459, <...>
  Free inodes: 24585-32768
Group 4: (Blocks 131072-163839) [ITABLE_ZEROED]
  Checksum 0x6a00, unused inodes 0
  Block bitmap at 1029 (bg #0 + 1029), Inode bitmap at 1045 (bg #0 + 1045)
  Inode table at 3105-3616 (bg #0 + 3105)
  32768 free blocks, 8192 free inodes, 0 directories
  Free blocks: 131074-131075, 131124-131129, <...>
  Free inodes: 32769-40960
Group 5: (Blocks 163840-196607) [ITABLE_ZEROED]
  Checksum 0x37e0, unused inodes 0
  Backup superblock at 163840, Group descriptors at 163841-163899
  Reserved GDT blocks at 163900-164864
  Block bitmap at 1030 (bg #0 + 1030), Inode bitmap at 1046 (bg #0 + 1046)
  Inode table at 3617-4128 (bg #0 + 3617)
  31743 free blocks, 8192 free inodes, 0 directories
  Free blocks: 164968-164970, 164979, <...>
  Free inodes: 40961-49152
Group 6: (Blocks 196608-229375) [ITABLE_ZEROED]
  <...>

    

Answer 1

Dê uma olhada nesta questão . Presumo que seja familiar ao seu problema.

Recriar e até sincronizar um RAID-1 não deve destruir dados. Obviamente, o dispositivo MD inicia em outro deslocamento agora. Assim, quando o mount procura por um superbloco, há dados. Isso pode ter acontecido de pelo menos duas maneiras:

1. Você (ou melhor: a configuração padrão) criou o novo array com um formato de superbloco diferente (consulte --metadata in man mdadm ). Assim, o superbloco está em outra posição (ou tem um tamanho diferente) agora. Por acaso você sabe qual era o formato antigo de metadados?
2. O deslocamento foi alterado mesmo com o mesmo formato devido a um deslocamento padrão diferente. Veja mdadm --examine /dev/sdb1 (adicione a saída à sua pergunta).

Você deve procurar por um superbloco na primeira área dos discos (/ dev / sdb1). Talvez isso possa ser feito com parted ou ferramentas semelhantes. Você pode ter que excluir as respectivas partições para isso (não há problema, pois você pode facilmente fazer backup e restaurar a tabela de partições).

Ou você cria dispositivos de loop / dispositivos DM com deslocamentos crescentes (não necessariamente em todo o disco, alguns MiB são suficientes) e tenta dumpe2fs -h neles. Se você quiser fazer isso, mas não sabe como eu posso fornecer algum código shell para isso.

O pior caso seria que o novo superbloco de MD tenha sobrescrito o superbloco do sistema de arquivos. Nesse caso, você pode procurar por cópias de superblocos (veja a saída de mke2fs ). Um mke2fs executado em um dispositivo fictício do mesmo tamanho pode informar as posições das cópias do superbloco.

Editar 1:

Agora li e entendi sua dumpe2fs output. Seu antigo RAID-1 teve seu superbloco no final (0.9 ou 1.0). Agora você provavelmente tem 1.2 para que uma parte do seu sistema de arquivos seja sobrescrita. Não posso avaliar o tamanho do dano. Este é um caso para e2fsck . Mas primeiro você deve redefinir o RAID para o seu tipo antigo. Ajudaria a conhecer a versão antiga.

Você pode reduzir o risco colocando os dispositivos DM em todo o /dev/sdb1 e /dev/sdc1 , criar instantâneos para eles (com dmsetup directly e criar o novo array sobre os instantâneos. Dessa forma, as partes relevantes de seus discos serão A partir da saída dumpe2fs , sabemos que o dispositivo MD deve ter tamanho de 1000202174464. Isso deve ser verificado imediatamente após a criação de um teste