¿Cómo hacer que un dispositivo RAID inactivo vuelva a funcionar?

Para su pregunta de bonificación:

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

He descubierto que tengo que añadir el array manualmente en /etc/mdadm/mdadm.conf para que Linux lo monte al reiniciar. De lo contrario, obtengo exactamente lo que tienes aquí - md_d1-dispositivos que están inactivos, etc.

El archivo conf debería ser como el de abajo - es decir, una línea ARRAY para cada dispositivo md. En mi caso, las nuevas matrices no aparecían en este archivo, pero si usted las tiene listadas, probablemente esto no solucione su 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

Añade un array por cada md-device, y añádelos después del comentario incluido arriba, o si no existe tal comentario, al final del archivo. Los UUIDs se obtienen haciendo 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 puedes ver, puedes copiar la salida del resultado del escaneo en el archivo.

Corro ubuntu desktop 10.04 LTS, y por lo que recuerdo este comportamiento difiere de la versión del servidor de Ubuntu, sin embargo fue hace tanto tiempo que creé mis md-devices en el servidor que puedo estar equivocado. También puede ser que se me haya pasado alguna opción.

De todos modos, añadir el array en el archivo conf parece hacer el truco. He ejecutado el anterior raid 1 y raid 5 durante años sin problemas.

Advertencia: En primer lugar permítanme decir que lo siguiente (debido al uso de “–force”) me parece arriesgado, y si tienes datos irrecuperables te recomendaría hacer copias de las particiones implicadas antes de empezar a intentar cualquiera de las cosas que se indican a continuación. Sin embargo, esto me funcionó.

Tuve el mismo problema, con un array que aparecía como inactivo, y nada de lo que hice, incluyendo el “mdadm –examine –scan >/etc/mdadm.conf”, como sugirieron otros aquí, ayudó en absoluto.

En mi caso, cuando intentaba arrancar el array RAID-5 después de un cambio de disco, decía que estaba sucio (a través de 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.

Causando que apareciera como inactivo en /proc/mdstat:

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

Sí comprobé que todos los dispositivos tenían los mismos eventos en ellos, excepto la unidad que había sustituido (/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

Sin embargo, los detalles del array mostraban que tenía 4 de los 5 dispositivos disponibles:

[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

(Lo anterior es de memoria en la columna de “Estado”, no lo encuentro en mi buffer de retroceso).

Pude resolverlo deteniendo el array y volviéndolo a montar:

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

En ese momento el array estaba levantado, funcionando con 4 de los 5 dispositivos, y pude añadir el dispositivo de reemplazo y se está reconstruyendo. Puedo acceder al sistema de archivos sin ningún problema.

Estaba teniendo problemas con Ubuntu 10.04 donde un error en FStab impedía el arranque del servidor.

Ejecuté este comando como se menciona en las soluciones anteriores:

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

Esto añadirá los resultados de “mdadm –examine –scan” a “/etc/mdadm/mdadm.conf”

En mi caso, esto fue:

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

Esto es un fakeraid 0. Mi comando en /etc/fstab para montar automáticamente es:

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

Lo importante aquí es que tienes “nobootwait” y “nofail”. Nobootwait omitirá cualquier mensaje del sistema que le impida arrancar. En mi caso, esto fue en un servidor remoto por lo que fue esencial.

Espero que esto ayude a algunos.

Puede activar su dispositivo md con

mdadm -A /dev/md_d0

Supongo que algún script de arranque se inicia demasiado pronto, antes de que uno de los miembros del RAID fuera descubierto o algún problema similar. Como una solución rápida y sucia, debería poder añadir esta línea a /etc/rc.local :

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

Edite : aparentemente su /etc/mdadm/mdadm.conf todavía contiene el antiguo nombre de configuración. Edite este archivo y sustituya las apariciones de md0 por md_d0.

Tuve un problema similar… mi servidor no montaba md2 después de haber hecho crecer las particiones de los dispositivos asociados. Al leer este hilo descubrí que el dispositivo RAID md2 tenía un nuevo UUID y la máquina intentaba utilizar el antiguo.

Como se sugirió… usando la salida de ‘md2’ de

mdadm --examine --scan

edité /etc/mdadm/mdadm.conf y reemplacé la vieja línea UUID con la salida del comando anterior y mi problema desapareció.

md_d0 : inactive sda4[0](S) parece incorrecto para una matriz RAID1. Parece sugerir que el array no tiene dispositivos activos y un dispositivo de repuesto (indicado por la (S), veríais la (F) allí para un dispositivo fallado y nada para un dispositivo OK/activo) - para un array RAID1 que no esté funcionando degradado debería haber al menos dos dispositivos OK/activos (y para un array degradado, al menos un dispositivo OK/activo) y no podéis activar un array RAID1 sin dispositivos de repuesto no fallados (ya que los repuestos no contienen una copia de los datos hasta que se activan cuando otra unidad falla). Si estoy leyendo bien esa salida /proc/mdstat, no podrás activar el array en su estado actual.

¿Tiene alguna unidad física en la máquina que haya fallado al girar? ¿Lista ls /dev/sd* todas las unidades y particiones que normalmente esperarías ver en esa máquina?

Cuando pretendes hacer algo con /dev/md[012346789} se va a /dev/md{126,127...}./dev/md0 sigue montado en /dev/md126 o /dev/md127 tienes que:

umount /dev/md127 o umount /dev/md126.

Esto es temporal para permitirte ejecutar comandos y algunas aplicaciones sin detener el sistema.

Una forma sencilla de conseguir que el array se ejecute asumiendo que no hay ningún problema de hardware y que tienes suficientes unidades/particiones para arrancar el array es la siguiente:

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

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

Puede ser que por alguna razón el array esté bien pero algo impidió que se iniciara o construyera. En mi caso fue porque mdadm no sabía que el nombre original del array era md127 y todas las unidades estaban desconectadas para ese array. Al volver a conectar tuve que ensamblar manualmente (probablemente un error en el que mdadm pensó que el array ya estaba activo debido al antiguo nombre de array desconectado).