Recuperación de datos en discos virtuales

La recuperación de datos en un disco virtual exige conservar el contenedor, sus discos padre, snapshots y archivos de configuración. Datastrophe analiza cada capa sin arrancar ni modificar la máquina afectada y valida los archivos prioritarios antes de preparar la entrega.

Solicitar cotización

Copia del datastore y del almacenamiento físico preservada junto con la cadena completa de la máquina virtual

Una máquina virtual caída exige conservar toda la cadena

El disco visible suele ser solo una pieza de la máquina virtual.

El primer diagnóstico identifica todos los archivos que participan en el estado perdido. Además del VMDK, VHDX o QCOW2, pueden ser necesarios descriptores, extents, deltas, snapshots, archivos padre, configuración del hipervisor y registros. Separar una pieza o renombrarla sin inventario puede romper relaciones que todavía eran recuperables.

Detener tareas automáticas de consolidación y respaldo
Conservar nombres, rutas, tamaños y fechas originales
Registrar el hipervisor y el almacenamiento de origen

El contenedor no equivale a sus archivos

Montar un disco virtual solo demuestra que una capa responde. Dentro pueden existir particiones dañadas, volúmenes cifrados, bases incoherentes o archivos que conservan nombre y tamaño sin contenido completo. La recuperación debe descender hasta el dato que usted necesita y comprobarlo en su formato real.

El inventario preserva la línea temporal

Las fechas de modificación, los identificadores de máquina y la ubicación de cada snapshot ayudan a ordenar la cadena. Conviene guardar también VMX, VMCX, XML, manifiestos OVF y bitácoras. Esa evidencia permite distinguir un archivo antiguo legítimo de una copia parcial creada después del incidente.

No copie únicamente el archivo de mayor tamaño: un descriptor pequeño o un delta reciente puede contener la referencia decisiva.

Versión reconstruida de una máquina virtual documentada con sus bloques faltantes y la capa donde apareció la falla

Los síntomas revelan en qué capa comenzó la falla

Un error de arranque no basta para culpar al archivo virtual.

La causa puede estar en el almacén, el hipervisor, el disco virtual o el sistema invitado. Una VM que desaparece del inventario, un datastore que no monta, un VHDX que solicita reparación y un Windows invitado que entra en bucle describen problemas distintos. La cronología evita aplicar una solución correcta en la capa equivocada.

El inventario debe distinguir si la VM faltó después de una migración, un snapshot fallido, un corte de energía o una expansión de almacenamiento. También se conservan los mensajes del host y la hora exacta de cada evento, con su zona horaria; en México pueden coexistir operaciones coordinadas desde husos distintos. Esta secuencia permite relacionar una alerta del datastore con la primera escritura fallida dentro del invitado, sin atribuir todo al sistema operativo virtual.

Anotar el mensaje exacto y la primera hora del incidente
Relacionar el error con migraciones, apagones o cambios recientes
Distinguir acceso intermitente de corrupción lógica estable

Señales frecuentes en VMware

Errores de CID, descriptores ausentes, grain tables dañadas o consolidaciones pendientes apuntan a la cadena VMDK. En VMFS también deben revisarse bloqueos, extents y el estado del datastore. Crear un descriptor nuevo por intuición puede asignar geometría o archivo padre incorrectos y desplazar todos los bloques.

Señales en Hyper-V, KVM y Proxmox

Un AVHDX huérfano, un registro VHDX incompleto o un backing file QCOW2 inexistente requieren reconstruir relaciones antes de montar. En clústeres, la VM puede depender además de LUN iSCSI, Ceph o almacenamiento compartido. La recuperación de servidores ayuda a valorar ese contexto completo.

Si el almacenamiento físico se desconecta o responde con lentitud, suspenda las lecturas repetidas antes de investigar la VM.

Cadena de snapshots con discos padre, deltas e identificadores ordenada para determinar la versión recuperable

Snapshots y discos padre determinan la versión recuperable

Cada delta representa cambios posteriores a un punto anterior de la máquina.

Una cadena incompleta puede abrir una versión antigua y ocultar los datos más recientes. El análisis ordena padres e hijos, compara identificadores y verifica que los límites de cada extent correspondan. No se da por válida una combinación solo porque el hipervisor la acepta: primero se comprueba qué fecha y qué bloques representa.

Relacionar cada delta con su padre declarado
Comparar capacidad virtual, tamaño físico y sector lógico
Conservar copias separadas de cada hipótesis

VMDK requiere coherencia entre descriptor y extents

El descriptor define tipo, capacidad, CID y orden de los extents; las tablas de granos indican dónde están los bloques. Si falta el descriptor, puede reconstruirse una hipótesis con evidencia del entorno, pero se valida contra particiones y sistemas de archivos. Una coincidencia de tamaño por sí sola no es suficiente.

VHDX y QCOW2 conservan metadatos propios

VHDX utiliza encabezados, regiones, BAT y registros; QCOW2 agrega clusters, refcounts y backing files. Reparar esos metadatos sobre el original modifica la evidencia. Datastrophe trabaja con copias y compara resultados para señalar con precisión qué versión es coherente y cuál contiene huecos.

