Recuperación de datos de máquinas virtuales VMware y VirtualBox
Las máquinas virtuales han transformado la infraestructura IT de empresas de todos los tamaños. VMware, VirtualBox e Hyper-V permiten ejecutar múltiples sistemas operativos sobre un único servidor físico, pero también concentran un riesgo adicional: si el disco del host falla, todos los discos virtuales que contiene pueden perderse al mismo tiempo. Y cuando un archivo .vmdk, .vdi o .vhdx se corrompe, acceder a los datos del guest sin arrancar la máquina requiere conocimientos forenses específicos. Esta guía explica los fallos más frecuentes y cómo los abordamos en nuestro laboratorio.
Formatos de disco virtual y sus vulnerabilidades
VMware: archivos .vmdk
VMware Workstation, VMware Player y VMware ESXi almacenan los discos de las máquinas virtuales en formato VMDK (Virtual Machine Disk). Un disco VMware puede estar compuesto de un único archivo monolítico o dividido en múltiples fragmentos de 2 GB. Los fallos más comunes incluyen:
- Corrupción del descriptor VMDK: el archivo de metadatos que describe la geometría y extensiones del disco se daña, impidiendo que VMware lo monte. Los datos de los fragmentos de datos están intactos pero inaccesibles.
- Snapshot bloqueado o huérfano: las cadenas de snapshots (.vmdk + -delta.vmdk) pueden quedar en estado inconsistente si la VM se apaga bruscamente. El proceso de consolidación falla y los datos del snapshot más reciente se vuelven inaccesibles.
- Thin provisioning sobre VMFS: en entornos ESXi, los discos thin-provisioned pueden corromperse si el datastore se llena al 100% mientras la VM está escribiendo. El resultado es un archivo VMDK truncado.
- Borrado accidental del .vmdk desde el datastore: un administrador elimina por error la VM desde vSphere sin marcar "eliminar archivos". Los archivos VMDK permanecen en el datastore hasta que se sobrescriben.
VirtualBox: archivos .vdi
Oracle VirtualBox usa el formato VDI (Virtual Disk Image), aunque también soporta VMDK y VHD. Los problemas específicos de VDI incluyen:
- UUID duplicado: VirtualBox usa un UUID interno para identificar cada disco. Si se copia o mueve un .vdi sin regenerar el UUID, la aplicación rechaza montarlo. Recuperamos los datos sin necesidad de arrancar la máquina.
- Corrupción de la cabecera VDI: los primeros bytes del archivo VDI contienen el magic number, la versión y el mapa de bloques. Si estos se corrompen (por caída de energía durante escritura), el archivo queda ilegible para VirtualBox.
- Disco dinámico fragmentado en el host: en discos duros mecánicos del host, los archivos .vdi de gran tamaño pueden fragmentarse severamente. Si el host falla, recuperar un archivo de 200 GB con miles de fragmentos requiere reconstrucción de la tabla de asignación del NTFS o ext4 del host antes de poder acceder al contenido del guest.
Hyper-V: archivos .vhdx y .vhd
Microsoft Hyper-V usa el formato VHDX (o el legacy VHD). El formato VHDX tiene estructuras de metadatos redundantes que lo hacen más resistente a la corrupción que el VHD original, pero no es inmune:
- Corrupción de la BAT (Block Allocation Table): la tabla que mapea bloques virtuales a posiciones físicas en el .vhdx puede dañarse, haciendo que el sistema de archivos del guest sea ilegible.
- Checkpoints Hyper-V en estado inconsistente: similar a los snapshots de VMware, un checkpoint no consolidado puede dejar la VM en estado no arrancable.
- CSV (Cluster Shared Volumes) dañados: en entornos Hyper-V sobre Windows Server con failover clustering, la corrupción del CSV puede afectar a múltiples VMs simultáneamente.
Recuperación sin arrancar la máquina virtual
Una de las capacidades más valiosas que ofrecemos es la extracción de archivos individuales del interior de una VM sin necesidad de arrancarla. Esto es especialmente útil cuando:
- El sistema operativo guest está corrompido pero los datos de usuario están intactos.
- Solo se necesitan determinados archivos o carpetas, no la VM completa.
- El guest tiene un sistema de archivos Linux (ext4, XFS, Btrfs) y el administrador no tiene acceso al sistema arrancado.
- La VM contiene un servidor de base de datos (MySQL, PostgreSQL, SQL Server) y se necesitan los archivos de datos sin restaurar toda la instancia.
Nuestro proceso consiste en montar el disco virtual en modo read-only en nuestro entorno forense, analizar el sistema de archivos del guest y extraer los datos solicitados. Este enfoque evita cualquier modificación del archivo original y preserva la cadena de custodia si es necesario para un proceso legal o una auditoría.
Recuperación de entornos ESXi y vSphere
Datastore VMFS corrompido
El sistema de archivos VMFS (Virtual Machine File System) de VMware ESXi tiene una estructura de metadatos compleja. Si la cabecera del volumen VMFS se corrompe —por un fallo de LUN en una SAN, por ejemplo— todas las VMs del datastore desaparecen de vSphere. Recuperamos el contenido de datastores VMFS 5 y VMFS 6 a partir de la imagen forense de los LUNs o discos subyacentes.
Base de datos de vCenter Server
VMware vCenter Server almacena toda la configuración de la infraestructura virtual en una base de datos embebida (PostgreSQL en versiones recientes) o externa (SQL Server, Oracle). Si el appliance de vCenter falla y se pierde la base de datos, la gestión centralizada de toda la infraestructura VMware queda inoperativa. Recuperamos bases de datos PostgreSQL y SQL Server de instancias vCenter dañadas.
Tabla de precios orientativos
| Tipo de caso | Precio estimado | Plazo |
|---|---|---|
| Reparación de descriptor VMDK / cabecera VDI | 200 € – 400 € | 24-48 h |
| Recuperación de snapshot corrompido | 250 € – 500 € | 2-4 días |
| Extracción de archivos de VM sin arrancar | 200 € – 450 € | 24-72 h |
| Recuperación de datastore VMFS | 400 € – 800 € | 4-8 días |
| BD vCenter corrompida | 300 € – 700 € | 2-5 días |
| Host con fallo físico + VMs múltiples | 500 € – 1.200 € | 5-12 días |
Diagnóstico siempre gratuito. Solo cobramos si recuperamos tus datos.
Buenas prácticas para proteger tus máquinas virtuales
- Backups externos al datastore: exporta periódicamente las VMs críticas a otro almacenamiento físico usando vSphere Data Protection, Veeam o similar.
- No abuses de los snapshots: los snapshots no son backups. Una cadena larga de snapshots degrada el rendimiento y aumenta el riesgo de corrupción.
- UPS en el host: un corte de energía con una VM escribiendo activamente es una de las causas más frecuentes de corrupción de VMDK.
- Monitoriza el espacio del datastore: un datastore al 95% de capacidad con discos thin-provisioned es una receta para la corrupción de datos.
- Prueba la restauración regularmente: un backup que nunca se ha restaurado puede no ser válido cuando realmente lo necesitas.
WhatsApp