La semana pasada tuve un gran inconveniente en uno de los servidores de apoyo operacional, un rack server HP DL380 G5 (2009) el cual arrancaba desde una unidad HP de almacenamiento multiple de discos duros la cual ya cierto tiempo atras venia con un disco duro presentando fallo fisico el cual hacía parte de un arreglo de discos asociados a una storage pool ZFS. Este pool fue configurado con RAIDZ-2 (un RAIDZ reforzado con dual paridad para sostenerse en linea incluso con dos discos averiados o en fallo) La idea consistía en reemplazar el disco averiado por uno nuevo de repuesto. Pero eso es otra historia, para un próximo post lo dedicaré a compartir la experiencia del caso de uso acerca de reemplazar el disco averiado.
EL pasado viernes 12 de febrero, aseguré dicho host el cual para mi sorpresa desplegaba errores cíclicos en algunos sectores del disco de arranque, a pesar de la advertencia apagué el equipo y bueno retiré el disco pero había olvidado un juego de destornilladores especiales para poderlo soltar del caddy. Fui a colocarlo nuevamente y volver a encenderlo. He ahi que con gran sorpresa encuentro que el sistema no arranca! OMG!, no puede arrancar siquiera el grub boot. Con preocupación me retiré y el lunes siguiente (15 de febrero) empecé a revisar dicha novedad. Retiré el disco del slot 1 del MSA2000 unit que es donde estaba ubicado el grub bootloader, lo coloco en mi equipo el cual previamente le habia instalado una PCIe HBA Card con conector de cable multisata (4 puertos) que habia comprado unos 3 años atrás por eBay especifcamente para poder dumpear discos a bajo nivel con dd. Desafortunadamente el disco arrancó con sonido de cabeza atascada y traqueaba fuerte, clara señal de que algo no estaba bien en el. Ni siquiera era reconocido por la controladora asi que la situación se ponía color de hormiga. Para ese momento aun no acaba de recordar de que años atrás cuando preparé el sistema había configurado con RAID1 basado en "Linux MD". Fue entonces cuando procedí a desconectar el siguiente disco en orden del arreglo el cual efectivamente tendría la información del disco. Para verificar que estaba al menos bueno para su uso, procedi a colocarlo en el slot 1 y encenderlo. Intentaba bootearlo pero no tenía grub, fue cuando tomé ese disco y lo coloqué en la controladora instalada en mi estación de trabajo paara verificar que contenía en su interior al menos en los sectores de la cabecera del disco. Allí terminé encontrando que encima del RAID1 (Linux MD) encontré una estructura basada en LVM2 !!!!!. La titanica tarea iniciaba, lograr llegar al fondo de los datos y recuperar la información alli presente. Al tener RAID1 con 2 discos, y al tener el 1er disco fuera de linea fisicamente averiado y bloqueado, la unica forma era lograr acceder a las particiones que estaban por debajo de LVM y este por debajo de LinuxMD en ese disco de respaldo. Estos fueron los pasos que llevé a cabo para lograrlo: (desde mi equipo el disco ha sido dispuesto por el o/s desde /dev/sdd)
Primero que todo verificar la estructura de particionamiento de disco para saber en que parte se encuentra la información:
root@m0n0-PT1650:/home/m0n0lithic# sfdisk /dev/sdd
Checking that no-one is using this disk right now ...
OK
Disk /dev/sdd: 121601 cylinders, 255 heads, 63 sectors/track
Warning: extended partition does not start at a cylinder boundary.
DOS and Linux will interpret the contents differently.
Old situation:
Units = cylinders of 8225280 bytes, blocks of 1024 bytes, counting from 0
Device Boot Start End #cyls #blocks Id System
/dev/sdd1 0+ 31- 31- 248832 83 Linux
/dev/sdd2 31+ 121601- 121570- 976510977 5 Extended
/dev/sdd3 0 - 0 0 0 Empty
/dev/sdd4 0 - 0 0 0 Empty
/dev/sdd5 31+ 121601- 121570- 976510976 fd Linux raid autodetect
Input in the following format; absent fields get a default value.
Usually you only need to specify
Se escanea entonces dicha partición para ubicar mas información al respecto de su estructura:
mdadm --examine --scan /dev/sdd5 ARRAY /dev/md2 level=raid1 num-devices=2
ARRAY /dev/md/0 level=raid1 num-devices=2
↪UUID=9b6e03fe:b73c43f2:1a490486:daa901de
devices=/dev/sdd5
Como podemos observar la partición asignada a Linux RAID MD es la número 5. Ahora es turno de poder invocar el driver y simular el RAID para que el o/s me permita ingresar a lo que está debajo de el. Con la siguiente instrucción escaneo preliminarmente dicha partición para que el driver md le reconozca y la disponga:
# mdadm --examine --scan level=raid1 /dev/sdd5 num-devices=2 ARRAY /dev/md/0 metadata=1.2 UUID=9b6e03fe:b73c43f2:1a490486:daa901de name=copiapo:0
El UUID tambien es posible sacarlo por el sistema de asignacion al dispositivo md/0 en /dev/disk/by-uuid/
El siguiente paso luego de scanear en el dispositivo es habilitar la unidad al sistema linux RAID:
# mdadm -A -s
Se verifica que este ya atado con:
# cat /proc/mdstat
Luego se procede a recuperar y renombrar el volumen LVM2, pero para ello como no se tiene información certera de la estructura LVM2, se procede a capturar los primeros 255 sectores del disco a recuperar. Dicha salida se almacena en un archivo temporal. Es allí donde radica la información estructural:
# dd if=/dev/md0 bs=512 count=255 skip=1 of=/tmp/md2-raw-start
Parte de la información extraida es esta (para este ejemplo):
COP01 {
id = "jg3MRj-5TrS-wdBQ-IXCR-KJ0c-c1hF-hE3tTq"
seqno = 1
format = "lvm2" # informational
status = ["RESIZEABLE", "READ", "WRITE"]
flags = []
extent_size = 8192
max_lv = 0
max_pv = 0
metadata_copies = 0
physical_volumes {
pv0 {
id = "nKq99y-jngj-Aj0T-vw4O-nhsQ-2U1O-d0KVuC"
device = "/dev/md0"
status = ["ALLOCATABLE"]
flags = []
dev_size = 1952759424
pe_start = 2048
pe_count = 238373
}
}
# Generated by LVM2 version 2.02.95(2) (2012-03-06): Tue Jun 24 16:22:23 2014
contents = "Text Format Volume Group"
version = 1
description = ""
creation_host = "copiapo" # Linux copiapo 3.2.0-4-amd64 #1 SMP Debian 3.2.57-3 x86_64
creation_time = 1403626943 # Tue Jun 24 16:22:23 2014
logical_volumes {
SWAP {
id = "qHXmbW-I9hG-IL2V-SKXi-LFPv-PUuO-Kw74eR"
status = ["READ", "WRITE", "VISIBLE"]
id = "qHXmbW-I9hG-IL2V-SKXi-LFPv-PUuO-Kw74eR"
status = ["READ", "WRITE", "VISIBLE"]
flags = []
creation_host = "copiapo"
creation_time = 1403626970
segment_count = 1
segment1 {
start_extent = 0
extent_count = 2861
type = "striped"
stripe_count = 1 # linear
stripes = [
"pv0", 0
]
}
}
}
}
# Generated by LVM2 version 2.02.95(2) (2012-03-06): Tue Jun 24 16:22:50 2014
contents = "Text Format Volume Group"
version = 1
description = ""
creation_host = "copiapo" # Linux copiapo 3.2.0-4-amd64 #1 SMP Debian 3.2.57-3 x86_64
creation_time = 1403626970 # Tue Jun 24 16:22:50 2014
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@COP01 {
id = "jg3MRj-5TrS-wdBQ-IXCR-KJ0c-c1hF-hE3tTq"
seqno = 3
format = "lvm2" # informational
status = ["RESIZEABLE", "READ", "WRITE"]
ROOT {
id = "3K3u2T-Srwh-Cy0D-AQz0-uVUY-dTyP-JtMYSu"
status = ["READ", "WRITE", "VISIBLE"]
flags = []
creation_host = "copiapo"
creation_time = 1403627035
segment_count = 1
segment1 {
start_extent = 0
extent_count = 235512
type = "striped"
Como ya tenemos el nombre del grupo principal ("COP01") igualmente verificamos a través de vgscan (volume group) y pvscan (physical vol) asi:
# vgscan
Reading all physical volumes. This may take a while...
Found volume group "COP01" using metadata type lvm2
# pvscan
PV /dev/md0 VG COP01 lvm2 [931,14 GiB / 0 free]
Total: 1 [931,14 GiB] / in use: 1 [931,14 GiB] / in no VG: 0 [0 ]
Luego de identificado lógica y fisicamente el volumen LVM2, Se procede a activar el volume group "COP01"
# vgchange COP01 -a y
2 logical volume(s) in volume group "COP01" now active
Finalmente se habilita dicho VG (Volume Group) para que la capa de archivo del sistema operativo pueda reconocerlo como un dispositivo mas de I/O:
# mount /dev/COP01/ROOT /mnt/linux
root@m0n0-PT1650:/home/m0n0lithic# df
Filesystem 1K-blocks Used Available Use% Mounted on
udev 4052292 12 4052280 1% /dev
tmpfs 812632 1184 811448 1% /run
/dev/sdc6 110560080 9857656 95063256 10% /
none 4 0 4 0% /sys/fs/cgroup
none 5120 0 5120 0% /run/lock
none 4063152 29016 4034136 1% /run/shm
none 102400 68 102332 1% /run/user
/dev/sdc1 528112 191668 309616 39% /boot
/dev/sda1 1953521664 960410740 989882988 50% /home
/dev/mapper/COP01-ROOT 949389436 651391012 249749184 73% /mnt/linux
ó df -h
/dev/mapper/COP01-ROOT 906G 622G 239G 73% /mnt/linux
A partir de este punto es cuando el administrador fisico del sistema puede disponer de la información guardada bajo esa estructura para su respectivo aseguramiento.
Espero sea de su agrado, les guste y le sirva de soporte para alguien que tenga una situación similar. Hasta una pronta aparición.
No hay comentarios :
Publicar un comentario