Recuperación de Datos de Máquinas Virtuales Hyper-V y Azure

Cuando una máquina virtual Hyper-V o Azure pierde sus datos, el impacto afecta a todos los sistemas que dependen de ella. Recuperamos archivos VHD y VHDX corruptos, resolvemos cadenas de snapshots rotas, restauramos Cluster Shared Volumes y recuperamos discos de Azure aunque el portal muestre el VM como irrecuperable. Evaluación gratuita sin compromiso.

Arquitectura de Hyper-V: qué hay dentro de un archivo VHD/VHDX

Entender por qué fallan las máquinas virtuales de Hyper-V empieza por comprender su estructura de almacenamiento. Microsoft utiliza dos formatos de disco virtual:

• VHD (Virtual Hard Disk): formato original, límite de 2 TB, estructura más sencilla. Se usa en entornos legacy y en algunas exportaciones de Azure clásico.
• VHDX: introducido en Windows Server 2012, soporta hasta 64 TB, bloques de 1 MB en lugar de 512 KB, mayor resistencia a la corrupción por fallos de corriente gracias al registro de metadatos. Es el formato estándar actual.

Un archivo VHDX es, en esencia, un contenedor con su propia tabla de bloques, un bitmap de estado de sector y metadatos de identidad. Cuando el hipervisor escribe en el disco virtual, actualiza primero el registro de metadatos (similar al journaling de NTFS), lo que proporciona cierta protección. Sin embargo, cuando el fallo ocurre durante esa ventana de escritura del metadato, o cuando el archivo host sufre corrupción, el VHDX puede quedar ilegible aunque físicamente esté intacto.

Modos de fallo más frecuentes en Hyper-V

1. Corrupción del archivo VHD/VHDX

Los síntomas más habituales son: Hyper-V Manager reporta el VM en estado “Critical” o “Saved” atascado, el archivo no monta como disco virtual, o la importación devuelve error 0x80070057 (parámetro incorrecto). Las causas incluyen:

• Fallo de alimentación durante escritura activa del guest OS
• Almacenamiento subyacente con sectores defectuosos en las zonas de cabecera del VHDX
• SMB share desconectado mientras el VM estaba encendido (Hyper-V sobre almacenamiento de red)
• Antivirus que intercepta y bloquea parcialmente el archivo .vhdx en producción
• Operaciones de compactación o conversión VHD a VHDX interrumpidas

En laboratorio, tratamos el archivo VHDX como un sistema de archivos dentro de otro sistema de archivos. Primero recuperamos o reconstruimos la cabecera del contenedor, luego accedemos al sistema de archivos del guest (NTFS, ReFS, ext4) y extraemos los datos con herramientas de recuperación a nivel de bloque.

2. Cadenas de snapshots rotas (.avhd / .avhdx)

Los snapshots de Hyper-V crean archivos de diferenciación: .avhd en VHD y .avhdx en VHDX. Cada snapshot almacena únicamente los bloques modificados respecto al padre, formando una cadena. Un VM con varios años de snapshots puede tener una cadena de 8 a 12 archivos donde cada eslabón depende del anterior.

Los problemas más graves surgen cuando:

• Se elimina o mueve un archivo intermedio de la cadena
• La operación de aplicar snapshot queda incompleta por un fallo de alimentación
• El merge automático de snapshots falla durante el apagado del host
• Los archivos .avhdx quedan huérfanos tras migración de almacenamiento a otro servidor

La recuperación implica reconstruir manualmente el árbol de dependencias, identificar qué bloques de cada snapshot son “activos” (no sobreescritos por hijos posteriores) y ensamblar la imagen coherente. Este proceso requiere análisis bloque a bloque de cada archivo de diferenciación en orden cronológico.

3. Fallo de Cluster Shared Volumes (CSV)

En clústeres Hyper-V de alta disponibilidad, los discos virtuales residen en Cluster Shared Volumes (CSV), que permiten que múltiples nodos accedan simultáneamente al mismo almacenamiento. Cuando un CSV falla, las consecuencias son más graves: todos los VMs alojados en ese volumen quedan inaccesibles simultáneamente.

Los escenarios de fallo incluyen pérdida del quórum del clúster, corrupción del sistema de archivos ReFS o NTFS del volumen compartido, fallo de la LUN subyacente en el SAN, y errores en la capa iSCSI o Fibre Channel. La recuperación de CSV requiere acceder al almacenamiento físico subyacente independientemente de la capa de clúster Windows, analizando directamente las estructuras del sistema de archivos en los discos.

Recuperación de datos en Azure: discos administrados y no administrados

Azure presenta retos adicionales respecto a Hyper-V on-premise: el acceso físico al hardware es imposible, y muchos fallos se manifiestan como VM en estado detenido que no arranca, o disco de datos que aparece como “Unattached” sin datos accesibles.

Discos administrados (Managed Disks)

Los discos administrados de Azure son blobs de página almacenados en Azure Storage. Cuando un disco administrado sufre corrupción del sistema de archivos del guest (NTFS corrupto, tabla de particiones dañada), el propio blob puede estar intacto pero el sistema operativo del VM no puede montarlo. El proceso de recuperación consiste en:

