Recuperación de datos VMware ESXi, vSphere y Hyper-V

VMFS (Virtual Machine File System) es el sistema de ficheros propietario de VMware para datastores en ESXi. Un corte eléctrico, fallo de la controladora RAID o error de firmware puede corromper las metadata de VMFS, dejando el datastore inaccesible. Los VMDK pueden estar intactos a nivel de bloques aunque VMFS no pueda listarlos.

La eliminación de un VMDK flat (el archivo de datos de la VM) desde el datastore browser o vía SSH no borra los datos inmediatamente: marca el espacio como libre en VMFS. Si no se ha escrito sobre ese espacio, la recuperación es viable analizando las estructuras internas de VMFS para localizar los extents del archivo borrado.

Los snapshots de VMware crean archivos delta (-delta.vmdk o -sesparse.vmdk) que registran los cambios desde el snapshot. Una consolidación fallida (merge del delta con el disco base) puede dejar la cadena de snapshots rota: el disco base y los deltas quedan inconsistentes. La VM no arranca y vCenter muestra «Needs consolidation» sin poder completarla.

El datastore aparece como «inactive» o «inaccessible» en vCenter/ESXi. Puede deberse a fallo del RAID subyacente, corrupción de la tabla de particiones GPT, pérdida de la LUN en la SAN (path failure) o corrupción de los metadatos VMFS-L (locking layer). Los datos de las VMs siguen en los discos físicos.

ESXi almacena su boot image en una partición pequeña (USB, SD o disco local). Si ESXi no arranca (Purple Screen of Death, corrupción del bootbank), los datastores VMFS en los discos de datos permanecen intactos. Reinstalar ESXi en un medio nuevo y volver a presentar los datastores suele restaurar el acceso, pero requiere precaución para no reformatear.

vSAN distribuye los objetos de las VMs entre disk groups de múltiples hosts. El fallo de un disk group (disco de cache SSD dañado, disco de capacidad fallido) puede dejar objetos «absent» o «degraded». Si la política FTT (Failures to Tolerate) se supera, la VM queda inaccesible. La reconstrucción requiere acceso directo a los discos de cada host.

Los discos VHDX de Hyper-V pueden corromperse por corte eléctrico durante operaciones de escritura, fallo del CSV (Cluster Shared Volumes) en un clúster, o error durante un checkpoint (snapshot Hyper-V). La VM no arranca y muestra error al montar el VHDX. La reparación de la estructura VHDX y la extracción de los datos del filesystem interno (NTFS/ReFS) es factible.

Los grupos de ransomware (Royal, BlackCat, LockBit) atacan ESXi directamente via SSH o vulnerabilidades conocidas (CVE-2021-21974 OpenSLP). Cifran los VMDK de todas las VMs. La recuperación depende de si el cifrado se completó, si existen snapshots previos en el datastore y si el RAID subyacente tiene datos residuales.

Imagen bit a bit de cada disco del servidor (SAS, SATA, NVMe) con DeepSpar Disk Imager. Si el almacenamiento es una SAN, extraemos los discos de la cabina. Si es almacenamiento local, clonamos directamente. Nunca trabajamos sobre los discos originales.

Si el servidor usa RAID hardware o software, reconstruimos el array virtualmente sobre las imágenes clonadas. Determinamos la geometría (stripe size, paridad, orden) a partir de las metadata de la controladora o del análisis de patrones.

Montaje del volumen VMFS (ESXi), NTFS/ReFS/CSV (Hyper-V) o ZFS/LVM (Proxmox) sobre el array reconstruido. Localización de los archivos VMDK/VHDX/QCOW2 y verificación de integridad de la cadena de snapshots si aplica.

Montaje del VMDK/VHDX como disco virtual para acceder al filesystem interno de la VM (NTFS, EXT4, XFS). Extracción de archivos, bases de datos, configuraciones. Si la VM no es montable, realizamos carving a nivel de bloques dentro del disco virtual.

Datos entregados en disco externo o, si se requiere, como VMDK/VHDX funcional listo para importar en un nuevo hipervisor. Informe técnico detallado con checksums. Solo pagas si recuperamos tus datos.