Recuperar datos de máquinas virtuales VMware y VirtualBox dañadas
La virtualización ha transformado los centros de datos: donde antes había decenas de servidores físicos, ahora hay un puñado de hipervisores ejecutando cientos de máquinas virtuales. Esta concentración es eficiente pero introduce un nuevo riesgo: cuando el almacenamiento físico del anfitrión falla, puede llevarse consigo todas las VMs que aloja. Y cuando los ficheros de disco virtual se corrompen — VMDK, VDI, VHD, VHDX — recuperar los datos requiere entender la arquitectura interna de cada formato. Este artículo cubre los escenarios más frecuentes en VMware, VirtualBox, ESXi e Hyper-V.
Formatos de disco virtual: qué contienen y cómo se corrompen
| Hipervisor | Formato | Estructura | Riesgo principal |
|---|---|---|---|
| VMware Workstation/Fusion | VMDK | Descriptor + flat (o monolítico) | Descriptor desincronizado |
| VMware ESXi | VMDK en datastore VMFS | VMFS filesystem + VMDK | VMFS journal corrupto |
| VirtualBox | VDI, VMDK, VHD | Header + mapa de bloques + datos | Header corrupto |
| Hyper-V legacy | VHD | Header + BAT + datos | BAT (Block Allocation Table) corrupta |
| Hyper-V moderno | VHDX | Header con checksum CRC32 + metadata + datos | Metadata region corrupta |
VMware VMDK: descriptor y fichero flat
Un VMDK de VMware Workstation consta de dos ficheros: el descriptor (vm.vmdk) y el fichero de datos (vm-flat.vmdk). El descriptor es un fichero de texto con metadatos: número de cilindros, cabezas, sectores, tipo de adaptador, UUID y la ruta al fichero flat. Si el descriptor se corrompe o desincroniza del flat, VMware rechaza montar el disco.
Reconstrucción del descriptor VMDK
Si el fichero flat está intacto y solo el descriptor está corrupto, se puede reconstruir manualmente. El tamaño del flat en bytes dividido por 512 da el número de sectores. Con eso y la documentación del formato VMDK se puede crear un descriptor válido. VMware también incluye la herramienta vmware-vdiskmanager que puede reparar y convertir VMDKs.
VMDK monolítico vs. dividido en 2GB
Los VMDKs pueden almacenarse como un único fichero monolítico o divididos en trozos de 2GB (herencia de limitaciones FAT32). Los VMDKs divididos tienen un fichero descriptor que referencia todos los fragmentos secuencialmente. Si uno de los fragmentos se elimina o corrompe, la VM entera deja de arrancar aunque el resto del disco esté intacto.
Cadena de snapshots: el riesgo más subestimado
Los snapshots de VMware crean ficheros VMDK delta (vm-000001.vmdk, vm-000002.vmdk...) que almacenan solo los cambios respecto al disco base. El fichero .vmsd describe la cadena y .vmsn almacena el estado de memoria. Una cadena de snapshots larga — 10, 20, 50 snapshots — es un riesgo significativo: si cualquier eslabón de la cadena se corrompe, todos los datos escritos después de ese snapshot son inaccesibles.
Consolidación de snapshots fallida
VMware vCenter puede intentar consolidar (merge) la cadena de snapshots automáticamente. Si este proceso se interrumpe por fallo de almacenamiento o de red, puede dejar la cadena en estado inconsistente: el descriptor apunta a un delta a medio crear. Síntoma: la VM aparece en vCenter con el aviso "Virtual machine disks consolidation is needed" y no puede iniciarse.
La recuperación manual requiere analizar el fichero .vmsd para reconstruir la cadena de herencia, identificar qué deltas están completos y cuáles están truncados, y extraer los datos usando herramientas de lectura directa de VMDK.
ESXi datastore: VMFS y fallos de almacenamiento
En un entorno ESXi, los VMDKs residen en un datastore VMFS (VMware Virtual Machine File System). VMFS es un sistema de archivos en clúster con locking distribuido para que múltiples hipervisores puedan acceder simultáneamente al mismo LUN SAN. Cuando el almacenamiento subyacente — disco local, iSCSI, Fibre Channel — falla, el datastore VMFS puede quedar ilegible.
Recuperación de datastore VMFS
Las herramientas de recuperación de VMFS (como vSphere Data Recovery o herramientas de terceros como UFS Explorer, R-Studio) pueden escanear el LUN subyacente y reconstruir el directorio VMFS aunque el journal esté corrupto. Si el dispositivo de bloque subyacente ha sufrido daño físico, primero se clona con ddrescue y luego se trabaja sobre la imagen.
VirtualBox: VDI y recuperación
VirtualBox usa su formato nativo VDI, aunque también soporta VMDK y VHD. El VDI tiene un header con UUID, tamaño del disco, tamaño de bloque, número de bloques y un mapa de bloques que indica qué bloques del disco virtual están almacenados en qué offset del fichero. Si el header se corrompe, VirtualBox no puede determinar ni el tamaño del disco.
Reparación de VDI con cabecera corrupta
El comando VBoxManage internalcommands repairhd --filename disco.vdi intenta reparar el header de un VDI dañado. Si falla, se puede reconstruir el header manualmente: el magic number de VDI es 7F10DABE a offset 0x40; la geometría del disco puede inferirse del tamaño del fichero. Con header reconstruido, las herramientas de recuperación de sistemas de archivos (dependiendo del SO huésped: ntfsundelete, extundelete, etc.) pueden extraer los datos.
Hyper-V: VHD y VHDX
VHD es el formato legacy de Hyper-V y Virtual PC. Tiene una footer al final del fichero (512 bytes) con el tipo de disco (fixed/dynamic/differencing), UUID y tamaño. Los VHD dinámicos tienen además una Block Allocation Table (BAT) al inicio. Si la BAT se corrompe, Hyper-V no puede mapear qué sectores virtuales están en qué posición física.
VHDX (introducido en Windows Server 2012) mejora la resiliencia con checksums CRC32 en el header y la metadata region. Soporta hasta 64TB (VHD máximo 2TB) y tiene mejor tolerancia a fallos de energía. En VHDX, las corruption metadata se detectan con el checksum, aunque no se auto-reparan; se necesita la herramienta Repair-VHD de PowerShell o herramientas de terceros.
El disco anfitrión falla llevándose las VMs
El escenario más crítico: el disco físico del servidor anfitrión falla. No hay RAID, no hay backup reciente. Las VMs — que eran ficheros en ese disco — están inaccesibles. La recuperación tiene dos capas:
- Capa física: recuperar el disco del anfitrión. Si tiene daño físico, trabajo de laboratorio. Si es corrupción lógica (NTFS del anfitrión dañado, ext4 corrupto), recuperación lógica del sistema de archivos del host.
- Capa de VM: una vez extraídos los ficheros VMDK/VDI/VHDX, analizarlos con las técnicas descritas para extraer los ficheros del sistema operativo huésped.
Esta doble capa es lo que hace que la recuperación de VMs sea más cara que la recuperación de un disco convencional: hay que recuperar primero el contenedor y luego el contenido.
Extracción de ficheros de VMs corruptas
Cuando el disco virtual está parcialmente accesible pero la VM no arranca, se pueden montar los ficheros con herramientas especializadas:
- 7-Zip: puede abrir VHD y VDI directamente como archivos comprimidos en algunas versiones.
- OSFMount / ImDisk (Windows): montan imágenes de disco como unidades virtuales para acceso directo.
- qemu-nbd: en Linux, expone VDI, VMDK, QCOW2 y VHDX como dispositivos de bloque
/dev/nbd0. - VMware Disk Mount Utility: monta VMDKs en sistemas Windows como unidades de red.
Precios de recuperación de máquinas virtuales
| Escenario | Complejidad | Precio orientativo |
|---|---|---|
| VMDK con descriptor corrupto, flat intacto | Baja | 200 – 350 € |
| VDI con header corrupto, datos accesibles | Media | 250 – 400 € |
| Cadena de snapshots VMware con eslabón roto | Alta | 400 – 800 € |
| VHDX corrupto en Hyper-V, disco anfitrión sano | Media | 300 – 550 € |
| Datastore ESXi ilegible, iSCSI dañado | Alta | 600 – 1.200 € |
| Disco anfitrión físico + VMs encima | Muy alta | 700 – 1.500 € |
Recomendaciones de prevención
- No acumular snapshots: más de 3 snapshots activos es una práctica de riesgo. Las cadenas largas degradan el rendimiento y aumentan el riesgo de corrupción en la consolidación.
- Backup a nivel de imagen: herramientas como Veeam, Nakivo o Acronis Cyber Backup hacen backup de las VMs completas sin necesidad de agentes en el guest.
- Almacenamiento redundante para el anfitrión: el disco del servidor ESXi o Hyper-V debería estar en RAID1 o RAID10 mínimo. Un único disco SSD para alojar 10 VMs de producción es una bomba de relojím.
Si tu máquina virtual no arranca y los datos que contiene son críticos, no intentes reconectar el disco, reinstalar el hipervisor ni recrear la VM — estas acciones pueden sobreescribir los datos recuperables. Solicitar diagnóstico gratuito para que un técnico especialista evalúe el estado de tus ficheros de disco virtual.
WhatsApp