1. Adjuntar el disco afectado como disco de datos a una VM de rescate en Azure
2. Ejecutar herramientas de diagnóstico y recuperación de sistema de archivos sobre el volumen montado
3. Si el sistema de archivos está irreparable, extraer los datos a nivel de bloque antes de cualquier reparación destructiva
4. Descargar imagen del blob para análisis en laboratorio en casos de corrupción grave

Snapshots de Azure y Recovery Services Vault

Azure Backup y los snapshots nativos de disco son la primera línea de defensa, pero tienen limitaciones: el snapshot más reciente puede ser de hace 24 horas o más, y si la corrupción fue gradual puede haberse propagado a todos los puntos de restauración disponibles. En estos casos, la recuperación forense de los datos desde el disco original es la única opción viable.

Storage Spaces Direct (S2D): el escenario más complejo

Storage Spaces Direct es la solución de almacenamiento hiperconvergido de Microsoft, utilizada en Azure Stack HCI y Windows Server 2019/2022. S2D crea pools de almacenamiento redundante combinando discos locales de múltiples nodos del clúster, con capas de caché NVMe o SSD sobre capacidad en HDD.

El fallo de S2D puede ser catastrófico en varias formas:

• Pérdida de nodo completo: si se pierden datos suficientes para romper la resiliencia configurada (espejo de 3 vías, paridad doble), el pool puede quedar en estado degradado con datos parcialmente inaccesibles.
• Corrupción de metadatos del pool: la base de datos de configuración de S2D, almacenada en el disco de quórum y replicada en los nodos, puede corromperse impidiendo el montaje del pool.
• Fallo simultáneo de múltiples discos de caché NVMe: los datos en caché no escritos aún en los discos de capacidad se pierden permanentemente si todos los discos de caché fallan a la vez.

La recuperación de S2D requiere análisis de los discos físicos de todos los nodos supervivientes, reconstrucción manual del esquema de distribución de datos (similar a RAID pero con geometría variable definida por el pool), y extracción de los datos directamente de las capas del pool sin depender de la capa de abstracción de Windows.

System Center Virtual Machine Manager: corrupción de base de datos

System Center Virtual Machine Manager (SCVMM) utiliza SQL Server como base de datos de gestión. Si dicha base de datos se corrompe, el entorno completo de gestión queda inoperativo: no se pueden crear, mover ni administrar VMs aunque los hipervisores físicos estén funcionando con normalidad. La recuperación implica restauración de la base de datos SQL Server desde backup o reparación a nivel de página cuando los backups son insuficientes, combinada con reconfiguración del servicio VMM y reconexión de los agentes en los hosts.

Hyper-V vs VMware: diferencias en recuperación

En laboratorio, la recuperación de Hyper-V suele ser algo más predecible que VMware gracias al formato estructurado del VHDX con su registro de metadatos, pero las cadenas de snapshots largas añaden complejidad comparable. Los entornos S2D son los más complejos de cualquier plataforma de virtualización.

Proceso de recuperación en nuestro laboratorio

1. Evaluación inicial gratuita: analizamos el archivo VHD/VHDX o imagen del disco, identificamos el tipo de fallo y estimamos la viabilidad de recuperación antes de comprometerte a ningún gasto.
2. Clonado bit a bit: si el almacenamiento físico tiene sectores defectuosos, clonamos antes de cualquier operación. Nunca trabajamos sobre los originales.
3. Reconstrucción del contenedor: reparamos la cabecera VHDX, reconstruimos la tabla de bloques y el bitmap de estado de sector para que el contenedor sea accesible.
4. Ensamblado de cadena de snapshots: si hay cadena .avhdx, la reconstruimos en orden cronológico, identificando bloques activos en cada nivel de diferenciación.
5. Extracción del sistema de archivos guest: accedemos al NTFS, ReFS o ext4 interior y recuperamos los datos con herramientas de carving y reconstrucción de MFT.
6. Entrega verificada: los datos recuperados se entregan en nuevo medio de almacenamiento, con listado completo de archivos y verificación de integridad.

Cuándo llamar antes de intentar repararlo

La regla de oro en entornos virtualizados es clara: no ejecutes chkdsk ni fsck dentro del VM si sospechas corrupción del contenedor VHDX. Estas herramientas pueden reparar el sistema de archivos guest sobreescribiendo precisamente los bloques que necesitamos para reconstruir los datos perdidos. Llámanos antes de cualquier operación de reparación si:

• El VM no arranca y los datos son críticos para el negocio
• Falta algún archivo .avhdx de la cadena de snapshots
• El CSV del clúster está en modo de redirección de E/S permanente
• El pool de Storage Spaces Direct está degradado o en modo de reparación
• La base de datos de SCVMM no arranca o está reportando errores de integridad

Te puede interesar

• › Recuperación de Datos de Máquinas Virtuales VMware y Hyper-V
• › Recuperar datos de máquina virtual VMware, VirtualBox e Hyper-V [2026]
• › Recuperación de datos para empresas: servidores, RAID y SAN/NAS
• › Recuperación de Datos de Máquinas Virtuales VMware ESXi y vSphere