La Multi-Partición

Autor: carla

Esta semana nos enfrentamos a un interesante desafío, que requirió un pensamiento fuera de la caja, dejar de lado el pensamiento más tradicional e investigar para encontrar esa divergencia que hace de este caso, un caso muy particular. Se trata un RAID 5 conformado por 8 discos duros (o al menos eso pensábamos) a Kepler.

El RAID consistía en 8 disco SCSI, 6 de 1 TB y 2 de 2TB, el cliente había mandado imágenes que había tomado a la BIOS de la controladora que armaba el RAID por lo que supimos que se trataba de un RAID 5 y que además había otro RAID de 2 discos usado para el sistema operativo, que en este caso era un VMware ESXI. Conociendo el sistema operativo usado, era claro que el cliente requería recuperar alguna máquina virtual.

En la etapa de diagnostico se detecto que 1 de los discos SCSI de 1 TB tenía daño físico y que otro de los discos andaba extremadamente lento.

Cuando el cliente autorizo la recuperación de la información se procedió a hacer imagen al disco que funcionaba lento ya que usarlo como estaba haría imposible la extracción de información posterior. Se logró una imagen fidedigna del disco dañado, pero lamentablemente este proceso tomo casi todo el tiempo que teníamos destinado a reparar el raid completo por lo que se extremaron los esfuerzos para terminar rápidamente el caso dándole un carácter de Urgente.

Usando una MFT interna de una de las máquinas virtuales se logró dar con los parámetros de armado del RAID.  Usando los parámetros encontrados, más la imagen creada y dejando fuera el disco con daño físico se armó el RAID 5 de 8 discos.

Para sorpresa nuestra, la estructura encontrada no correspondía a una partición VMFS que normalmente encontraríamos cuando usan servidores con VMware ESXI sino que era una estructura de Linux LVM2 con muchas particiones.

Existía solo 1 partición activa conformada por 2 de las 8 particiones encontradas, pero su estructura interna no correspondía a ninguna partición estándar de Linux.  Normalmente encontraríamos archivos de máquinas virtuales directamente, pero en este caso a la máquina virtual le asignaron un disco físico representado por la partición activa encontrada por lo que se procedió a extraer la partición activa directamente a un archivo logrando de esta forma recuperar el archivo .VMDK que en los sistemas de maquinas virtuales representa el disco duro de esta.

Logramos extraer más de 1TB de información y se la presentamos a nuestro cliente el cual indicó que era la información buscada, pero existía otro problema. Faltaba una carpeta crítica que estaba en otra unidad, en un disco virtual aparte, que estaba anclado a la máquina virtual principal. Claro que había otras particiones en el RAID que podrían ser el disco virtual perdido, pero como mencioné anteriormente, sólo había una partición activa y ya la habíamos extraído.

En esta situación llegamos a un punto en que todo lo que conocíamos nos decía que había algún tipo de corrupción en el arreglo que impedía que encontráramos la segunda partición activa.

No nos dimos por vencidos y nos lanzamos a investigar el funcionamiento interno de los sistemas LVM2.  Montamos un laboratorio con maquinas virtuales y creamos particiones LVM2 con el fin de comprender su funcionamiento y de cómo el sistema operativo iba interpretando sus estructuras.   Con la investigación realizada supimos que debíamos encontrar la estructura de metadatos del LVM2 he interpretarla manualmente para saber como estaba armada la partición faltante.

Efectivamente al encontrar los metadatos del LVM2 del RAID hacía referencia a 2 particiones activas, la que habíamos encontrado conformada por 2 de las particiones del raid y otra partición conformada por 6 bloques o particiones y 5 de estos bloques estaban en una unidad distinta al RAID. ¡EUREKA! ¿Qué pasó entonces?  De alguna forma cuando se creo la partición que anexarían a la maquina virtual principal se usó “por casualidad” espacio del otro raid destinado al sistema operativo.

Con este nuevo descubrimiento se solicitó al cliente que mandara los discos correspondientes al sistema operativo de la maquina y cuando los obtuvimos pudimos armar manualmente la partición activa faltante encontrado de esta forma las carpetas perdidas y mas de 2TB extra de información.

Todo terminó bien, la dedicación de los ingenieros, insistencia, curiosidad y su experiencia, permitió una vez más, poder entregar los datos perdidos a un cliente que gratamente nos comentó: “Gracias Kepler, por darme una segunda oportunidad con mis datos”.