Caso de estudio: cómo se recuperaron los datos de un entorno VMware ESXi cuando el problema no estaba solo en los discos, sino también en las snapshots SEsparse.
Un fallo de almacenamiento puede complicarse mucho más cuando afecta a un entorno virtualizado. En este caso, un servidor VMware ESXi con seis máquinas virtuales en producción sufrió el fallo de dos discos SAS de un RAID 5. La recuperación exigió reconstruir el almacenamiento y, después, resolver un problema lógico relacionado con snapshots SEsparse que llevaban más de seis meses sin consolidarse.
El caso muestra por qué, en determinadas recuperaciones, conseguir que los discos vuelvan a ser legibles no significa que el trabajo haya terminado.
Un RAID 5 que empezó a fallar
El servidor afectado alojaba seis máquinas virtuales destinadas a gestión, contabilidad, seguros, ficheros, acceso remoto y backup. El almacenamiento estaba configurado en RAID 5 sobre tres discos SAS.
El incidente comenzó a las 8:30, cuando el disco 2 apareció en estado Warning. El sistema continuó funcionando durante varias horas, aunque con una lentitud extrema.
A las 15:00 se sustituyó el disco y se inició el rebuild del RAID.
Menos de una hora después, a las 15:59, se registró la última escritura en el almacenamiento. A las 18:30, el disco 1 terminó fallando y el RAID dejó de estar operativo.
Los registros de las máquinas virtuales mostraban además varios apagados y reinicios inesperados durante esa mañana. La lentitud del servidor no era, por tanto, un simple problema de rendimiento. Era una señal de que el almacenamiento ya estaba deteriorándose.
El riesgo de reconstruir un RAID degradado
Un rebuild obliga a realizar una lectura completa y sostenida de los discos que permanecen en el array. Si alguno de ellos tiene problemas físicos, esta operación puede provocar su fallo.
Eso fue lo que sucedió en este caso.
Dos de los tres discos SAS terminaron presentando fallo de cabezales. Un RAID 5 puede continuar funcionando ante el fallo de un miembro, pero no ante la pérdida de dos.
Por este motivo, cuando un RAID empieza a responder con una lentitud anormal, continuar trabajando sobre él o iniciar una reconstrucción puede comprometer la recuperación posterior.
La actuación más segura habría sido detener el servidor y realizar primero una imagen de cada disco por separado.
Primera fase: recuperar el RAID
La recuperación comenzó con los dos discos que presentaban fallo de cabezales.
Tras la intervención física y la obtención de las imágenes de los miembros del RAID, Serman consiguió cuatro imágenes completas de 900 GB.
Con ellas se reconstruyó la geometría del RAID y se extrajo el volumen VMFS que contenía las máquinas virtuales. Los datos estaban ahí, pero todavía no era posible arrancar correctamente todas las máquinas.
El segundo problema apareció en VMware
Al intentar abrir una de las máquinas virtuales en VMware Workstation apareció el mensaje:
The file specified is not a virtual disk
El análisis de los descriptores de los VMDK permitió identificar la causa: las máquinas tenían snapshots sin consolidar en formato SEsparse.
El formato SEsparse es utilizado por ESXi en determinados entornos VMFS6. El problema no era necesariamente que los archivos estuvieran corruptos. El software utilizado para abrirlos no podía interpretar correctamente ese tipo de extent.
La diferencia era importante porque las snapshots contenían información que no estaba en los discos base.
Más de 130 GB de actividad estaban en los snapshots
Las snapshots se habían creado el 1 de febrero y nunca se habían consolidado.
Durante aproximadamente seis meses y medio, las máquinas habían seguido trabajando y las nuevas escrituras se habían ido almacenando en esos deltas.
Entre las tres máquinas afectadas había más de 130 GB de actividad que no estaba contenida en los discos base. En una de ellas, la información posterior a febrero suponía 103 GB de actividad que no podía recuperarse simplemente abriendo el disco base.
Por tanto, recuperar únicamente los discos base habría significado recuperar un estado anterior de las máquinas. Había que reconstruir las cadenas completas de snapshots.
El problema del journal SEsparse
El siguiente intento fue utilizar qemu-img, que incorpora soporte de lectura para SEsparse, pero los snapshots activos en el momento del fallo aparecían como dirty:
Image is dirty, Replaying journal not supported
Cada capa SEsparse mantiene un journal de transacciones. Cuando una máquina se apaga correctamente, ese journal queda cerrado. En este caso, una de las máquinas había sufrido un apagado inesperado durante el incidente y el journal había quedado abierto.
QEMU podía leer el formato SEsparse, pero no podía reproducir las transacciones pendientes. Había que utilizar otra vía.
La solución: utilizar ESXi para recuperar los snapshots
La solución pasó por utilizar el propio entorno ESXi. Serman desplegó un host ESXi 7.0.3 dedicado exclusivamente a la conversión, con los datastores originales montados mediante NFS. Las herramientas de ESXi permitieron abrir los extents y reproducir el journal antes de validar la consistencia de las capas.
El análisis encontró 67 transacciones pendientes, que fueron aplicadas durante el proceso.
Una vez completado el replay, la cadena volvió a ser consistente y legible. A continuación, las cadenas se aplanaron, integrando el disco base y sus deltas en discos planos que podían abrirse sin depender de los snapshots originales.
No todos los archivos pertenecían a la cadena activa
Durante la recuperación apareció otro problema, algunas máquinas contenían capas de snapshots huérfanas.
Los nombres de los archivos podían sugerir una secuencia, pero los CID de los descriptores demostraban qué capas estaban realmente relacionadas.
En una de las máquinas, por ejemplo, la cadena activa saltaba de una capa a otra y dejaba una capa intermedia sin referencia. Convertir todos los archivos siguiendo simplemente su nombre habría podido introducir información que no correspondía al estado real de la máquina virtual. Por eso, antes de convertir los snapshots fue necesario reconstruir las cadenas a partir de sus relaciones reales.
También hay que comprobar qué datos existían realmente
Durante el análisis apareció un disco de 500 GB que parecía no tener particiones ni contenido. Antes de considerarlo como una pérdida de datos, se verificaron los ficheros originales y diferentes zonas del disco.
El análisis mostró únicamente 4,4 KB de actividad sobre 500 GB. El disco había sido inicializado, pero no utilizado. La conclusión fue que no había datos que recuperar. Esta comprobación evitó atribuir a la recuperación una pérdida que en realidad no existía.
El resultado
Las tres máquinas virtuales que tenían snapshots pendientes fueron entregadas con el estado correspondiente al día del incidente, incluyendo los datos generados desde febrero. Las otras tres máquinas, que no tenían snapshots pendientes, pudieron arrancar directamente a partir de los ficheros recuperados.
El caso requirió trabajar en dos niveles diferentes, primero sobre los discos físicos y la estructura RAID y, posteriormente, sobre VMFS, VMDK y snapshots SEsparse.
Qué puede aprender un administrador de sistemas de este caso
Un RAID lento merece atención inmediata
La lentitud extrema puede ser un síntoma de problemas físicos en los discos. Antes de iniciar un rebuild, conviene comprobar el estado de los miembros del array.
Una snapshot no sustituye a un backup
En este caso, seis meses y medio de actividad habían quedado almacenados en snapshots sin consolidar. Una política de snapshots prolongadas puede complicar una recuperación cuando se combina con un fallo de almacenamiento.
El diagnóstico no termina cuando aparecen los archivos
En un entorno VMware, recuperar los VMDK no garantiza que las máquinas puedan arrancar ni que contengan toda la información generada antes del incidente.
Hay que comprobar las cadenas de snapshots, sus dependencias y su estado.