Recuperar datos de máquina virtual VMware, VirtualBox e Hyper-V [2026]

Cuando una máquina virtual deja de arrancar o un fichero VMDK, VDI o VHDX aparece como corrupto, los datos que contenía siguen presentes en el disco virtual en la gran mayoría de los casos. La clave es identificar si el problema es lógico —corrupción del metadato del disco virtual o del sistema de ficheros interno— o si el fallo reside en el disco físico anfitrión que aloja esos ficheros. Esta guía explica las causas, las herramientas de recuperación sin laboratorio disponibles para cada plataforma y cuándo es necesario escalar a un laboratorio profesional de recuperación de datos.

Qué son los discos virtuales y por qué se corrompen

Un disco virtual es un fichero —o conjunto de ficheros— almacenado en el sistema de ficheros del servidor anfitrión que emula el comportamiento de un disco físico para una máquina virtual. La VM lo ve como un disco real y escribe en él del mismo modo que lo haría en un HDD o SSD físico. Desde fuera, sin embargo, es simplemente un fichero de gran tamaño con una estructura interna propia definida por el hipervisor.

Esta doble naturaleza —disco para la VM, fichero para el anfitrión— introduce una serie de puntos de fallo únicos que no existen en los discos físicos convencionales:

• Snapshot inconsistente: Al crear un snapshot, el hipervisor congela el estado del disco base y redirige todas las escrituras a un fichero delta. Si la VM se apaga de forma brusca mientras el snapshot está activo, la cadena delta/base puede quedar en un estado inconsistente que impide montar el disco en el siguiente arranque.
• Disco anfitrión lleno: Si el volumen que almacena los ficheros VMDK, VDI o VHDX se queda sin espacio libre, las escrituras de la VM fallan a mitad de operación. El resultado es una corrupción del sistema de ficheros interno de la VM, idéntica en sus síntomas a un apagón de corriente en un sistema físico.
• Corrupción de VMFS: En entornos VMware ESXi, el sistema de ficheros del datastore (VMFS) puede corromperse por fallos de la SAN/NFS, problemas de multiruta o actualizaciones fallidas. Cuando VMFS no monta, ninguna de las VMs almacenadas en él es accesible, aunque los datos estén intactos en el nivel de bloque.
• Ransomware que cifra VMs: Variantes modernas como BlackCat/ALPHV incluyen módulos específicos para cifrar ficheros VMDK, VHDX y los datastores VMFS de ESXi directamente, maximizando el impacto en infraestructuras virtualizadas empresariales.
• Migración fallida (vMotion / Export): Una migración en vivo interrumpida, una exportación OVA/OVF incompleta o una conversión P2V fallida pueden dejar el fichero de disco virtual en un estado parcialmente escrito que el hipervisor no puede abrir.

Tipos de disco virtual: VMDK, VDI, VHD y VHDX

Cada plataforma de virtualización utiliza su propio formato de disco virtual, con estructura interna, herramientas de reparación y capacidades distintas.

VMDK — VMware ESXi y Workstation

VMDK (Virtual Machine Disk) es el formato propietario de VMware. Un disco VMDK puede estar compuesto por un único fichero monolítico o por múltiples fragmentos de 2 GB en discos en modo dividido. Adicionalmente, cada VMDK tiene asociado un fichero descriptor (-flat.vmdk para los datos, .vmdk para el descriptor) y, cuando hay snapshots activos, uno o varios ficheros delta (-delta.vmdk). En ESXi, los VMDKs residen dentro de un datastore VMFS o NFS, lo que añade una capa de sistema de ficheros adicional a la cadena de recuperación.

VDI — VirtualBox

VDI (Virtual Disk Image) es el formato nativo de Oracle VirtualBox. A diferencia del VMDK, el VDI es siempre un fichero único que contiene tanto el descriptor como los datos. Puede ser de tamaño fijo o de expansión dinámica. VirtualBox es ampliamente usado en entornos de desarrollo y laboratorio, donde los VDI contienen a menudo configuraciones, bases de datos de prueba o entornos completos cuya pérdida puede suponer días de trabajo.

VHD / VHDX — Hyper-V y Azure

