mdadm raid5 recupera la falla del doble disco - con un giro (orden de la unidad)

Permítanme reconocer en primer lugar que he cometido errores y que tengo una copia de seguridad para la mayoría de los datos de este RAID, pero no para todos . Todavía tengo la esperanza de recuperar el resto de los datos. No tengo el dinero para llevar los discos a una empresa experta en recuperación.

Error # 0, no tener una copia de seguridad del 100%. Lo sé.

Tengo un mdadmsistema RAID5 de 4x3TB. Drives / dev / sd [be], todos con una partición /dev/sd[b-e]1. Soy consciente de que RAID5 en unidades muy grandes es arriesgado, pero lo hice de todos modos.

Eventos recientes

El RAID se degrada después de una falla de dos unidades. Una unidad [/ dev / sdc] realmente desapareció, la otra [/ dev / sde] volvió a funcionar después de un ciclo de encendido, pero no se volvió a agregar automáticamente al RAID. Así que me quedé con un RAID de 4 dispositivos con solo 2 unidades activas [/ dev / sdb y / dev / sdd].

Error # 1, no utilizar copias dd de las unidades para restaurar el RAID. No tenía los discos ni el tiempo. Error # 2, no hacer una copia de seguridad del superbloque y mdadm -Ede las unidades restantes.

Intento de recuperación

Remonté el RAID en modo degradado con

mdadm --assemble --force /dev/md0, using /dev/sd[bde]1.

Entonces podría acceder a mis datos. Lo reemplacé /dev/sdccon un repuesto; vacío; unidad idéntica

Quité el viejo /dev/sdc1del RAID

mdadm --fail /dev/md0 /dev/sdc1

Error # 3, no hacer esto antes de reemplazar la unidad

Luego particioné el nuevo /dev/sdcy lo agregué al RAID.

mdadm --add /dev/md0 /dev/sdc1

Luego comenzó a restaurar el RAID. ETA 300 min. Seguí el proceso /proc/mdstathasta el 2% y luego fui a hacer otras cosas.

Comprobando el resultado

Varias horas (pero menos de 300 minutos) más tarde, verifiqué el proceso. Se había detenido debido a un error de lectura /dev/sde1.

Aquí es donde realmente comienza el problema

Luego lo eliminé /dev/sde1del RAID y lo volví a agregar. No recuerdo por qué hice esto; era tarde.

mdadm --manage /dev/md0 --remove /dev/sde1
mdadm --manage /dev/md0 --add /dev/sde1

Sin embargo, /dev/sde1ahora estaba marcado como de repuesto. Así que decidí recrear toda la matriz usando --assume-clean usando lo que pensé que era el orden correcto y con la /dev/sdc1falta.

mdadm --create /dev/md0 --assume-clean -l5 -n4 /dev/sdb1 missing /dev/sdd1 /dev/sde1

Eso funcionó, pero el sistema de archivos no fue reconocido al intentar montar. (Debería haber sido EXT4).

Orden del dispositivo

Luego verifiqué una copia de seguridad reciente que tenía /proc/mdstaty encontré el orden de la unidad.

md0 : active raid5 sdb1[0] sde1[4] sdd1[2] sdc1[1]
      8790402048 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/4] [UUUU]

Entonces recordé que este RAID había sufrido una pérdida de unidad hace aproximadamente un año, y me recuperé reemplazando la unidad defectuosa por una de repuesto. Eso puede haber codificado un poco el orden del dispositivo ... así que no había unidad [3] sino solo [0], [1], [2] y [4].

Traté de encontrar el orden de la unidad con el script Permute_array: https://raid.wiki.kernel.org/index.php/Permute_array.pl pero no encontré el orden correcto.

Preguntas

Ahora tengo dos preguntas principales:

