Recuperación de máquinas virtuales para empresas en Panamá

¿Qué es la recuperación de máquinas virtuales?

Virtualizar concentra muchos servidores en uno: cada máquina virtual es, en el fondo, un puñado de archivos —su disco virtual y su configuración— guardados dentro de un almacén de datos. Esa comodidad tiene una contracara: cuando algo se rompe en ese almacén, no cae un servicio, caen todos los que viven ahí. Recuperar una máquina virtual es devolver el acceso a esos archivos y a los datos que contienen cuando el hipervisor ya no puede.

La buena noticia es que la mayoría de los incidentes de virtualización son lógicos —no un disco roto, sino una estructura dañada— y, sobre un almacenamiento sano, son muy recuperables. La mala es que es fácil empeorarlos en los primeros minutos, intentando «arreglar» el datastore con las herramientas equivocadas. Entender la anatomía del problema es lo que separa una recuperación limpia de una pérdida.

Dos capas, no una: el datastore vive sobre un RAID

El error mental más común es tratar la máquina virtual como si fuera un archivo suelto. No lo es. En VMware, la VM es un conjunto de ficheros (el descriptor y el «flat» del VMDK, más su .vmx) dentro de un datastore con sistema de archivos VMFS; y ese VMFS, a su vez, está montado sobre un volumen RAID de varios discos. Son dos capas apiladas, y el fallo puede estar en cualquiera de ellas.

Esa distinción decide todo el trabajo. Si el RAID está sano y lo que se dañó es la capa de virtualización —el VMFS no monta, un VMDK se corrompió, una VM se borró—, la recuperación ocurre arriba, sobre los archivos. Pero si el RAID perdió un disco de más o su configuración, no tiene sentido pelear con el datastore: primero hay que reconstruir el almacenamiento, y eso es recuperación de servidor o de RAID. Equivocar la capa es perder el tiempo en el mejor caso y destruir datos en el peor.

¿Cuándo es recuperable una máquina virtual perdida?

Es recuperable, y con buenas probabilidades, cuando el almacenamiento sigue sano y el daño es lógico: una VM borrada del inventario, un VMDK eliminado por error, un datastore VMFS que dejó de montar por un header o un bitmap dañados, una cadena de snapshots que se rompió, o un datastore que se llenó y corrompió estructuras al consolidar. En todos estos casos los datos siguen en los discos; lo que se rompió es la forma de llegar a ellos, y eso se reconstruye.

Se vuelve mucho más difícil cuando hay daño físico debajo —varios discos del RAID caídos, una cabina con fallo de hardware— o cuando alguien ya «reparó» a ciegas: recreó el datastore, reformateó, o dejó que el sistema sobrescribiera el espacio. Por eso la primera consigna ante una VM caída es no tocar el datastore y llamar antes de improvisar.

Qué puede romperse: del RAID al archivo del invitado

Cuando llega un caso, lo primero es ubicar en qué capa está el problema, porque cada una pide una técnica distinta:

• La capa RAID: uno o más discos del arreglo fallaron y el host perdió el volumen entero.
• La tabla de particiones o el header del VMFS: el datastore existe pero no monta.
• El bitmap de recursos del VMFS: da errores de «sin espacio» en un datastore que está medio vacío.
• El descriptor o el flat del VMDK: la VM no arranca o el disco aparece corrupto.
• La cadena de snapshots: un delta intermedio se dañó y la VM no consolida.
• Dentro del invitado: el VMDK está bien, pero se borraron archivos dentro del sistema operativo de la VM.

Un diagnóstico que confunde estas capas lleva a soluciones que no aplican; uno que las separa bien resuelve el caso por el camino más corto y seguro.

Capa por capa: una vista rápida

A modo de mapa, así se ven los escenarios más frecuentes según dónde esté el daño. La tabla no reemplaza el diagnóstico —cada caso tiene matices—, pero ayuda a ubicar el problema y el primer movimiento sensato.

El patrón se repite en todas las filas: trabajar sobre copias, en solo lectura, y resolver de abajo hacia arriba. Ubicar bien la capa es la mitad de la recuperación.

VMFS por dentro: header, bitmap y descriptores

Vale la pena abrir la caja, porque explica muchos síntomas. El VMFS guarda al inicio del volumen un header con el identificador, la versión y la etiqueta; un bitmap de recursos que controla la asignación de bloques de 1 MB; y un heap de descriptores que apunta a los archivos .vmdk. Cuando se corrompe el header, el datastore no monta aunque los datos estén intactos; cuando se daña el bitmap, aparecen errores de espacio en un datastore medio vacío. Hay además un detalle de bloqueo propio del clúster: VMFS coordina el acceso entre varios hosts con mecanismos en disco, y un fallo de esa coordinación durante un corte de luz puede dejar bloqueos huérfanos que impiden montar el volumen sin que haya, en realidad, daño en los datos. Saber leer estas estructuras es lo que permite una extracción dirigida en vez de un palo de ciego.

¿Por qué vmkfstools no siempre arregla el datastore?