VHD (Virtual Hard Disk) es el formato heredado de Microsoft, introducido con Virtual PC y Virtual Server. VHDX es su sucesor moderno, con soporte para discos de hasta 64 TB, mejor rendimiento y mayor resiliencia ante corrupción gracias a un diario de transacciones interno. Hyper-V en Windows Server y en Azure utiliza ambos formatos. Los VHDX son también el formato estándar para las imágenes de máquinas virtuales de Azure cuando se migran a on-premise.

Snapshots de VM: cadenas delta y su impacto en la recuperación

Un snapshot no es una copia de seguridad: es una fotografía del estado de la VM en un momento concreto, implementada como un fichero delta que almacena solo los cambios realizados desde que se tomó el snapshot. El disco base queda en modo lectura y todas las escrituras van al fichero delta.

Las cadenas de snapshots largas —con 5, 10 o más niveles de profundidad— son habituales en entornos donde los snapshots se usan para revertir cambios con facilidad pero nunca se consolidan. Cada nivel añade latencia de escritura y, más importante, un eslabón adicional en la cadena que, si se corrompe, hace inaccesible todo el árbol de snapshots por encima de él.

Cuando una VM con snapshots no arranca, el primer paso es determinar si el problema está en el disco base, en uno de los ficheros delta intermedios o en el fichero delta activo más reciente. La herramienta vmware-vdiskmanager (Workstation) o los procedimientos de consolidación manual de ESXi permiten inspeccionar la cadena, pero si algún fichero de la cadena tiene daño físico, la operación de consolidación puede fallar y agravar la pérdida.

Opciones de recuperación sin laboratorio

Cuando el disco anfitrión está sano y el problema es puramente lógico (corrupción del metadato del disco virtual o del sistema de ficheros interno de la VM), existen herramientas nativas que pueden resolver la situación sin necesidad de intervención profesional.

VMware: montar VMDK y vmware-vdiskmanager

En VMware Workstation, el proceso más directo es montar el VMDK como disco adicional en otra VM operativa para acceder a sus ficheros directamente. Si el problema es el sistema de ficheros interno (NTFS o ext4 de la VM), se puede aplicar chkdsk o fsck desde dentro de la VM de rescate.

Para reparar el propio VMDK, la herramienta oficial es vmware-vdiskmanager con los flags -R (reparar) y -e (extender/verificar la cadena). En ESXi, el equivalente es vmkfstools -x check para verificar la integridad del disco virtual y vmkfstools -e para expandirlo si las métricas de tamaño son inconsistentes.

VirtualBox: VBoxManage repairmedium

VirtualBox incluye el comando VBoxManage repairmedium disk <fichero.vdi>, que intenta reparar inconsistencias en el encabezado del VDI y en la tabla de asignación de bloques. También es posible convertir el VDI a formato RAW mediante VBoxManage convertfromraw para procesarlo con herramientas de recuperación de datos convencionales que operan sobre imágenes brutas.

Hyper-V: Repair-VHD PowerShell

En Hyper-V, el cmdlet PowerShell Repair-VHD -Path <fichero.vhdx> -All intenta reparar errores de consistencia en el VHDX. Para VHDs heredados, el proceso es equivalente. Si la VM tiene checkpoints (los snapshots de Hyper-V), es posible intentar la fusión mediante Merge-VHD. Como alternativa, montar el VHD/VHDX en Windows con la herramienta "Administración de discos" o Mount-VHD permite acceder a sus particiones internas directamente desde el explorador de archivos.

Herramientas de recuperación de ficheros sobre discos virtuales montados

Una vez montado el disco virtual (por cualquiera de los métodos anteriores), si el sistema de ficheros interno de la VM es accesible pero algunos directorios o ficheros aparecen como borrados o corruptos, es posible aplicar herramientas de recuperación de ficheros estándar directamente sobre la partición montada. El proceso es idéntico al de cualquier disco físico: las herramientas no distinguen si trabajan sobre hardware real o sobre un disco virtual montado.

Recuperación de VMFS: cuando el datastore de ESXi no monta

VMFS (VMware vSphere File System) es el sistema de ficheros en bloque de alto rendimiento que VMware ESXi utiliza para almacenar los ficheros VMDK, ISO, ficheros de configuración y logs de las VMs. Opera directamente sobre LUNs SAN (iSCSI, Fibre Channel) o sobre discos locales del hipervisor.

