Recuperando a matriz RAID5 após zerar o superbloco errado

1

Eu tenho uma matriz raid5 em 4 discos, sda1, sdb1, sdd1 e sde1. O sdd1 foi removido, mas é um drive saudável. Enquanto tentava adicioná-lo novamente, acidentalmente zerei o superbloco de sdb1.

Os dados do sdb1 são consistentes com sda1 e sde1, faltando apenas o superbloco.

É possível recuperar o superbloco desse dispositivo e remontar o array (degradado) sem perder nenhum dado?

Abaixo está a saída de 'mdadm -E / dev / sd {a, d, e} 1'.

Estou lendo a saída corretamente em que sde1 é o dispositivo 0, sdd1 é o dispositivo 2 e sda1 é o dispositivo 3? Então isso significaria que sdb1 era o Dispositivo 1. Eu poderia recriar a matriz com o seguinte comando sem perda de dados:

$ sudo mdadm --create /dev/md0 --assume-clean --level=5 --raid-devices=4 /dev/sde1 /dev/sdb1 missing /dev/sda1

/dev/sda1:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x1
     Array UUID : 81a36846:cf4f0489:219e2546:b1f5b90e
           Name : cowbell:0
  Creation Time : Sun Sep 25 20:24:46 2011
     Raid Level : raid5
   Raid Devices : 4

 Avail Dev Size : 3907025920 (1863.02 GiB 2000.40 GB)
     Array Size : 5860538880 (5589.05 GiB 6001.19 GB)
    Data Offset : 1024 sectors
   Super Offset : 8 sectors
          State : clean
    Device UUID : a0abbc72:f8bb1e2b:e8f81f5c:ed62a979

Internal Bitmap : 8 sectors from superblock
    Update Time : Tue Jul 23 18:05:09 2013
       Checksum : 9f46a56 - correct
         Events : 717820

         Layout : left-symmetric
     Chunk Size : 512K

   Device Role : Active device 3
   Array State : AA.A ('A' == active, '.' == missing)
/dev/sdd1:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x1
     Array UUID : 81a36846:cf4f0489:219e2546:b1f5b90e
           Name : cowbell:0
  Creation Time : Sun Sep 25 20:24:46 2011
     Raid Level : raid5
   Raid Devices : 4

 Avail Dev Size : 3907027053 (1863.02 GiB 2000.40 GB)
     Array Size : 5860538880 (5589.05 GiB 6001.19 GB)
  Used Dev Size : 3907025920 (1863.02 GiB 2000.40 GB)
    Data Offset : 2048 sectors
   Super Offset : 8 sectors
          State : active
    Device UUID : 79f5632d:46d5c083:a1c0130c:b83b0654

Internal Bitmap : 8 sectors from superblock
    Update Time : Tue Jul 23 17:42:02 2013
       Checksum : a78d6f5b - correct
         Events : 717392

         Layout : left-symmetric
     Chunk Size : 512K

   Device Role : Active device 2
   Array State : AAAA ('A' == active, '.' == missing)
/dev/sde1:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x1
     Array UUID : 81a36846:cf4f0489:219e2546:b1f5b90e
           Name : cowbell:0
  Creation Time : Sun Sep 25 20:24:46 2011
     Raid Level : raid5
   Raid Devices : 4

 Avail Dev Size : 3907027053 (1863.02 GiB 2000.40 GB)
     Array Size : 5860538880 (5589.05 GiB 6001.19 GB)
  Used Dev Size : 3907025920 (1863.02 GiB 2000.40 GB)
    Data Offset : 2048 sectors
   Super Offset : 8 sectors
          State : clean
    Device UUID : 6abd9160:c8ae382c:e6c73d01:37ac057b

Internal Bitmap : 8 sectors from superblock
    Update Time : Tue Jul 23 18:05:09 2013
       Checksum : 9f5d8fa6 - correct
         Events : 717820

         Layout : left-symmetric
     Chunk Size : 512K

   Device Role : Active device 0
   Array State : AA.A ('A' == active, '.' == missing)
    
por Justin Miller 24.07.2013 / 17:49

2 respostas

1

Além dos backups, você também pode considerar apenas fazer cópias completas de dd dos discos antes de tentar qualquer recuperação.

Dito isso, parece que você está no caminho certo para a recuperação sem perda de dados. Você está interpretando os números dos dispositivos corretamente. Esse comando parece com o que você precisa.

Veja minha resposta aqui - essas coisas são surpreendentemente resistentes à perda de dados, e a destruição do superbloco não é prejudicial à capacidade de reconstruir a matriz na mesma geometria (consulte o teste 4 nessa resposta).

    
por 24.07.2013 / 22:00
0

Eu tentaria verificar se os discos físicos subjacentes são sincronizados antes de continuar recriando o dispositivo MD com a suposição de que está limpo. Você pode fazer isso com

mdadm -E /dev/sd[abc]1 | grep Event
Events : 0.53120
Events : 0.53108
Events : 0.53120

A saída mostra que sda e sdc são sincronizados enquanto o sdc está atrasado.

    
por 25.07.2013 / 11:49