Tengo una copia de seguridad de todos los datos importantes. Al final es necesaria una restauración. Pero primero quiero probar algo antes de seguir este camino y es una buena situación para aprender algo sobre todo lo que usé aquí.
Tengo un controlador mpt sas con 8 canales SATA conectados a dos bahías de discos internas de 2,5" configuradas. Dos de ellas se usaron para unidades SSD, que solo se usan para almacenar en caché volúmenes lvm.
Se utilizan 6 discos de 1 TB para partes de datos en la partición 3 configuradas como una matriz de software RAID5.
Dos de ellos se han utilizado para bootparts en la partición 1 y rootparts para la partición 2. Ambas bootparts son un RAID1 simple con ext3 fs. Ambas partes de arranque son un RAID1 que está cifrado con luks y tiene un lvm vg xenrootdg con varios lvs. Las 6 partes de datos se utilizan como RAID5 como se describe. El volumen raid está cifrado con luks y en estos hay un lvm con un vg xendatadg. Sólo en el volumen RAID5 tiene problemas para abrirlos.
El problema principal fueron los múltiples cortes de energía en el gabinete de 4 discos que contiene 4 de los seis discos de 1TB. Se debe agregar un disco nuevo debido a un disco eliminado, tal vez cerca del final se deba resincronizar el nuevo disco. Esto no se sabe exactamente.
Podría iniciar el volumen después del primer error y podría iniciar una resincronización. Pero el problema vuelve a ocurrir y estos volúmenes RAID volvieron a fallar.
En el momento de la segunda falla, el sistema no pudo leer sectores de un disco especial y el RAID5 se degradó debido a un error de lectura permanente registrado de algún sector de uno de los discos fallidos.
Mientras tanto, el kernel vuelve a registrar los discos con un nuevo nombre (por ejemplo, ha cambiado el nombre de sde a sdk, etc.).
Después de reiniciar el sistema, verifiqué qué disco se registró como fallido y los encontré comparando el número de serie. Agregar el disco a /dev/zero no mostró ningún problema, así que intenté resincronizar nuevamente pero ocurre el mismo problema.
Ahora me di cuenta de que podría ser un problema con la alimentación del compartimiento del disco, así que quité todos los discos y al menos los conecté en los puertos SATA existentes en la placa base. Agregué más discos al controlador sas para poder hacer una copia de seguridad de las particiones ahora usando dd.
Pude copiar todas las particiones relacionadas en dos discos nuevos, por lo que la lectura no es un problema.
También sólo máx. Se utilizaban 3 volúmenes dentro del lvm vg. Por lo tanto, la mayoría de los lvs deberían estar todavía en estado limpio porque no se modificaron después de que extraí el primer disco n.° 2 (sdl3).
Revisé smartctl para que no haya ningún problema permanente en el disco registrado (no se muestran errores irrecuperables ni sectores reubicados).
Pero no puedo iniciar el volumen RAID5 aunque debería tener suficientes discos.
Tengo 5 discos (n.° 0,1,3,4,5) y el disco n.° 2 aún existente, eliminado. Además, el nuevo disco de reemplazo número 2 está ahí, pero se muestra como repuesto. Debería ser posible subir el volumen con #0,1,3,4,5, que son 5 de 6 volúmenes disponibles. Pero todo lo que intento, al menos el número 3, me genera el mayor problema porque nunca se acepta como parte del volumen.
Debido a que sdX podría cambiar aquí el examen en el orden de función del dispositivo que se muestra. Aquí una breve lista por el momento:
#0 sdc3 #1 sdk3 #3 sda3 #4 sdg3 #5 sdf3
eliminado #2 sdl3 nuevo #2 marcado como #S sdb3
root@newxen:~# mdadm -E /dev/sdc3
/dev/sdc3:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : 8d0acbbb:73bcfac9:a26557de:c29d5434
Name : newxen:128 (local to host newxen)
Creation Time : Sun Nov 8 22:22:15 2015
Raid Level : raid5
Raid Devices : 6
Avail Dev Size : 1909221936 (910.39 GiB 977.52 GB)
Array Size : 4773051840 (4551.94 GiB 4887.61 GB)
Used Dev Size : 1909220736 (910.39 GiB 977.52 GB)
Data Offset : 260992 sectors
Super Offset : 8 sectors
Unused Space : before=260912 sectors, after=1200 sectors
State : clean
Device UUID : 1142cc76:b224395c:8fb15126:fd1801fe
Internal Bitmap : 8 sectors from superblock
Update Time : Tue Jan 16 00:02:32 2024
Checksum : bae896cd - correct
Events : 248741
Layout : left-symmetric
Chunk Size : 64K
Device Role : Active device 0
Array State : AARA.A ('A' == active, '.' == missing, 'R' == replacing)
root@newxen:~# mdadm -E /dev/sdk3
/dev/sdk3:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : 8d0acbbb:73bcfac9:a26557de:c29d5434
Name : newxen:128 (local to host newxen)
Creation Time : Sun Nov 8 22:22:15 2015
Raid Level : raid5
Raid Devices : 6
Avail Dev Size : 1909221936 (910.39 GiB 977.52 GB)
Array Size : 4773051840 (4551.94 GiB 4887.61 GB)
Used Dev Size : 1909220736 (910.39 GiB 977.52 GB)
Data Offset : 260992 sectors
Super Offset : 8 sectors
Unused Space : before=260912 sectors, after=1200 sectors
State : clean
Device UUID : 701ed2ed:13a03708:da9cc185:9c9ce3e2
Internal Bitmap : 8 sectors from superblock
Update Time : Tue Jan 16 10:26:32 2024
Checksum : 223defb1 - correct
Events : 248741
Layout : left-symmetric
Chunk Size : 64K
Device Role : Active device 1
Array State : .A...A ('A' == active, '.' == missing, 'R' == replacing)
root@newxen:~# mdadm -E /dev/sdl3
/dev/sdl3:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : 8d0acbbb:73bcfac9:a26557de:c29d5434
Name : newxen:128 (local to host newxen)
Creation Time : Sun Nov 8 22:22:15 2015
Raid Level : raid5
Raid Devices : 6
Avail Dev Size : 1909221936 (910.39 GiB 977.52 GB)
Array Size : 4773051840 (4551.94 GiB 4887.61 GB)
Used Dev Size : 1909220736 (910.39 GiB 977.52 GB)
Data Offset : 260992 sectors
Super Offset : 8 sectors
Unused Space : before=260912 sectors, after=1200 sectors
State : clean
Device UUID : 1b34e8d5:f3df3e52:307a06a0:38c265e4
Internal Bitmap : 8 sectors from superblock
Update Time : Mon Jan 15 13:36:40 2024
Checksum : 7023234b - correct
Events : 248741
Layout : left-symmetric
Chunk Size : 64K
Device Role : Active device 2
Array State : AAAAAA ('A' == active, '.' == missing, 'R' == replacing)
root@newxen:~# mdadm -E /dev/sda3
/dev/sda3:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x83
Array UUID : 8d0acbbb:73bcfac9:a26557de:c29d5434
Name : newxen:128 (local to host newxen)
Creation Time : Sun Nov 8 22:22:15 2015
Raid Level : raid5
Raid Devices : 6
Avail Dev Size : 1909221936 (910.39 GiB 977.52 GB)
Array Size : 4773051840 (4551.94 GiB 4887.61 GB)
Used Dev Size : 1909220736 (910.39 GiB 977.52 GB)
Data Offset : 260992 sectors
Super Offset : 8 sectors
Recovery Offset : 0 sectors
Unused Space : before=260912 sectors, after=1200 sectors
State : clean
Device UUID : fa9d44c6:bb18bc8c:04ed5943:13a6ddfb
Internal Bitmap : 8 sectors from superblock
Update Time : Tue Jan 16 00:02:32 2024
Checksum : 55c99a69 - correct
Events : 243265
Layout : left-symmetric
Chunk Size : 64K
Device Role : Active device 3
Array State : AAAA.A ('A' == active, '.' == missing, 'R' == replacing)
root@newxen:~# mdadm -E /dev/sdg3
/dev/sdg3:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x8b
Array UUID : 8d0acbbb:73bcfac9:a26557de:c29d5434
Name : newxen:128 (local to host newxen)
Creation Time : Sun Nov 8 22:22:15 2015
Raid Level : raid5
Raid Devices : 6
Avail Dev Size : 1909221936 (910.39 GiB 977.52 GB)
Array Size : 4773051840 (4551.94 GiB 4887.61 GB)
Used Dev Size : 1909220736 (910.39 GiB 977.52 GB)
Data Offset : 260992 sectors
Super Offset : 8 sectors
Recovery Offset : 0 sectors
Unused Space : before=260904 sectors, after=1200 sectors
State : clean
Device UUID : 63a171d2:dad103ed:ff18efc4:d31bc05d
Internal Bitmap : 8 sectors from superblock
Update Time : Tue Jan 16 10:22:01 2024
Bad Block Log : 512 entries available at offset 72 sectors - bad blocks present.
Checksum : a5b990c1 - correct
Events : 244946
Layout : left-symmetric
Chunk Size : 64K
Device Role : Active device 4
Array State : .AA.AA ('A' == active, '.' == missing, 'R' == replacing)
root@newxen:~# mdadm -E /dev/sdf3
/dev/sdf3:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : 8d0acbbb:73bcfac9:a26557de:c29d5434
Name : newxen:128 (local to host newxen)
Creation Time : Sun Nov 8 22:22:15 2015
Raid Level : raid5
Raid Devices : 6
Avail Dev Size : 1909221936 (910.39 GiB 977.52 GB)
Array Size : 4773051840 (4551.94 GiB 4887.61 GB)
Used Dev Size : 1909220736 (910.39 GiB 977.52 GB)
Data Offset : 260992 sectors
Super Offset : 8 sectors
Unused Space : before=260912 sectors, after=1200 sectors
State : clean
Device UUID : d6e11e48:e1258598:f9d5251c:795c8308
Internal Bitmap : 8 sectors from superblock
Update Time : Tue Jan 16 10:26:32 2024
Checksum : c8dc31e3 - correct
Events : 248741
Layout : left-symmetric
Chunk Size : 64K
Device Role : Active device 5
Array State : .A...A ('A' == active, '.' == missing, 'R' == replacing)
Here the replacing disc
root@newxen:~# mdadm -E /dev/sdb3
/dev/sdb3:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x9
Array UUID : 8d0acbbb:73bcfac9:a26557de:c29d5434
Name : newxen:128 (local to host newxen)
Creation Time : Sun Nov 8 22:22:15 2015
Raid Level : raid5
Raid Devices : 6
Avail Dev Size : 7720024847 (3681.19 GiB 3952.65 GB)
Array Size : 4773051840 (4551.94 GiB 4887.61 GB)
Used Dev Size : 1909220736 (910.39 GiB 977.52 GB)
Data Offset : 260992 sectors
Super Offset : 8 sectors
Unused Space : before=260912 sectors, after=5810804111 sectors
State : clean
Device UUID : 1be91027:ca00bcc9:7e21dd61:76cdf787
Internal Bitmap : 8 sectors from superblock
Update Time : Tue Jan 16 10:26:32 2024
Bad Block Log : 512 entries available at offset 16 sectors - bad blocks present.
Checksum : f892a18d - correct
Events : 248741
Layout : left-symmetric
Chunk Size : 64K
Device Role : spare
Array State : .A...A ('A' == active, '.' == missing, 'R' == replacing)
Situación ahora:
root@newxen:~# cat /proc/mdstat
Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10]
md128 : inactive sda3[3](S) sdb3[6](S) sdf3[5](S) sdc3[0](S) sdg3[2](S) sdk3[1](S)
8633067263 blocks super 1.2
...
root@newxen:~# mdadm --detail /dev/md128
/dev/md128:
Version : 1.2
Raid Level : raid0
Total Devices : 6
Persistence : Superblock is persistent
State : inactive
Working Devices : 6
Name : newxen:128 (local to host newxen)
UUID : 8d0acbbb:73bcfac9:a26557de:c29d5434
Events : 248741
Number Major Minor RaidDevice
- 8 163 - /dev/sdk3
- 8 99 - /dev/sdg3
- 8 83 - /dev/sdf3
- 8 35 - /dev/sdc3
- 8 19 - /dev/sdb3
- 8 3 - /dev/sda3
Si verifico la última fecha y el estado de la matriz, quiero decir que al principio el 15 de enero 13:36:40 sdl3 se configuró falló y se eliminó (lo cual hice manualmente) con AAAAAA, pero debería estar limpio el 16 de enero 00:02:32 sda3 con AAAA.A parece limpio el 16 de enero 00:02:32 sdc3 con AARA.A parece limpio el 16 de enero 10:22:01 sdg3 con .AA.AA parece no limpio el 16 de enero 10:26:32 sdk3 con .A. ..A parece no estar limpio 16 de enero 10:26:32 sdf3 con .A...A parece estar limpio 16 de enero 10:26:32 sdb3 con .A..A parece no estar limpio
Debería ser posible ensamblar el volumen raid con las partes existentes sda3 sdc3 sdg3 sdk3 sdf3, tal vez porque estaba en la matriz sdb3.
Probé diferentes métodos pero ninguno de ellos me devuelve a un volumen de resincronización.
mdadm --assemble --scan --verbose
...
mdadm: /dev/sda3 is identified as a member of /dev/md128, slot 3.
mdadm: /dev/sdl3 is identified as a member of /dev/md128, slot 2.
mdadm: /dev/sdf3 is identified as a member of /dev/md128, slot 5.
mdadm: /dev/sdg3 is identified as a member of /dev/md128, slot 4.
mdadm: /dev/sdk3 is identified as a member of /dev/md128, slot 1.
mdadm: /dev/sdc3 is identified as a member of /dev/md128, slot 0.
mdadm: /dev/sdb3 is identified as a member of /dev/md128, slot -1.
mdadm: ignoring /dev/sdk3 as it reports /dev/sdl3 as failed
mdadm: ignoring /dev/sdf3 as it reports /dev/sdl3 as failed
mdadm: device 12 in /dev/md128 has wrong state in superblock, but /dev/sdb3 seems ok
mdadm: no uptodate device for slot 1 of /dev/md128
mdadm: added /dev/sdl3 to /dev/md128 as 2
mdadm: added /dev/sda3 to /dev/md128 as 3 (possibly out of date)
mdadm: added /dev/sdg3 to /dev/md128 as 4 (possibly out of date)
mdadm: no uptodate device for slot 5 of /dev/md128
mdadm: added /dev/sdb3 to /dev/md128 as -1
mdadm: added /dev/sdc3 to /dev/md128 as 0
mdadm: /dev/md128 assembled from 2 drives and 1 spare - not enough to start the array.
...
root@newxen:~# cat /proc/mdstat
Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10]
md128 : inactive sdf3[5](S) sdb3[6](S) sdc3[0](S) sdk3[1](S) sdg3[2](S) sdl3[4](S)
8633067263 blocks super 1.2
...
root@newxen:~# mdadm --detail /dev/md128
/dev/md128:
Version : 1.2
Raid Level : raid0
Total Devices : 6
Persistence : Superblock is persistent
State : inactive
Working Devices : 6
Name : newxen:128 (local to host newxen)
UUID : 8d0acbbb:73bcfac9:a26557de:c29d5434
Events : 248741
Number Major Minor RaidDevice
- 8 179 - /dev/sdl3
- 8 163 - /dev/sdk3
- 8 99 - /dev/sdg3
- 8 83 - /dev/sdf3
- 8 35 - /dev/sdc3
- 8 19 - /dev/sdb3
Entonces parece que el antiguo sdl3 eliminado y el reemplazo del sdb3 causan algunos problemas. Entonces detuve md128 nuevamente e intenté abrirlo manualmente sin ellos:
root@newxen:~# mdadm --assemble /dev/md128 /dev/sdc3 /dev/sdk3 /dev/sda3 /dev/sdg3 /dev/sdf3 --verbose
mdadm: looking for devices for /dev/md128
mdadm: /dev/sdc3 is identified as a member of /dev/md128, slot 0.
mdadm: /dev/sdk3 is identified as a member of /dev/md128, slot 1.
mdadm: /dev/sda3 is identified as a member of /dev/md128, slot 3.
mdadm: /dev/sdg3 is identified as a member of /dev/md128, slot 4.
mdadm: /dev/sdf3 is identified as a member of /dev/md128, slot 5.
mdadm: ignoring /dev/sdk3 as it reports /dev/sdc3 as failed
mdadm: ignoring /dev/sdg3 as it reports /dev/sdc3 as failed
mdadm: ignoring /dev/sdf3 as it reports /dev/sdc3 as failed
mdadm: no uptodate device for slot 1 of /dev/md128
mdadm: no uptodate device for slot 2 of /dev/md128
mdadm: added /dev/sda3 to /dev/md128 as 3 (possibly out of date)
mdadm: no uptodate device for slot 4 of /dev/md128
mdadm: no uptodate device for slot 5 of /dev/md128
mdadm: added /dev/sdc3 to /dev/md128 as 0
mdadm: /dev/md128 assembled from 1 drive - not enough to start the array.
root@newxen:~# cat /proc/mdstat
Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10]
md128 : inactive sdk3[1](S) sdf3[5](S) sdg3[2](S) sdc3[0](S)
3818443872 blocks super 1.2
...
root@newxen:~# mdadm --detail /dev/md128
/dev/md128:
Version : 1.2
Raid Level : raid0
Total Devices : 4
Persistence : Superblock is persistent
State : inactive
Working Devices : 4
Name : newxen:128 (local to host newxen)
UUID : 8d0acbbb:73bcfac9:a26557de:c29d5434
Events : 248741
Number Major Minor RaidDevice
- 8 163 - /dev/sdk3
- 8 99 - /dev/sdg3
- 8 83 - /dev/sdf3
- 8 35 - /dev/sdc3
Entonces me pregunto si sda3 no se muestra en los detalles.
También intenté usar sdl3 en lugar de sdb3 e intenté volver a agregar las partes que faltaban, pero nada ayudó realmente. Entonces supongo que debería poner a cero los superbloques y recrear la incursión con la opción --assume-clean. En mi opinión, debería estar en el orden correcto. En el mejor de los casos, tal vez debería ser sin sdb3 y sdl3 porque no estoy seguro de que sdb3 haya llegado alguna vez al estado de sincronización antes de que ocurriera el primer problema. ¿Hay alguna manera de comprobarlo?
Entonces, si no existe otra opción, lo haría (¿este orden es correcto?)
mdadm --create --verbose --force --assume-clean /dev/md128 --level=5 --raid-devices=6 /dev/sdc3 /dev/sdk3 missing /dev/sda3 /dev/sdg3 /dev/sdf3
Otra solución podría ser asumir que el disco sdb3 debe estar casi sincronizado.
mdadm --create --verbose --force --assume-clean /dev/md128 --level=5 --raid-devices=6 /dev/sdc3 /dev/sdk3 /dev/sdb3 /dev/sda3 /dev/sdg3 /dev/sdf3
¿Cómo puedo comprobarlo?:
echo check >> /sys/block/md128/md/sync_action and then check dmesg carefully?
Otra cosa que me gustaría saber es ¿en qué sectores debo estar preparado para problemas una vez terminada la reconstrucción? ¿Alguna sugerencia sobre cómo puedo identificarlos?
Se agregaron más detalles: es difícil encontrar información detallada. Sería bueno que alguien pudiera confirmar o corregir mis ideas.
Mientras tanto, las pruebas de descifrado deben finalizar. No es necesario realizar correctamente ninguna permutación del orden de los dispositivos.
Por lo tanto, fue posible poner en funcionamiento la matriz RAID por la forma en que los datos en sí parecen todavía mezclados y aún no se pueden utilizar. Por eso, no puedo descifrar los datos de luks que contienen por el momento.