Cuando un datastore VMFS no monta tras un evento de fallo —corrupción del encabezado VMFS, pérdida de la tabla de particiones del LUN, fallo de la controladora RAID subyacente— todas las VMs que residían en él quedan inaccesibles simultáneamente. Los VMDKs siguen físicamente presentes en el disco, pero sin el sistema de ficheros VMFS operativo no hay forma de acceder a ellos a través de las herramientas nativas de ESXi.

La recuperación de VMFS se aborda en dos niveles:

1. Reparación del encabezado VMFS: Herramientas especializadas pueden reconstruir el encabezado y las estructuras de metadato de VMFS a partir de las copias de seguridad que el propio VMFS mantiene distribuidas en el volumen. Si el daño es solo en el encabezado primario, esta operación es frecuentemente exitosa.
2. Escaneo de bloques brutos: Si la reparación del encabezado no es posible, se puede realizar un escaneo forense de los bloques del LUN en busca de las estructuras VMFS y de los descriptores VMDK, reconstruyendo el índice del datastore de forma manual. Este proceso requiere equipamiento y software especializado y solo está al alcance de laboratorios con experiencia específica en recuperación de entornos VMware.

Cuándo se necesita un laboratorio profesional

Las herramientas nativas descritas anteriormente son eficaces cuando el problema es puramente lógico y el disco anfitrión está en buen estado. Hay tres escenarios en los que la intervención profesional es imprescindible:

• Disco anfitrión físicamente dañado con VMs: Si el HDD o SSD que aloja los ficheros VMDK, VDI o VHDX tiene fallo físico —cabezales averiados, controladora dañada, celdas NAND agotadas— cualquier intento de acceso directo puede agravar el daño. Es necesario primero recuperar los bloques del disco físico con equipamiento de sala limpia antes de abordar la capa de disco virtual.
• VMFS corrompido en ESXi: La corrupción del datastore VMFS que impide su montaje no es resoluble con las herramientas nativas de ESXi. Requiere software forense específico para la estructura interna de VMFS y conocimiento profundo del formato. Un intento de reparación incorrecto puede sobrescribir las estructuras de metadato restantes y hacer irrecuperable el contenido.
• Cadena de snapshots rota con fichero delta dañado: Cuando uno o más ficheros delta de la cadena de snapshots están corruptos o han sido borrados, la consolidación manual falla. La recuperación requiere reconstruir el árbol delta de forma controlada, extraer los datos del sistema de ficheros interno de la VM a través de las partes accesibles de la cadena y fusionarlos con el estado del disco base.

Proceso de recuperación en RecuperaTusDatos

Nuestro procedimiento para discos virtuales sigue la misma metodología forense que aplicamos a cualquier soporte de almacenamiento, adaptada a las particularidades de los formatos VMDK, VDI y VHDX:

1. Evaluación inicial: Análisis del disco anfitrión para determinar si existe daño físico. Si el disco tiene sectores inestables o síntomas de fallo mecánico/electrónico, realizamos primero una imagen forense antes de abordar la capa de disco virtual.
2. Diagnóstico de la capa virtual: Identificamos el formato, la versión, la presencia de snapshots, el estado del sistema de ficheros interno y la causa del fallo (corrupción de encabezado, cadena delta rota, VMFS dañado, cifrado de ransomware).
3. Extracción sin escritura sobre el original: Todo el trabajo se realiza sobre imágenes forenses del disco anfitrión, nunca sobre los ficheros originales. Esto garantiza que siempre existe una copia de trabajo sin modificar.
4. Reconstrucción de la estructura virtual: Reparamos o reconstruimos las estructuras de metadato del disco virtual (encabezado VMDK/VDI/VHDX, tabla de bloques, cadena de snapshots) hasta conseguir montar el volumen y acceder al sistema de ficheros interno de la VM.
5. Extracción de datos: Una vez montado el disco virtual, extraemos los ficheros y directorios solicitados a un soporte de almacenamiento nuevo entregado al cliente.
6. Verificación y entrega: Revisamos la integridad de los datos extraídos antes de la entrega. Si los datos no son recuperables, no se cobra nada por el trabajo de laboratorio.

Preguntas frecuentes sobre recuperación de datos de máquinas virtuales