Un snapshot borrado o sobrescrito puede imponer un límite permanente para los cambios que solo existían en ese archivo.

Máquina virtual que no inicia preservada sin consolidar snapshots ni modificar sus discos

Antes del diagnóstico, no consolide, monte ni arranque

Las acciones automáticas pueden escribir justo donde todavía existe evidencia útil.

Evite aceptar reparaciones, consolidar snapshots o iniciar la VM afectada. El sistema invitado puede actualizar bitácoras, paginación, índices y bases apenas arranca. El hipervisor también puede fusionar deltas o cambiar metadatos. Si necesita detener servicios, documente la acción y preserve el conjunto antes de cualquier prueba.

No ejecutar CHKDSK, fsck ni reparación de inicio
No importar la VM como si fuera una copia sana
No instalar herramientas dentro del sistema invitado

Una copia incompleta también modifica decisiones

Copiar archivos por explorador puede omitir sparse extents, enlaces o elementos bloqueados. Conviene registrar tamaño, hash cuando sea viable y cualquier error de lectura. El proceso de recuperación de datos separa preservación, diagnóstico y reconstrucción para evitar confundir una copia rápida con una adquisición controlada.

Las pruebas se realizan sobre duplicados

Cada intento de reparar un encabezado, enlazar un padre o montar un volumen se hace en una copia identificada. Así es posible regresar al estado inicial, comparar hipótesis y explicar por qué una ruta produjo más archivos válidos. El original queda fuera de las pruebas de arranque.

Una reparación que termina sin error no demuestra que haya conservado la versión de datos que usted buscaba.

Copia de un disco virtual montada en modo de solo lectura antes de iniciar o analizar el sistema invitado

La recuperación avanza del almacenamiento al sistema invitado

El orden técnico evita reconstruir una capa sobre bloques todavía inestables.

Primero se obtiene una lectura estable de los archivos fuente o de los medios que los contienen. Después se reconstruyen la cadena virtual, las particiones y el sistema de archivos invitado. Solo entonces se extraen documentos, bases o configuraciones. Saltar etapas puede producir una VM que monta, pero devuelve archivos corruptos.

Cuando la aplicación usa una base de datos, un servidor de archivos o un sistema contable, se preservan juntos disco de sistema, disco de datos, registros y configuración. Extraer solo el VMDK que parece más grande puede dejar fuera el journal o las claves necesarias. La reconstrucción comprueba primero la continuidad de la cadena y después abre una copia aislada, sin red productiva, para verificar páginas, adjuntos y transacciones prioritarias.

Adquirir los medios físicos con control de errores
Reconstruir almacén, contenedor y volumen por separado
Validar los datos prioritarios en la última capa

El almacén puede ser el verdadero origen

Si VMDK o VHDX estaban en un NAS, RAID o LUN, la lectura depende de ese conjunto. Orden de discos, paridad, thin provisioning y extents deben resolverse antes de confiar en el contenedor. Para esa capa, consulte la recuperación de RAID y NAS.

El sistema invitado exige su propio análisis

NTFS, ReFS, ext4, XFS, APFS y LVM conservan metadatos diferentes. La extracción combina directorios, registros y firmas cuando faltan referencias. Los archivos hallados se clasifican como íntegros, parciales o no verificables; no se reportan como recuperados solo porque aparezca su nombre.

El porcentaje de bloques leídos y el porcentaje de archivos útiles son medidas diferentes.

Metadatos propios de VMDK, VHDX y discos dinámicos examinados junto con cifrado y aprovisionamiento

Cifrado y aprovisionamiento fino fijan límites comprobables

Algunos bloques no están dañados: nunca estuvieron dentro del archivo recibido.

Un disco dinámico o sparse ocupa menos espacio físico que su capacidad declarada. Los bloques no asignados pueden leerse como ceros sin significar pérdida. En cambio, un extent faltante, una descarga truncada o un snapshot incompleto deja huecos reales. El mapa de asignación permite distinguir ambos escenarios antes de valorar los archivos.

Identificar thin, sparse, fixed o eager-zeroed
Conservar claves y metadatos de cifrado
Verificar si hubo exportación, descarga o copia parcial

Las credenciales forman parte del caso

BitLocker, LUKS, FileVault o cifrado de aplicación pueden requerir contraseña, archivo de recuperación, TPM virtual o configuración del hipervisor. Obtener todos los bloques no garantiza documentos legibles si falta ese material. Datastrophe no elude controles de acceso y trabaja únicamente con autorización y credenciales disponibles.

Las exportaciones pueden alterar la geometría

Una conversión entre VMDK, VHDX y QCOW2 puede cambiar bloques no asignados, sector lógico o cadena de respaldo. Si ya hubo una conversión, conserve también la fuente y anote la herramienta y opciones usadas. Comparar ambas versiones ayuda a separar el daño original de un error introducido durante la exportación.

Ni el diagnóstico ni una reparación pueden recrear bloques sobrescritos, ausentes o cifrados sin una clave legítima.

Bases y servicios de la máquina virtual comprobados por coherencia de aplicación, no solo por montaje

