¿Cómo recuperar una matriz dañada de Linux md RAID5?

Hace algún tiempo tenía un sistema RAID5 en casa. Uno de los 4 discos falló, pero después de quitarlo y volver a colocarlo parecía estar bien, así que comencé una resincronización. Cuando terminó me di cuenta, para mi horror, que 3 de 4 discos fallaron. Sin embargo, no creo que sea posible. Hay múltiples particiones en los discos, cada parte de una matriz RAID diferente.

• md0 es una matriz RAID1 compuesta por sda1, sdb1, sdc1 y sdd1.
• md1 es una matriz RAID5 compuesta por sda2, sdb2, sdc2 y sdd2.
• md2 es una matriz RAID0 compuesta por sda3, sdb3, sdc3 y sdd3.

md0 y md2 informan que todos los discos están activos mientras que md1 informa que 3 fallaron (sdb2, sdc2, sdd2) Entiendo que cuando los discos duros fallan, todas las particiones deben perderse, no solo las del medio.

En ese momento apagué la computadora y desconecté las unidades. Desde entonces estaba usando esa computadora con un disco nuevo más pequeño.

¿Hay alguna esperanza de recuperar los datos? ¿Puedo convencer de alguna manera a mdadm de que mis discos funcionan? El único disco que realmente puede tener un problema es sdc, pero ese también es informado por las otras matrices.

Actualizar

Finalmente tuve la oportunidad de conectar los discos viejos y arrancar esta máquina desde SystemRescueCd. Todo lo anterior fue escrito de memoria. Ahora tengo algunos datos duros. Aquí está la salida demdadm --examine /dev/sd*2

/dev/sda2:
          Magic : a92b4efc
        Version : 0.90.00
           UUID : 53eb7711:5b290125:db4a62ac:7770c5ea
  Creation Time : Sun May 30 21:48:55 2010
     Raid Level : raid5
  Used Dev Size : 625064960 (596.11 GiB 640.07 GB)
     Array Size : 1875194880 (1788.33 GiB 1920.20 GB)
   Raid Devices : 4
  Total Devices : 4
Preferred Minor : 1

    Update Time : Mon Aug 23 11:40:48 2010
          State : clean
 Active Devices : 3
Working Devices : 4
 Failed Devices : 1
  Spare Devices : 1
       Checksum : 68b48835 - correct
         Events : 53204

         Layout : left-symmetric
     Chunk Size : 64K

      Number   Major   Minor   RaidDevice State
this     0       8        2        0      active sync   /dev/sda2

   0     0       8        2        0      active sync   /dev/sda2
   1     1       8       18        1      active sync   /dev/sdb2
   2     2       8       34        2      active sync   /dev/sdc2
   3     3       0        0        3      faulty removed
   4     4       8       50        4      spare   /dev/sdd2
/dev/sdb2:
          Magic : a92b4efc
        Version : 0.90.00
           UUID : 53eb7711:5b290125:db4a62ac:7770c5ea
  Creation Time : Sun May 30 21:48:55 2010
     Raid Level : raid5
  Used Dev Size : 625064960 (596.11 GiB 640.07 GB)
     Array Size : 1875194880 (1788.33 GiB 1920.20 GB)
   Raid Devices : 4
  Total Devices : 4
Preferred Minor : 1

    Update Time : Mon Aug 23 11:44:54 2010
          State : clean
 Active Devices : 2
Working Devices : 3
 Failed Devices : 1
  Spare Devices : 1
       Checksum : 68b4894a - correct
         Events : 53205

         Layout : left-symmetric
     Chunk Size : 64K

      Number   Major   Minor   RaidDevice State
this     1       8       18        1      active sync   /dev/sdb2

   0     0       0        0        0      removed
   1     1       8       18        1      active sync   /dev/sdb2
   2     2       8       34        2      active sync   /dev/sdc2
   3     3       0        0        3      faulty removed
   4     4       8       50        4      spare   /dev/sdd2
/dev/sdc2:
          Magic : a92b4efc
        Version : 0.90.00
           UUID : 53eb7711:5b290125:db4a62ac:7770c5ea
  Creation Time : Sun May 30 21:48:55 2010
     Raid Level : raid5
  Used Dev Size : 625064960 (596.11 GiB 640.07 GB)
     Array Size : 1875194880 (1788.33 GiB 1920.20 GB)
   Raid Devices : 4
  Total Devices : 4