Porque las herramientas integradas del hipervisor están pensadas para operar sobre un medio sano. Cuando por debajo del VMFS hay errores de disco o un RAID degradado, una orden de reparación no arregla nada y, peor, puede consolidar el daño escribiendo sobre estructuras que aún se podían rescatar. Lo mismo vale para las soluciones rápidas que circulan en foros: recrear el datastore, reinicializar el volumen o forzar una reparación de bajo nivel sobre el almacenamiento afectado. La regla profesional es la contraria: análisis en solo lectura primero, sin escribir nada en el origen, y la recuperación dirigida a un destino distinto. Si el medio tiene errores, se resuelve la capa física antes de pedirle al VMFS que se repare a sí mismo.

La trampa de los snapshots encadenados

Los snapshots son una herramienta excelente y, mal usados, una bomba de tiempo. Cada snapshot crea un fichero delta donde se escriben los cambios, y el disco vivo pasa a ser la suma de la base más todos los deltas en cadena. El problema es la profundidad: cuando se acumulan muchos niveles —y se ven entornos con cadenas de cinco, siete o nueve deltas que nadie consolidó— la fragilidad crece, porque la pérdida de un delta intermedio rompe todo lo que vino después. La recomendación sana es no pasar de dos o tres niveles y consolidar a tiempo. En recuperación, cuando la cadena se rompe, el trabajo consiste en colapsarla hasta el último delta íntegro y validar desde ahí; lo posterior al punto dañado suele perderse, y conviene decirlo con claridad desde el diagnóstico.

¿El datastore se llenó y se corrompió?

Es uno de los incidentes más frecuentes y evitables. Un datastore que llega al 100 % de uso —muchas veces por snapshots olvidados que crecen sin control— puede corromper sus estructuras justo cuando intenta consolidar o migrar una máquina. La VM se apaga, no vuelve a encender y el datastore empieza a dar errores. La buena noticia es que el dato casi siempre sigue presente: se trabaja sobre una copia, se reconstruyen las estructuras del VMFS afectadas y se extraen las máquinas una a una. La mejor cura, eso sí, es preventiva: alertas de espacio al 80 o 90 % de uso y una política de snapshots que no los deje envejecer.

Datastore borrado por error: los primeros minutos

Cuando alguien borra un datastore equivocado —o un script de automatización lo hace solo—, los primeros minutos deciden cuánto se recupera. La consigna es inmediata: detener toda escritura sobre ese almacenamiento, porque cada bloque nuevo que se escribe puede pisar justo lo que se quiere rescatar. Después, revisar si la cabina de almacenamiento tiene snapshots a nivel de hardware, que a veces permiten revertir en minutos. Y, sobre todo, no recrear el datastore sobre el mismo espacio «para volver a empezar»: eso es lo que convierte un caso recuperable en uno perdido. Con el medio quieto, la recuperación reconstruye el VMFS y extrae las máquinas que vivían en él.

VM entera o solo archivos del invitado: dos recuperaciones distintas

Hay dos preguntas que parecen la misma y no lo son: ¿hace falta la máquina virtual completa, lista para arrancar, o solo unos archivos que vivían dentro de ella? La respuesta cambia el trabajo. Muchas veces el cliente cree que necesita «la VM», pero lo que de verdad importa es la base de datos, la carpeta de proyectos o los correos que estaban adentro; en ese caso basta extraer el VMDK, montarlo como disco secundario y copiar lo que importa, sin reconstruir un entorno arrancable. Es más rápido y más seguro.

Otras veces sí se necesita la máquina operativa de vuelta —porque corre un servicio difícil de reinstalar—, y entonces el objetivo es devolver un VMDK consistente que encienda. Por eso, en el diagnóstico preguntamos antes que nada qué se busca recuperar: el dato o el sistema. Como recordamos siempre, lo esencial de una VM es su contenido, no su configuración, y aclararlo desde el inicio evita trabajo de más y acelera lo que de verdad detiene al negocio.

Almacenamiento compartido: vSAN, SAN e iSCSI

En entornos serios el datastore rara vez vive en discos locales: está en almacenamiento compartido. Una vSAN agrega los discos de varios hosts en un solo pool; una SAN expone volúmenes (LUNs) por iSCSI o fibra a todo el clúster. Eso cambia la recuperación en dos sentidos. Primero, el alcance: un solo LUN o un componente afectado no obliga a derribar toda la infraestructura, así que se trabaja de forma quirúrgica sobre lo dañado. Segundo, el método: cuando el fallo es lógico y los hosts siguen en pie, muchas veces se puede atacar el problema sin apagar nada, conectándose al entorno, lo que enlaza de lleno con la recuperación remota.

La vSAN tiene además una particularidad: como reparte los datos entre nodos, recuperar con un conjunto parcial de discos reduce lo que se puede rescatar, de modo que conviene preservar todos los componentes del clúster antes de actuar. La regla, de nuevo, es no improvisar sobre almacenamiento compartido en producción: un movimiento apresurado afecta a muchas máquinas a la vez. En estos entornos coordinamos siempre la ventana de trabajo con el equipo de TI y preservamos el estado completo del clúster antes de tocar nada, precisamente porque el riesgo de una acción mal medida se multiplica por el número de máquinas que comparten ese almacenamiento.

