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.
fuente
mdadm --re-addque no es lo que estás buscando. ¿Hiciste una prueba de memoria recientemente? ¿Tiene algún mensaje de registro relacionado con la falla de la matriz?mdadm -A /dev/md1 /dev/sd{b,c,d}2(tal vez--force)? (Si no está, copia de seguridad de los superbloques en primer lugar.)/dev/sdd2puede estar en una matriz separada a pesar de tener el mismo UUID quesd{a,b,c}2.Respuestas:
Primero verifique los discos, intente ejecutar una autocomprobación inteligente
Puede tardar algunas horas en finalizar, pero verifique el estado de prueba de cada unidad cada pocos minutos, es decir
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)
Pero tuve suerte y volví a armar la matriz con esto
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
Para concluir, creo que si el comando anterior falla, debería intentar recrear la matriz de esta manera:
Si lo hace
--create, lamissingparte 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.
fuente
mdadm --assemble /dev/md1 /dev/sd[abc]2 --forcetrabajó. Gracias. ¡Guardaste mis datos! :) No intentaré agregar el cuarto disco porque los primeros 3 no son tan buenos como pensaba anteriormente. El autoexamen revelado cada uno tiene 10-20 bloques ilegibles. Me siento estúpido por no comprobar esto primero.--assume-clean(lo hizo) no lo hará.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.conffuente