Preferred Minor : 1

    Update Time : Mon Aug 23 11:44:54 2010
          State : clean
 Active Devices : 1
Working Devices : 2
 Failed Devices : 2
  Spare Devices : 1
       Checksum : 68b48975 - correct
         Events : 53210

         Layout : left-symmetric
     Chunk Size : 64K

      Number   Major   Minor   RaidDevice State
this     2       8       34        2      active sync   /dev/sdc2

   0     0       0        0        0      removed
   1     1       0        0        1      faulty removed
   2     2       8       34        2      active sync   /dev/sdc2
   3     3       0        0        3      faulty removed
   4     4       8       50        4      spare   /dev/sdd2
/dev/sdd2:
          Magic : a92b4efc
        Version : 0.90.00
           UUID : 53eb7711:5b290125:db4a62ac:7770c5ea
  Creation Time : Sun May 30 21:48:55 2010
     Raid Level : raid5
  Used Dev Size : 625064960 (596.11 GiB 640.07 GB)
     Array Size : 1875194880 (1788.33 GiB 1920.20 GB)
   Raid Devices : 4
  Total Devices : 4
Preferred Minor : 1

    Update Time : Mon Aug 23 11:44:54 2010
          State : clean
 Active Devices : 1
Working Devices : 2
 Failed Devices : 2
  Spare Devices : 1
       Checksum : 68b48983 - correct
         Events : 53210

         Layout : left-symmetric
     Chunk Size : 64K

      Number   Major   Minor   RaidDevice State
this     4       8       50        4      spare   /dev/sdd2

   0     0       0        0        0      removed
   1     1       0        0        1      faulty removed
   2     2       8       34        2      active sync   /dev/sdc2
   3     3       0        0        3      faulty removed
   4     4       8       50        4      spare   /dev/sdd2

Parece que las cosas han cambiado desde el último arranque. Si estoy leyendo esto correctamente, sda2, sdb2 y sdc2 funcionan y contienen datos sincronizados y sdd2 es de repuesto. Recuerdo claramente haber visto 3 discos fallidos, pero esta es una buena noticia. Sin embargo, la matriz todavía no funciona:

Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] 
md125 : inactive sda2[0](S) sdb2[1](S) sdc2[2](S)
      1875194880 blocks

md126 : inactive sdd2[4](S)
      625064960 blocks

md127 : active raid1 sda1[0] sdd1[3] sdc1[2] sdb1[1]
      64128 blocks [4/4] [UUUU]

unused devices: <none>

md0 parece ser renombrado a md127. md125 y md126 son muy extraños. Deben ser una matriz, no dos. Eso solía llamarse md1. md2 se ha ido por completo, pero ese fue mi intercambio, así que no me importa.

Puedo entender los diferentes nombres y realmente no importa. Pero, ¿por qué no se puede leer una matriz con 3 discos de "sincronización activa"? ¿Y qué pasa con sdd2 estar en una matriz separada?

Actualizar

Intenté lo siguiente después de hacer una copia de seguridad de los superbloques:

root@sysresccd /root % mdadm --stop /dev/md125
mdadm: stopped /dev/md125
root@sysresccd /root % mdadm --stop /dev/md126
mdadm: stopped /dev/md126

Hasta aquí todo bien. Como sdd2 es de repuesto, no quiero agregarlo todavía.

root@sysresccd /root % mdadm --assemble /dev/md1 /dev/sd{a,b,c}2 missing 
mdadm: cannot open device missing: No such file or directory
mdadm: missing has no superblock - assembly aborted

Aparentemente no puedo hacer eso.

root@sysresccd /root % mdadm --assemble /dev/md1 /dev/sd{a,b,c}2        
mdadm: /dev/md1 assembled from 1 drive - not enough to start the array.
root@sysresccd /root % cat /proc/mdstat 
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] 
md1 : inactive sdc2[2](S) sdb2[1](S) sda2[0](S)
      1875194880 blocks

md127 : active raid1 sda1[0] sdd1[3] sdc1[2] sdb1[1]
      64128 blocks [4/4] [UUUU]

unused devices: <none>

Eso tampoco funcionó. Probemos con todos los discos.

