Tengo un servidor con 3 discos duros sata. Cada uno tiene 2 particiones: una pequeña es parte de /dev/md0, una matriz raid1 (/boot), el resto es parte de una matriz raid5 (/dev/md1), que es un volumen físico lvm. En su interior hay 3 volúmenes lógicos (IIRC). Uno de ellos es un reiserfs de 3,6 fs que contiene alrededor de 100 gigas de datos.
Ayer este servidor falló. Al encenderlo, SMART me dijo que una de las unidades estaba muerta. De hecho, estaba haciendo muy malos ruidos. Entonces quité la unidad fallida e intenté reiniciar el sistema en los 2 discos restantes. Lo cual fracasó.
Con un CD en vivo, lo inicié e intenté reiniciar la matriz. Desafortunadamente, mdadm se negó a hacerlo porque pensó que uno de los 2 discos restantes también había fallado.
Entonces, siguiendo los consejos que se encuentran en¿Cómo recuperar una matriz md RAID5 de Linux averiada?que parecía que podría aplicarse a mi situación, hice algo que probablemente fue simplemente estúpido: corrí
mdadm --create /dev/md1 --assume-clean -l5 -n3 -c64 /dev/sd[ab]2 missing
Ahora, puedo iniciar esta matriz, pero las herramientas lvm (vgscan, vgdisplay, pvck) no pueden encontrar nada relacionado con lvm en la matriz y no puedo acceder a mis datos. ¿Acabo de borrar todos los metadatos de lvm?
Mi sensación es que los datos reales todavía están ahí, sin daños (aparte de los metadatos de lvm). ¿Existe la posibilidad de recuperar los datos? ¿Cómo?
ACTUALIZAR:
Siguiendo los consejos de psusi (a continuación), probé cada una de las siguientes formas de recrear la matriz:
mdadm --create /dev/md1 --assume-clean -l5 -n3 -c64 /dev/sda2 /dev/sdb2 missing
mdadm --create /dev/md1 --assume-clean -l5 -n3 -c64 /dev/sdb2 /dev/sda2 missing
mdadm --create /dev/md1 --assume-clean -l5 -n3 -c64 /dev/sda2 missing /dev/sdb2
mdadm --create /dev/md1 --assume-clean -l5 -n3 -c64 /dev/sdb2 missing /dev/sda2
mdadm --create /dev/md1 --assume-clean -l5 -n3 -c64 missing /dev/sda2 /dev/sdb2
mdadm --create /dev/md1 --assume-clean -l5 -n3 -c64 missing /dev/sdb2 /dev/sda2
mdadm --create /dev/md1 --assume-clean -l5 -n3 -c512 /dev/sda2 /dev/sdb2 missing
mdadm --create /dev/md1 --assume-clean -l5 -n3 -c512 /dev/sdb2 /dev/sda2 missing
mdadm --create /dev/md1 --assume-clean -l5 -n3 -c512 /dev/sda2 missing /dev/sdb2
mdadm --create /dev/md1 --assume-clean -l5 -n3 -c512 /dev/sdb2 missing /dev/sda2
mdadm --create /dev/md1 --assume-clean -l5 -n3 -c512 missing /dev/sda2 /dev/sdb2
mdadm --create /dev/md1 --assume-clean -l5 -n3 -c512 missing /dev/sdb2 /dev/sda2
Que son básicamente todos los pedidos posibles, tanto con -c64 como con -c512. Después de cada prueba, ejecuté un vgscan. Ninguno encontró nada. ¿Quizás no debería usar vgscan sino alguna otra herramienta?
ACTUALIZACIÓN 2:
Intenté volver a conectar el disco duro defectuoso. Y milagro, parece funcionar de alguna manera. Al menos, lo suficiente para examinarlo:
root@debian:~# mdadm --examine /dev/sda2
/dev/sda2:
Magic : a92b4efc
Version : 0.90.00
UUID : 1f5462ab:6945560d:019b01a5:914dd464
Creation Time : Fri Oct 17 12:40:40 2008
Raid Level : raid5
Used Dev Size : 160015360 (152.60 GiB 163.86 GB)
Array Size : 320030720 (305.21 GiB 327.71 GB)
Raid Devices : 3
Total Devices : 3
Preferred Minor : 1
Update Time : Tue Apr 12 08:15:03 2011
State : active
Active Devices : 3
Working Devices : 3
Failed Devices : 0
Spare Devices : 0
Checksum : 64d514fb - correct
Events : 137
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
Entonces, ¿hay alguna manera de copiar este superbloque a los otros 2 dispositivos para poder iniciar la matriz "correctamente"?
Respuesta1
Tengo una configuración similar y puedo recomendar tener un Linux completo en la partición pequeña de cada unidad ynorefleje esas particiones pequeñas, pero haga que sean completamente arrancables por separado.
Puede syncrealizar la configuración excluyendo algunos archivos cruciales ( /etc/fstab, configuración de grub). Esto ocupa más espacio que solo /bootpero ahorra mucho tiempo cuando surgen problemas.
Respuesta2
Probablemente no ensambló las unidades en el mismo orden o utilizando el mismo tamaño de fragmento que antes. Debe averiguar cuál era el orden anterior y utilizar el mismo orden cuando vuelva a crear la matriz. En otras palabras, puede que no haya sido el tercer disco el que murió, sino el primero o el segundo, es posible que hayas confundido sda y sdb.
Respuesta3
Como @psusi insinuadoEl formato de metadatos es kye, como parece; ahora "1.2" es el predeterminado, no "0.9". Es una pena decirlo, pero esto podría provocar la pérdida de datos, ya que 1.2 usa un desplazamiento de 4 KiB:
1, 1.0, 1.1, 1.2 predeterminado Utilice el nuevo superbloque de formato versión 1. Esto tiene menos restricciones. Se puede mover fácilmente entre hosts con diferente endianidad y se puede controlar y reiniciar una operación de recuperación. Las diferentes subversiones almacenan el superbloque en diferentes ubicaciones del dispositivo, ya sea al final (para 1.0), al inicio (para 1.1) o en 4K desde el principio (para 1.2).
Un consejo (por desgracia, tardío): nunca se apresure a recrear una matriz sin intentarlo con -B: compilar:
-B, --build Build a legacy array without superblocks
UPD.: resultó que -Bse niega a construir RAID-5… :-/