Como pôr um dispositivo RAID inactivo a funcionar novamente?

Para a sua pergunta de bónus:

mdadm --examine --scan >> /etc/mdadm/mdadm.conf

Descobri que tenho de adicionar o array manualmente em /etc/mdadm/mdadm.conf para fazer o Linux montá-lo na reinicialização. Caso contrário, obtenho exactamente o que tem aqui - dispositivos md_d1 que estão inactivos, etc.

O conf-file deve parecer-se como abaixo - ou seja, um ARRAY-linha para cada md-dispositivo. No meu caso, as novas matrizes estavam em falta neste ficheiro, mas se as tiver listadas, isto provavelmente não é uma solução para o seu problema.

# definitions of existing MD arrays
ARRAY /dev/md0 level=raid5 num-devices=3 UUID=f10f5f96:106599e0:a2f56e56:f5d3ad6d
ARRAY /dev/md1 level=raid1 num-devices=2 UUID=aa591bbe:bbbec94d:a2f56e56:f5d3ad6d

Adicione um array por md-dispositivo, e adicione-os após o comentário incluído acima, ou se não existir tal comentário, no final do ficheiro. Recebe os UUIDs fazendo sudo mdadm -E --scan:

$ sudo mdadm -E --scan
ARRAY /dev/md0 level=raid5 num-devices=3 UUID=f10f5f96:106599e0:a2f56e56:f5d3ad6d
ARRAY /dev/md1 level=raid1 num-devices=2 UUID=aa591bbe:bbbec94d:a2f56e56:f5d3ad6d

Como pode ver, pode copiar a saída do resultado do scan-resultado para o ficheiro.

Corro o ubuntu 10.04 LTS, e tanto quanto me lembro este comportamento difere da versão de servidor do Ubuntu, no entanto foi há tanto tempo que criei os meus dispositivos md no servidor que posso estar errado. Também pode ser que me tenha escapado alguma opção.

De qualquer modo, adicionar o array no ficheiro conf- parece fazer o truque. Fiz o raid 1 e o raid 5 acima durante anos, sem problemas.

Aviso: Antes de mais, deixem-me dizer que o que se segue (devido ao uso de “–força”) me parece arriscado, e se tiverem dados irrecuperáveis eu recomendaria fazer cópias das partições envolvidas antes de começarem a tentar qualquer uma das coisas abaixo. No entanto, isto funcionou para mim.

Tive o mesmo problema, com uma matriz a aparecer como inactiva, e nada do que eu fiz incluindo o “mdadm –examine –scan >/etc/mdadm.conf”, como sugerido por outros aqui, ajudou em nada.

No meu caso, quando tentou iniciar o array RAID-5 após uma substituição de drive, estava a dizer que estava sujo (via dmesg):

md/raid:md2: not clean -- starting background reconstruction
md/raid:md2: device sda4 operational as raid disk 0
md/raid:md2: device sdd4 operational as raid disk 3
md/raid:md2: device sdc4 operational as raid disk 2
md/raid:md2: device sde4 operational as raid disk 4
md/raid:md2: allocated 5334kB
md/raid:md2: cannot start dirty degraded array.

fazendo-o aparecer como inactivo em /proc/mdstat:

md2 : inactive sda4[0] sdd4[3] sdc4[2] sde4[5]
      3888504544 blocks super 1.2

Descobri que todos os dispositivos tinham os mesmos eventos, excepto a unidade que eu tinha substituído (/dev/sdb4):

[root@nfs1 sr]# mdadm -E /dev/sd*4 | grep Event
mdadm: No md superblock detected on /dev/sdb4.
         Events : 8448
         Events : 8448
         Events : 8448
         Events : 8448

Contudo, os detalhes da matriz mostraram que tinha 4 dos 5 dispositivos disponíveis:

[root@nfs1 sr]# mdadm --detail /dev/md2
/dev/md2:
[...]
   Raid Devices : 5
  Total Devices : 4
[...]
 Active Devices : 4
Working Devices : 4
[...]
    Number Major Minor RaidDevice State
       0 8 4 0 inactive dirty /dev/sda4
       2 8 36 2 inactive dirty /dev/sdc4
       3 8 52 3 inactive dirty /dev/sdd4
       5 8 68 4 inactive dirty /dev/sde4

(O acima é de memória na coluna “Estado”, não o consigo encontrar no meu buffer scroll-back).

