Primero cómo llegué a esta situación:
Tenía una matriz RAID5 con discos de 2 TB cada uno (discos USB externos), luego quería crear una matriz cifrada más grande. Por lo tanto, obtuve 2 discos adicionales (también de 2 TB cada uno) y el plan era ejecutar el arreglo original en modo degradado, configurar el nuevo arreglo cifrado, copiar parte de los datos, luego reducir el arreglo original a 2 discos en modo degradado, ampliar el nuevo, copiar el resto de datos y finalmente ampliarlo a 7 discos RAID5 no degradados. Hice todo el procedimiento con /dev/loopX dispositivos de 2 GB cada uno para comprobar si mi plan tiene alguna advertencia.
Todo salió bien con la matriz real hasta el punto en que uno de los nuevos discos falló. Cuando reemplacé este, el orden en que el kernel reconoce los discos cambió después del siguiente reinicio (/dev/sdb , /dev/sdc , … eran todos discos diferentes a los anteriores). Todo se arruinó y no me di cuenta hasta que uno de los discos se volvió a sincronizar como miembro de la matriz incorrecta. Me ahorro los detalles de esta historia y voy directo al grano:
Ahora tengo una matriz cifrada, RAID5 de 3 discos, degradada en /dev/sdc1 y /dev/sdd1 , funcionando perfectamente bien, todos los datos allí y un sistema de archivos saludable de acuerdo con fsck -f .
Hasta ahora todo bien.
Todo el problema ahora se reduce a 3 discos:no puedo hacer que esta matriz no cifrada vuelva a funcionar. Estoy bastante seguro de que los datos TIENE estar allí en /dev/sdf1 , /dev/sdg1 , /dev/sdh1 , ya que esta era una matriz en funcionamiento justo antes de que UNO de los discos se estropeara (accidentalmente se volvió a sincronizar como miembro de la otra matriz cifrada, como se dijo antes). Entonces, uno de estos tres discos puede tener datos de matriz incorrectos, pero ¿cuál? Y dos de ellos tienen que ser buenos, pero ¿cómo lo descubro?
Probé todas las permutaciones de mdadm --create … con /dev/sdf1 , /dev/sdg1 , /dev/sdh1 y "faltante" como:
mdadm --create /dev/md0 --level=5 --raid-devices=3 /dev/sdf1 /dev/sdg1 missing
mdadm --create /dev/md0 --level=5 --raid-devices=3 /dev/sdf1 missing /dev/sdg1
...y por supuesto comprobado cada vez con
fsck /dev/md0
que se quejaba de una supermanzana no válida.
Cada vez que mdadm creaba la matriz, pero no había ningún sistema de archivos legible, solo contenía basura, ninguna de las permutaciones utilizadas con mdadm finalmente funcionó.
Entonces mi pregunta ahora es:¿Qué opciones me quedan? Además de perder mis datos y reconstruir la matriz desde cero, por supuesto.
Aquí alguna información adicional (todos los discos):
mdadm --examine /dev/sdb1
/dev/sdb1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : cfee26c0:414eee94:e470810c:17141589
Name : merlin:0 (local to host merlin)
Creation Time : Sun Oct 28 11:38:32 2012
Raid Level : raid5
Raid Devices : 3
Avail Dev Size : 3906760704 (1862.89 GiB 2000.26 GB)
Array Size : 3906759680 (3725.78 GiB 4000.52 GB)
Used Dev Size : 3906759680 (1862.89 GiB 2000.26 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
State : clean
Device UUID : f4f0753e:56b8d6a5:84ec2ce8:dbc933f0
Update Time : Sun Oct 28 11:38:32 2012
Checksum : 60093b72 - correct
Events : 0
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 1
Array State : AA. ('A' == active, '.' == missing)
mdadm --examine /dev/sdc1
/dev/sdc1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 5cb45bae:7a4843ba:4ad7dbfb:5c129d2a
Name : merlin:1 (local to host merlin)
Creation Time : Wed Sep 26 07:32:32 2012
Raid Level : raid5
Raid Devices : 3
Avail Dev Size : 3906760704 (1862.89 GiB 2000.26 GB)
Array Size : 3905299456 (3724.38 GiB 3999.03 GB)
Used Dev Size : 3905299456 (1862.19 GiB 1999.51 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
State : clean
Device UUID : 9e2f9ae6:6c95d05e:8d83970b:f1308de0
Update Time : Fri Oct 26 03:26:37 2012
Checksum : 79d4964b - correct
Events : 220
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 0
Array State : AA. ('A' == active, '.' == missing)
mdadm --examine /dev/sdd1
/dev/sdd1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 5cb45bae:7a4843ba:4ad7dbfb:5c129d2a
Name : merlin:1 (local to host merlin)
Creation Time : Wed Sep 26 07:32:32 2012
Raid Level : raid5
Raid Devices : 3
Avail Dev Size : 3906760704 (1862.89 GiB 2000.26 GB)
Array Size : 3905299456 (3724.38 GiB 3999.03 GB)
Used Dev Size : 3905299456 (1862.19 GiB 1999.51 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
State : clean
Device UUID : 98b07c41:ff4bea98:2a765a6b:63d820e0
Update Time : Fri Oct 26 03:26:37 2012
Checksum : 6e2767e8 - correct
Events : 220
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 1
Array State : AA. ('A' == active, '.' == missing)
mdadm --examine /dev/sde1
/dev/sde1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 6db9959d:3cdd4bc3:32a241ad:a9f37a0c
Name : merlin:0 (local to host merlin)
Creation Time : Sun Oct 28 12:12:59 2012
Raid Level : raid5
Raid Devices : 3
Avail Dev Size : 3905299943 (1862.19 GiB 1999.51 GB)
Array Size : 3905299456 (3724.38 GiB 3999.03 GB)
Used Dev Size : 3905299456 (1862.19 GiB 1999.51 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
State : clean
Device UUID : 677a4410:8931e239:2c789f83:e130e6f7
Update Time : Sun Oct 28 12:12:59 2012
Checksum : 98cb1950 - correct
Events : 0
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 2
Array State : A.A ('A' == active, '.' == missing)
mdadm --examine /dev/sdf1
/dev/sdf1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 3700a0a6:3fadfd73:bc74b618:a5526767
Name : merlin:0 (local to host merlin)
Creation Time : Sun Oct 28 11:28:30 2012
Raid Level : raid5
Raid Devices : 3
Avail Dev Size : 3905392640 (1862.24 GiB 1999.56 GB)
Array Size : 3905391616 (3724.47 GiB 3999.12 GB)
Used Dev Size : 3905391616 (1862.24 GiB 1999.56 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
State : clean
Device UUID : 5a8a5423:10b7a542:26b5e2b3:f0887121
Update Time : Sun Oct 28 11:28:30 2012
Checksum : 8e90495f - correct
Events : 0
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 1
Array State : AA. ('A' == active, '.' == missing)
mdadm --examine /dev/sdg1
/dev/sdg1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 202255c9:786f474d:ba928527:68425dd6
Name : merlin:0 (local to host merlin)
Creation Time : Sun Oct 28 11:24:36 2012
Raid Level : raid5
Raid Devices : 3
Avail Dev Size : 3905299943 (1862.19 GiB 1999.51 GB)
Array Size : 3905299456 (3724.38 GiB 3999.03 GB)
Used Dev Size : 3905299456 (1862.19 GiB 1999.51 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
State : clean
Device UUID : 4605c729:c290febb:92901971:9a3ed814
Update Time : Sun Oct 28 11:24:36 2012
Checksum : 38ba4d0a - correct
Events : 0
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 1
Array State : AA. ('A' == active, '.' == missing)
mdadm --examine /dev/sdh1
/dev/sdh1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 682356f5:da2c442e:7bfc85f7:53aa9ea7
Name : merlin:0 (local to host merlin)
Creation Time : Sun Oct 28 12:13:44 2012
Raid Level : raid5
Raid Devices : 3
Avail Dev Size : 3906761858 (1862.89 GiB 2000.26 GB)
Array Size : 3906760704 (3725.78 GiB 4000.52 GB)
Used Dev Size : 3906760704 (1862.89 GiB 2000.26 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
State : clean
Device UUID : 489943b3:d5e35022:f52c917a:9ca6ff2a
Update Time : Sun Oct 28 12:13:44 2012
Checksum : f6947a7d - correct
Events : 0
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 1
Array State : AA. ('A' == active, '.' == missing)
cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md1 : active raid5 sdc1[0] sdd1[1]
3905299456 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
unused devices: <none>
¡Cualquier ayuda sería muy apreciada!
Relacionado:¿Por qué rsync no permite un tamaño de bloque> 128K?Respuesta aceptada:
Si acaba de perder un disco, debería he podido recuperarme de eso usando el mucho más seguro --assemble .
Ha ejecutado crear ahora tantas veces que todos los UUID son diferentes. sdc1 y sdd1 compartir un UUID (esperado, ya que esa es su matriz de trabajo)... el resto de los discos comparten un nombre, pero todos tienen diferentes UUID. Así que supongo que ninguno de esos son los supermanzanas originales. Lástima…
De todos modos, supongo que está intentando usar los discos incorrectos o está tratando de usar el tamaño de fragmento incorrecto (creo que el valor predeterminado ha cambiado con el tiempo). Es posible que su matriz anterior también haya usado una versión de superbloque diferente (ese valor predeterminado definitivamente ha cambiado), lo que podría compensar todos los sectores (y también destruir algunos de los datos). Finalmente, es posible que esté usando el diseño incorrecto, aunque eso es menos probable.
También es posible que su matriz de prueba sea de lectura y escritura (desde el punto de vista de md) que intenta usar ext3 en realidad hizo algunas escrituras. Por ejemplo, la repetición de un diario. Pero eso es solo si encontró una supermanzana en algún momento, creo.
Por cierto:creo que realmente deberías usar --assume-clean , aunque, por supuesto, una matriz degradada no intentará comenzar a reconstruir. Entonces probablemente desee configurar inmediatamente el modo de solo lectura.