Linux - dmraid (ou mdadm) - Reconstruir RAID 10

Question

Há um tempo atrás eu tinha uma configuração de raid10 em cima de mim, e agora estou apenas começando a tentar salvar a matriz para que eu possa reconstruir e seguir em frente com a minha vida. Basicamente, uma unidade em cada subconjunto falhou, o que significa que (em teoria) posso recuperar. Se eu perdesse dois discos no mesmo subconjunto, a recuperação não seria possível.

Eu removi os dois discos defeituosos e adicionei dois novos drives ao sistema. Para a placa controladora de raid o sistema está usando uma promessa fasttrak 4310. Quando eu inicializei o sistema eu entrei na bios da placa controladora raid e notei que todas as 4 unidades foram encontradas, mas as duas novas (obviamente) não foram atribuídas à raid configuração. Infelizmente não há como remover as duas unidades antigas e adicionar as duas novas unidades a partir da configuração através da bios. Promise fornece um instalador WebPAM, mas antigo (6 anos) e não será instalado no CentOS 6.4.

Então eu fiz algumas escavações e me deparei com "dmraid". O dmraid parece promissor, já que estava retornando informações sobre minha configuração do raid, com base no que eu sei sobre ele:

root@service1 ~ # -> dmraid -s -s
ERROR: pdc: wrong # of devices in RAID set "pdc_fbdbhaai-0" [1/2] on /dev/sdb
ERROR: pdc: wrong # of devices in RAID set "pdc_fbdbhaai-1" [1/2] on /dev/sde
ERROR: pdc: wrong # of devices in RAID set "pdc_fbdbhaai-0" [1/2] on /dev/sdb
ERROR: pdc: wrong # of devices in RAID set "pdc_fbdbhaai-1" [1/2] on /dev/sde
*** Superset
name   : pdc_fbdbhaai
size   : 976642080
stride : 32
type   : raid10
status : ok
subsets: 2
devs   : 2
spares : 0
--> Subset
name   : pdc_fbdbhaai-0
size   : 976642080
stride : 32
type   : stripe
status : broken
subsets: 0
devs   : 1
spares : 0
--> Subset
name   : pdc_fbdbhaai-1
size   : 976642080
stride : 32
type   : stripe
status : broken
subsets: 0
devs   : 1
spares : 0

root@service1 ~ # -> dmraid -r
/dev/sde: pdc, "pdc_fbdbhaai-1", stripe, ok, 976642080 sectors, data@ 0
/dev/sdb: pdc, "pdc_fbdbhaai-0", stripe, ok, 976642080 sectors, data@ 0

A partir de agora, parece que tudo que preciso fazer é atualizar os metadados do RAID para desconsiderar os drives antigos e adicionar os novos drives. Então (espero) eu posso emitir um comando de reconstrução e, teoricamente, o ataque se salvará com as duas unidades restantes.

Eu li "man dmraid", mas queria ter certeza absoluta de que os comandos que eu emiti realizarão o que estou tentando fazer. Infelizmente, não consegui encontrar bons documentos on-line sobre como adicionar / remover unidades de metadados de invasão usando o dmraid.

Meu conjunto de comandos proposto será parecido com:

root@service1 ~ # -> dmraid --remove pdc_fbdbhaai-0 /dev/sda1
root@service1 ~ # -> dmraid --remove pdc_fbdbhaai-1 /dev/sda2

Com as unidades antigas removidas, é hora de adicionar novas:

root@service1 ~ # -> dmraid -R pdc_fbdbhaai-0 /dev/sdc
root@service1 ~ # -> dmraid -R pdc_fbdbhaai-1 /dev/sdd

Alguém com experiência em trabalhar com dmraid pode confirmar essas etapas? Ou devo seguir outra rota?

    

Answer 1

Caramba. Foi capaz de descobrir isso. Depois de mais algumas pesquisas, encontrei alguns posts que indicavam que o dmraid não era mais mantido ativamente, e usava mdadm . Então comecei a trabalhar com o mdadm e descobri os comandos para obter a reconstrução do raid e esperançosamente voltar a ficar on-line novamente. Aqui está o que eu fiz:

De acordo com o mdadm docs, a emissão de um comando assemble criará o volume lógico de duas unidades físicas, IF eles têm informações de superblocos, então vamos adicionar as duas unidades que não falharam:

$ -> mdadm --assemble /dev/md0 /dev/sdb /dev/sde
mdadm: /dev/md0 assembled from 2 drives - need all 4 to start it (use --run to insist).

Fácil, adicione as duas novas unidades ao volume lógico:

$ -> mdadm --add /dev/md0 /dev/sdc /dev/sdd
mdadm: cannot get array info for /dev/md0

Neste ponto, pesquisei o que esta mensagem indica. Havia uma infinidade de situações diferentes que podem causar a resposta dada, então eu refleti sobre o comando de montagem novamente. A chave para reexaminar o comando de montagem na segunda vez foi a mensagem dada; "use --run para insistir". Figurou, por que não vamos dar uma chance:

$ -> mdadm --run /dev/md0
mdadm: started /dev/md0

Ok, bom até agora, agora posso adicionar as duas novas unidades?

$ -> mdadm --add /dev/md0 /dev/sdc
mdadm: added /dev/sdc

$ -> mdadm --add /dev/md0 /dev/sdd
mdadm: added /dev/sdd

Whoa legal! Vamos verificar o status:

$ -> cat /prod/mdstat
Personalities : [raid10]
md0 : active raid10 sdd[4](S) sdc[5] sdb[1] sde[2]
  976772992 blocks 64K chunks 2 near-copies [4/2] [_UU_]
  [>....................]  recovery =  2.2% (10762688/488386496) finish=131.5min speed=60498K/sec

unused devices: <none>

Claro que sim! De acordo com o status, o ataque está sendo reconstruído a partir das duas unidades que não travaram e queimaram.

- EDITAR

Para garantir que a configuração do ataque persista entre a reinicialização / o desligamento, tive que fazer o seguinte:

$ -> mdadm --detail --scan >> /etc/mdadm.conf