Consegui resolver isto parando a matriz e depois remontando-a:

mdadm --stop /dev/md2
mdadm -A --force /dev/md2 /dev/sd[acde]4

Nesse momento o array estava em funcionamento, com 4 dos 5 dispositivos, e eu consegui adicionar o dispositivo de substituição e está a ser reconstruído. Consegui aceder ao sistema de ficheiros sem qualquer problema.

Tive problemas com o Ubuntu 10.04 onde um erro no FStab impediu o servidor de arrancar.

Eu executei este comando como mencionado nas soluções acima:

mdadm --examine --scan >> /etc/mdadm/mdadm.conf

Isto anexará os resultados de “mdadm –examine –scan” a “/etc/mdadm/mdadm.conf”

No meu caso, isto foi:

ARRAY /dev/md/0 metadata=1.2 UUID=2660925e:6d2c43a7:4b95519e:b6d110e7 name=localhost:0

Isto é um fakeraid 0. O meu comando em /etc/fstab para montagem automática é:

/dev/md0 /home/shared/BigDrive ext3 defaults,nobootwait,nofail 0 0

O importante aqui é que tem “nobootwait” e “nofail”. Nobootwait saltará qualquer mensagem de sistema que o impeça de arrancar. No meu caso, isto foi num servidor remoto, pelo que foi essencial.

Espero que isto ajude algumas pessoas.

Pode activar o seu dispositivo md com

mdadm -A /dev/md_d0

Suponho que algum script de arranque começa demasiado cedo, antes de um dos membros do RAID ser descoberto ou algum problema semelhante. Como uma solução rápida e suja, deverá poder adicionar esta linha ao /etc/rc.local :

mdadm -A /dev/md_d0 && mount /dev/md_d0

Edit : aparentemente o seu /etc/mdadm/mdadm.conf ainda contém o antigo nome da configuração. Edite este ficheiro e substitua as ocorrências de md0 por md_d0.

Tive um problema semelhante… o meu servidor não montaria md2 depois de eu ter cultivado as partições dos dispositivos associados. Ao ler este tópico descobri que o dispositivo RAID md2 tinha um novo UUID e a máquina estava a tentar usar o antigo.

Como sugerido… usando a saída ‘md2’ de

mdadm --examine --scan

Eu editei /etc/mdadm/mdadm.conf& e substituí a antiga UUID pela saída do comando acima e o meu problema desapareceu.

md_d0 : inactive sda4[0](S) parece errado para uma matriz RAID1. Parece sugerir que o array não tem dispositivos activos e um dispositivo sobresselente (indicado pelo (S), veria (F) ali para um dispositivo avariado e nada para um dispositivo OK/activo) - para um array RAID1 que não esteja a funcionar degradado deveria haver pelo menos dois dispositivos OK/activo (e para um array degradado, pelo menos um dispositivo OK/activo) e não se pode activar um array RAID1 sem dispositivos não activos não avariados (pois os sobresselentes não contêm uma cópia dos dados até que sejam activados quando outro drive falhar). Se eu estiver a ler bem esse /proc/mdstat output, não será possível activar o array no seu estado actual.

Tem alguma unidade física na máquina que não tenha rodado? ls /dev/sd* lista todas as unidades e partições que normalmente esperaria ver nessa máquina?

Quando se finge fazer algo com /dev/md[012346789}& vai para /dev/md{126,127...}./dev/md0 continua montado a /dev/md126 ou /dev/md127 tem de se fazer:

umount /dev/md127 ou umount /dev/md126.

Isto é temporário para lhe permitir executar comandos e algumas aplicações sem parar o seu sistema.

Uma forma simples de fazer funcionar a matriz, assumindo que não há nenhum problema de hardware e que se tem suficientes unidades/partições para iniciar a matriz é a seguinte:

md20 : inactive sdf1[2](S)
      732442488 blocks super 1.2

 sudo mdadm --manage /dev/md20 --run

Pode ser que por qualquer razão o array esteja bem, mas algo o tenha impedido de arrancar ou construir. No meu caso, isto aconteceu porque o mdadm não sabia que o nome original do array era md127 e todas as unidades foram desligadas para esse array. Ao reabastecer tive de montar manualmente (provavelmente um bug em que mdadm pensava que o array já estava activo por causa do nome do antigo array offline).