La validación debe probar archivos, bases y servicios prioritarios

Una VM que inicia puede seguir conteniendo datos incompletos o inconsistentes.

El resultado se mide contra el uso que usted necesita recuperar. Se revisan muestras de cada familia prioritaria, rutas, fechas y dependencias. Cuando hay una base o aplicación crítica, el contenedor se prueba en un entorno aislado o se extraen sus componentes para comprobar coherencia sin reactivar servicios sobre el original.

Abrir muestras representativas de cada formato crítico
Comprobar bases con herramientas no destructivas
Documentar huecos, duplicados y versiones alternativas

Las bases requieren más que un archivo presente

SQL Server, PostgreSQL, MySQL y otras plataformas dependen de páginas, registros y archivos relacionados. Una prueba puede revelar tablas accesibles y otras dañadas. Se informa ese alcance de forma concreta para que usted decida entre restaurar una base, exportar tablas o recuperar documentos independientes.

La entrega se adapta al objetivo

Según la evidencia, la entrega puede ser una VM reconstruida, un disco virtual estabilizado o una selección de datos extraídos. No se recomienda volver a producción con el contenedor afectado. Los resultados se copian a un medio sano y se acompañan con los límites que deben considerarse al migrarlos.

Montar el volumen o listar carpetas no equivale a validar una base transaccional.

Inventario de la máquina virtual, hipervisor y cadena de snapshots reunidos para la cotización

Una cotización útil necesita archivos técnicos y prioridades

La evaluación mejora cuando reconstruye el incidente antes de recibir los datos.

Prepare el hipervisor, la versión, la capacidad virtual, el tipo de datastore y la cronología de la falla. Indique qué archivos componen la VM, qué copias existen y qué acciones se intentaron. También liste los datos indispensables, su ruta aproximada, fechas y aplicación de origen. Esa información reduce pruebas sin dirección.

Para una evaluación remota no conviene subir de inmediato una imagen de varios terabytes. Prepare descriptores, inventario, tamaños, nombres de snapshots, mensajes y hashes ya disponibles; con ellos se decide si falta un archivo pequeño o si debe preservarse todo el datastore. Si la transferencia resulta necesaria, se acuerdan cifrado, canal y responsable de cada extremo. Las credenciales viajan separadas y la copia fuente permanece congelada durante el envío.

Adjuntar inventario, configuración y mensajes exactos
Ordenar bases, carpetas y servicios por prioridad
Definir si necesita VM, exportación o archivos sueltos

Qué archivos conviene reunir

Incluya descriptores, extents, snapshots, discos padre, VMX o VMCX, exportaciones, registros y capturas del error. Si el almacenamiento físico falla, documente también sus unidades y controlador. No envíe contraseñas dentro del paquete; las credenciales se comparten por el canal acordado.

Qué debe definir antes de autorizar

Aclare qué resultado mínimo tendría valor: una base específica, la última versión de un proyecto o una VM completa. En la solicitud de cotización puede describir esas prioridades y el plazo operativo real. La propuesta se apoya en el diagnóstico, no en un porcentaje genérico.

Conserve los nombres originales y no comprima ni sincronice de nuevo una cadena incompleta.

Preguntas frecuentes

¿Se puede recuperar un VMDK si falta el descriptor?

A veces es posible reconstruir una hipótesis con la capacidad, los extents, la geometría y la información del hipervisor. Se trabaja sobre una copia y se valida contra particiones y archivos. Si también faltan deltas o bloques, el resultado puede limitarse a una versión anterior o parcial.

¿Qué ocurre si desapareció un snapshot AVHDX o delta VMDK?

Los cambios que existían únicamente en ese snapshot pueden no estar disponibles. Se ordenan los archivos restantes, se revisan identificadores y se determina qué punto temporal conserva coherencia. No conviene fusionar la cadena antes de saber qué pieza falta.

¿Una máquina virtual recuperada puede arrancarse de inmediato?

No se recomienda arrancarla sin una copia y un entorno aislado. El inicio genera escrituras y puede activar servicios dañados. Primero se verifican el sistema de archivos, las bases y los datos prioritarios; después se decide si conviene entregar una VM o extraer información.

¿Datastrophe puede abrir un VHDX protegido con BitLocker?

Se necesita la clave o credencial legítima y metadatos suficientes del volumen. Leer el contenedor no elimina el cifrado. Si la clave no está disponible o los metadatos criptográficos fueron destruidos, los bloques pueden permanecer inaccesibles aunque físicamente existan.

¿Basta con enviar el archivo VHDX o QCOW2 más grande?

No siempre. Puede depender de discos padre, snapshots, configuración o almacenamiento subyacente. Antes de copiar, conserve la carpeta completa, nombres y fechas, y prepare un inventario. Una revisión inicial indicará qué archivos o medios son necesarios para el diagnóstico.

Medios

Otras especialidades

Diagnóstico

¿Tiene dudas sobre un dispositivo o una falla?

Datastrophe evalúa el riesgo antes de cualquier intervención y le indica la ruta más prudente.

Solicitar diagnóstico