mdadm --stop /dev/md1
mdadm: stopped /dev/md1
root@sysresccd /root % mdadm --assemble /dev/md1 /dev/sd{a,b,c,d}2
mdadm: /dev/md1 assembled from 1 drive and 1 spare - not enough to start the array.
root@sysresccd /root % cat /proc/mdstat                           
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] 
md1 : inactive sdc2[2](S) sdd2[4](S) sdb2[1](S) sda2[0](S)
      2500259840 blocks

md127 : active raid1 sda1[0] sdd1[3] sdc1[2] sdb1[1]
      64128 blocks [4/4] [UUUU]

unused devices: <none>

Sin suerte. Según esta respuesta , planeo probar:

mdadm --create /dev/md1 --assume-clean --metadata=0.90 --bitmap=/root/bitmapfile --level=5 --raid-devices=4 /dev/sd{a,b,c}2 missing
mdadm --add /dev/md1 /dev/sdd2

¿Es seguro?

Actualizar

Publico el script del analizador de superbloque que usé para hacer esa tabla en mi comentario. Quizás alguien lo encuentre útil. Gracias por toda tu ayuda.

Primero verifique los discos, intente ejecutar una autocomprobación inteligente

for i in a b c d; do
    smartctl -s on -t long /dev/sd$i
done

Puede tardar algunas horas en finalizar, pero verifique el estado de prueba de cada unidad cada pocos minutos, es decir

smartctl -l selftest /dev/sda

Si el estado de un disco no se completa debido a errores de lectura, entonces este disco debe considerarse inseguro para el reensamblado de md1. Después de que finalice la autocomprobación, puede comenzar a tratar de volver a ensamblar su matriz. Opcionalmente, si desea ser más cauteloso, mueva los discos a otra máquina antes de continuar (solo en caso de RAM / controlador / etc. defectuosos).

Recientemente, tuve un caso exactamente como este. Una unidad falló, volví a agregarla a la matriz pero durante la reconstrucción 3 de 4 unidades fallaron por completo. El contenido de / proc / mdadm era el mismo que el tuyo (tal vez no en el mismo orden)

md1 : inactive sdc2[2](S) sdd2[4](S) sdb2[1](S) sda2[0](S)

Pero tuve suerte y volví a armar la matriz con esto

mdadm --assemble /dev/md1 --scan --force

Al observar el resultado de --examine que proporcionó, puedo decir que sucedió el siguiente escenario: sdd2 falló, lo eliminó y lo volvió a agregar, por lo que se convirtió en una unidad de repuesto tratando de reconstruir. Pero al reconstruir sda2 falló y luego sdb2 falló. Entonces, el contador de eventos es más grande en sdc2 y sdd2, que son las últimas unidades activas en la matriz (aunque sdd no tuvo la oportunidad de reconstruirse y, por lo tanto, es el más desactualizado de todos). Debido a las diferencias en los contadores de eventos, --force será necesario. Entonces también podrías probar esto

mdadm --assemble /dev/md1 /dev/sd[abc]2 --force

Para concluir, creo que si el comando anterior falla, debería intentar recrear la matriz de esta manera:

mdadm --create /dev/md1 --assume-clean -l5 -n4 -c64 /dev/sd[abc]2 missing

Si lo hace --create, la missingparte es importante, no intente agregar una cuarta unidad en la matriz, porque entonces comenzará la construcción y perderá sus datos . Crear la matriz con una unidad que falta, no cambiará su contenido y tendrá la oportunidad de obtener una copia en otro lugar (raid5 no funciona de la misma manera que raid1).

Si eso no logra abrir la matriz, pruebe esta solución (script perl) aquí Recreando una matriz

Si finalmente logra abrir la matriz, el sistema de archivos estará sucio y probablemente dañado. Si un disco falla durante la reconstrucción, se espera que la matriz se detenga y se congele sin escribir en los otros discos. En este caso, fallaron dos discos, tal vez el sistema estaba realizando solicitudes de escritura que no pudo completar, por lo que hay una pequeña posibilidad de que pierda algunos datos, pero también una posibilidad de que nunca lo note :-)

editar: algunas aclaraciones agregadas.

Experimenté muchos problemas mientras usaba mdadm, pero nunca perdí datos. Debe evitar la --forceopción, o utilizarla con mucho cuidado, ya que puede perder todos sus datos. Por favor publique su/etc/mdadm/mdadm.conf