1. Arruiné todos los superbloques en las unidades, pero solo di:

   mdadm --create --assume-clean
   

   comandos (por lo que no debería haber sobrescrito los datos en sí /dev/sd[bde]1. ¿Tengo razón en que, en teoría, el RAID se puede restaurar [suponiendo por un momento que /dev/sde1está bien] si solo encuentro el orden correcto del dispositivo?

2. ¿Es importante que /dev/sde1se le dé el número de dispositivo [4] en el RAID? Cuando lo creo con

   mdadm --create /dev/md0 --assume-clean -l5 -n4 \
     /dev/sdb1 missing /dev/sdd1 /dev/sde1
   

   se le asigna el número [3]. Me pregunto si eso es relevante para el cálculo de los bloques de paridad. Si resulta ser importante, ¿cómo puedo recrear la matriz con la /dev/sdb1[0]falta [1] /dev/sdd1[2] /dev/sde1[4]? Si pudiera hacer que eso funcione, podría iniciarlo en modo degradado y agregar la nueva unidad /dev/sdc1y dejar que se vuelva a sincronizar.

Está bien si quisieras señalarme que este puede no haber sido el mejor curso de acción, pero verás que me di cuenta de esto. Sería genial si alguien tiene alguna sugerencia.

Para responder tu pregunta,

1. ¿Se puede restaurar?

   • Lo primero es lo primero: DETÉNGASE, siéntese y piense un poco. Sí, el algoritmo, el tamaño del fragmento y el orden del disco son vitales para obtener el sistema de archivos que estaba presente, para volver a ensamblarlo correctamente. Pero como ha sobrescrito los superbloques, ahora le quedan pruebas y errores.
   • En segundo lugar, ¿hay alguna forma de recuperar el diseño del disco anterior? Siempre hago un mdadm --detail> backupfile solo para mantener el diseño del disco en un lugar seguro. Verifique dmesg, / var / log para ver si hay evidencia de cómo se configuraron los discos en la incursión.
   • Por último, si coincide con el tamaño del fragmento anterior y el orden del disco, puede haber dañado el superbloque ext4: hay formas de escanear rápidamente otros superbloques (y hay un ingenioso programa llamado TestDisk que escanea los superbloques de los sistemas de archivos existentes e intenta buscarlos) manualmente: http://www.cgsecurity.org/wiki/Main_Page )

2. Como sdc es nuevo, continuaría intentando ensamblar manualmente a través de la cláusula faltante, y sí, sde debe estar en el orden correcto para que se ensamble en modo degradado. Una vez que encuentre el diseño correcto, copie todos los datos de la matriz y comience nuevamente, documentando el diseño (para que no vuelva a encontrarse con este problema).

Buena suerte

Antes de hacer NADA más, capture un 'mdadm --examine / dev / sdX1' para cada una de las unidades que estaban en su matriz, y un 'mdadm --detail / dev / md0' a partir de eso, debería poder determinar El diseño exacto.

Solo tuve que hacer esto yo mismo para recuperar una matriz de Synology en una pregunta separada:

¿Cómo recuperar una matriz mdadm en Synology NAS con la unidad en estado "E"?

Editar: Lo siento, acabo de ver que dijiste que perdiste los superbloques en todas las unidades.

Sus comandos posteriores LOOK correcto. La opción más simple podría ser ejecutar las creaciones con cada pedido posible, y luego ver si puede montar y acceder al sistema de archivos en ellas de solo lectura.

Esta pregunta es antigua y estoy seguro de que nadie puede ayudarte ahora, pero para otros que leen:

el error más peligroso que cometiste no es uno que numeraste, que era ejecutar:

mdadm --create ...

en los discos originales, antes de estar preparado para saber qué hacer. Esto ha sobrescrito los metadatos, por lo que no tiene registro del orden de la unidad, el desplazamiento de datos, el tamaño del fragmento, etc.

Para recuperarse de esto, debe sobrescribirlos nuevamente con los valores correctos. La forma más fácil de saber esto es mirar los metadatos, pero eso ya lo destruiste. La siguiente forma es adivinar. Adivina las diferentes combinaciones de un comando como este, con diferentes valores para cualquiera de las opciones, excepto lo que sabes (4 dispositivos, nivel 5), y también un orden de disco diferente:

mdadm --create /dev/md0 --assume-clean --metadata=1.2 --raid-devices=4 --level=5 --layout=... --chunk=512 --data-offset=128M /dev/sdb1 missing /dev/sdd1 /dev/sde1

Pero dado que NO conoce el resultado correcto, nuevamente, no debe ejecutarlo en los discos antiguos destruyéndolos aún más, cometiendo el mismo error fatal. En su lugar, use una superposición; Por ejemplo, este procedimiento debería funcionar para mantener seguros los originales.

Una vez que haya encontrado algunos argumentos que producen una matriz de trabajo que puede fsck o montar y verificar (por ejemplo, verifique la suma de comprobación de un archivo lo suficientemente grande como para abarcar todos los miembros de la banda como un iso que debería haber almacenado con su suma de comprobación / pgp firma, o descomprimir -t o gunzip -ta archivo grande)