Hyper-V, Proxmox y el mismo principio

Aunque VMware concentra la mayoría de los casos, el método no cambia con la plataforma. En Microsoft Hyper-V, las máquinas viven en discos VHDX y sus checkpoints en ficheros AVHDX que hay que fusionar con cuidado en el orden correcto; una fusión mal hecha es el equivalente a romper una cadena de snapshots. En Proxmox, los discos suelen ser qcow2 o volúmenes LVM, con su propia lógica de instantáneas. Cambian los formatos y los nombres, pero el principio es el mismo de siempre: la mayoría de las pérdidas son lógicas sobre almacenamiento sano, se trabaja sobre copias y nunca sobre el original, y si el medio físico falló, primero se recupera la capa de abajo. Atendemos los tres entornos sin reinventar el criterio.

Nuestro proceso de recuperación de máquinas virtuales

El método respeta la misma columna vertebral de toda recuperación, con un primer paso que aquí es decisivo: saber en qué capa está el daño antes de mover nada.

1. Identificar la capa que falló

Determinamos si el problema está en el RAID, el datastore VMFS, el VMDK, la cadena de snapshots o el sistema invitado; eso decide toda la estrategia.

2. Asegurar el almacenamiento

Si el RAID falló, imágenes en solo lectura de los discos y reconstrucción del arreglo offline antes de tocar el datastore.

3. Interpretar el VMFS

Parseamos el VMFS para localizar y extraer cada .vmdk —descriptor más flat— sin montar el datastore en el host afectado.

4. Resolver snapshots y VMDK

Colapsamos la cadena de snapshots hasta el último punto íntegro y reparamos o reconstruimos el disco virtual, siempre sobre una copia.

5. Validar el invitado

Montamos el VMDK recuperado como disco secundario y verificamos el sistema de archivos y los datos del invitado antes de entregar.

# ¿Qué capa falló?
RAID5 (4 discos) -> 1 disco DEGRADADO, arreglo monta en solo lectura
Datastore VMFS6: header OK, bitmap de recursos DAÑADO   # "sin espacio" falso
VM "SRV-ERP": descriptor .vmdk OK, cadena de 5 snapshots -> rota en delta-3

# Plan, en este orden:
  1) Imagen de los 4 discos (solo lectura) + reconstruir RAID offline
  2) Parsear VMFS6 -> extraer SRV-ERP-flat.vmdk + descriptor
  3) Colapsar snapshots hasta delta-2 (delta-3 ilegible)  # se pierde lo posterior
  4) Montar el VMDK como disco secundario y validar el invitado

Ese registro resume el criterio: se nombra cada capa, se actúa de abajo hacia arriba, y se dice con honestidad qué se recupera —hasta delta-2— y qué no. Ningún paso escribe sobre el origen.

¿Qué no debes hacer con una VM o un datastore caído?

Las decisiones de los primeros minutos pesan tanto como la técnica. Conviene evitar:

• No recrees el datastore ni lo reinicialices «para empezar de cero»: borra el mapa de lo que querías recuperar.
• No fuerces vmkfstools ni reparaciones de bajo nivel sobre un almacenamiento con errores.
• No sigas escribiendo en el datastore afectado: ni nuevas VMs, ni migraciones, ni snapshots.
• No reconstruyas el RAID a ciegas ni dejes que la controladora «se repare» antes de imaginar los discos.
• No consolides una cadena de snapshots sospechosa sin una copia previa: una fusión fallida amplía el daño.

¿Cuánto cuesta y cuánto tarda recuperar una máquina virtual?

Depende de la capa afectada y del tamaño. Un VMDK borrado sobre un datastore sano puede resolverse rápido; un caso de dos capas —RAID degradado más VMFS dañado más snapshots rotos— lleva más, porque hay que imaginar discos, reconstruir el arreglo y luego trabajar la virtualización. Por eso primero diagnosticamos, sin tocar el origen, y entonces fijamos por escrito el alcance y el precio antes de empezar. Para una caída que detiene la operación, la línea de emergencia 24/7 arranca de inmediato. No damos cifras «desde» sin ver el caso, porque en virtualización el plazo cambia por completo según en qué capa esté el daño.

La forma de no repetirlo: respaldo de virtualización

Toda recuperación de máquinas virtuales termina en la misma recomendación: un respaldo pensado para virtualización, que copie las VMs de forma consistente y, mejor aún, las guarde fuera del mismo almacenamiento y de la misma red. Un respaldo a nivel de hipervisor permite restaurar una máquina entera en minutos, en lugar de reconstruir un VMDK pieza a pieza. Y como el ransomware moderno apunta a los entornos de virtualización y a sus copias, conviene sumar copias inmutables y separadas. Por eso ligamos esta recuperación con el respaldo de servidores y máquinas virtuales y, cuando el caso es lógico y el host sigue en pie, con la recuperación remota que evita parar la operación.

Preguntas frecuentes