Cómo realizar backups de máquinas virtuales sin instalar nada extra

Cuando empiezas a trabajar con entornos virtualizados es fácil caer en la trampa de pensar que, como todo es software, ya estará “protegido” de alguna manera. La realidad es que una máquina virtual se puede corromper, borrar o romper igual o más que un servidor físico, y si no tienes un plan de respaldo claro, tarde o temprano te acabarás arrepintiendo.

Además, muchas veces buscamos cómo hacer copias de seguridad de máquinas virtuales sin montar una infraestructura enorme ni instalar tropecientas herramientas y cómo automatizar copias de seguridad. Con un poco de orden, usando bien VSS, Hyper-V, VMware y algunas utilidades gratuitas, es posible proteger tus VMs apoyándote en lo que ya trae Windows Server o en software sin coste adicional.

Por qué es crítico hacer backups de tus máquinas virtuales

Las máquinas virtuales están por todas partes: Hyper-V en Windows Server, VMware Workstation en equipos de desarrollo, soluciones KVM en servidores Linux y montones de laboratorios caseros. Esta flexibilidad hace que se usen para casi todo: probar sistemas operativos, montar entornos de pruebas, ejecutar servicios en producción, desarrollar software o incluso alojar servicios de directorio y bases de datos críticas.

Ese uso tan intensivo tiene una consecuencia directa: si una VM importante se rompe y no tienes copia de seguridad consistente, puedes perder desde un simple laboratorio hasta todo tu entorno de producción. En KVM, Hyper-V o VMware, una máquina virtual no es más que un conjunto de archivos (discos virtuales, configuración, snapshots, etc.), de modo que un fallo de hardware, un borrado accidental o un ransomware pueden llevárselos por delante en cuestión de segundos.

En entornos basados en KVM, que son muy habituales en servidores Linux, la cosa se vuelve incluso un poco más peliaguda. La integración con el sistema anfitrión es profunda, se mezclan redes virtuales, almacenamiento compartido y diferentes formatos de disco, y eso hace que diseñar una estrategia de backup sin entender bien la arquitectura sea complicado. De ahí que sea tan importante tener claro cómo capturar el estado coherente de esas VMs sin romper nada.

En Hyper-V y VMware, aunque el concepto es parecido (ficheros de configuración + discos virtuales + snapshots), la forma correcta de hacer la copia de seguridad cambia según uses las herramientas integradas del sistema operativo o soluciones de terceros. No basta con copiar un VHDX o un VMDK a mano y cruzar los dedos; si quieres consistencia de aplicaciones, tienes que apoyarte en mecanismos como VSS y en los “writers” de Hyper-V o del propio hipervisor.

Por tanto, el objetivo real no es solo tener “una copia de algo”, sino conseguir backups consistentes, restaurables y que se puedan automatizar sin tener que instalar un zoo de herramientas en cada host. A partir de aquí veremos cómo hacerlo principalmente en Hyper-V y VMware, y qué opciones gratuitas tienes sobre la mesa.

Copias de seguridad de máquinas virtuales Hyper-V con Windows Server Backup

En servidores Windows con Hyper-V, mucha gente pasa por alto que Windows Server incluye de serie Copias de seguridad de Windows Server (Windows Server Backup), una utilidad que, bien usada, permite respaldar máquinas virtuales sin tener que pagar licencias adicionales. Eso sí, hay que dejarla correctamente integrada con el escritor VSS de Hyper-V para que las copias tengan sentido.

Para que Windows Server Backup trate a Hyper-V como una aplicación y pueda coordinar snapshots consistentes, es necesario que el escritor VSS de Hyper-V aparezca registrado dentro de la configuración de aplicación de la copia de seguridad. Si no, lo que estarás haciendo será un simple backup a nivel de volumen que puede dejar las VMs en estado incoherente.

El registro de este escritor se hace una sola vez a través del Editor del Registro (regedit). Básicamente se crea una estructura de claves bajo HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion, añadiendo una subclave WindowsServerBackup, otra llamada “Application Support” (Compatibilidad con aplicaciones) y, dentro de ella, una clave con el identificador del escritor de Hyper-V: {66841CD4-6DED-4F4B-8F17-FD23F8DDC3DE}.

En esa clave se define un valor de cadena llamado “Application Identifier” (Identificador de aplicación) y se le asigna el texto Hyper-V. Con esto, Copias de seguridad de Windows Server ya entiende que hay un componente de aplicación asociado a Hyper-V y se coordina con el escritor VSS de la plataforma. El proceso se remata cerrando regedit y, a partir de ese momento, las tareas de backup podrán gestionar las VMs correctamente.

A partir de ahí, cuando ejecutes una copia de seguridad desde la partición primaria del host, Windows Server Backup pedirá a Hyper-V que congele el estado de las máquinas virtuales mediante VSS, para que el contenido de disco que se copie sea consistente. Este detalle es importante porque marca la diferencia entre un backup que arranca siempre y uno que arranca cuando le da la gana.

Qué volúmenes y archivos hay que incluir en el backup de Hyper-V

Registrar el escritor es solo la mitad del trabajo: si no seleccionas los volúmenes adecuados en la tarea de copia de seguridad, la restauración de las máquinas virtuales puede quedar coja. Hyper-V guarda la información de las VMs repartida en varios discos, así que hay que tenerlos todos en cuenta.

En un entorno típico, los archivos de configuración de las máquinas virtuales se almacenan en un volumen (por ejemplo, D:), los discos duros virtuales VHD o VHDX se guardan en otro (por ejemplo, E:), y el fichero InitialStore.xml suele residir en C:\ProgramData\Microsoft\Windows\Hyper-V. Ese InitialStore.xml contiene información esencial para que Hyper-V pueda enumerar y gestionar las VMs.

Esto implica que, si quieres tener la seguridad de poder reconstruir por completo las máquinas virtuales después de un desastre, la tarea de copia de seguridad debe incluir todos los volúmenes que intervienen: C:, D:, E: o los que uses en tu instalación. Respaldar solo el volumen donde están los VHDX y olvidarse de C: suele ser la receta perfecta para un disgusto posterior.

Hay otras casuísticas a tener en cuenta. Si la máquina virtual no tiene instalados los Integration Services de Hyper-V (algo relativamente habitual en sistemas operativos antiguos o en algunas distribuciones), el hipervisor no puede coordinar internamente las VSS dentro de la VM. En ese caso, durante la captura de la instantánea VSS la VM se pone en estado guardado (saved state), es decir, se “congela” desde el punto de vista del host.

Lo mismo ocurre cuando el sistema operativo de la máquina virtual no soporta VSS de forma nativa, como Windows 2000 o Windows XP. En estos casos, Hyper-V tampoco puede hacer una copia “en caliente” con integración completa de aplicaciones, por lo que recurre a poner la VM en estado guardado mientras dura la fotografía VSS para mantener la coherencia a nivel de disco.

Otro aspecto delicado son las VMs que usan discos dinámicos (no discos de expansión dinámica, sino discos dinámicos gestionados por el sistema operativo invitado). Para este tipo de configuraciones, se recomienda hacer las copias de seguridad en modo sin conexión: se apaga la máquina virtual, se ejecuta el backup y luego se vuelve a encender. Así se evitan posibles problemas de consistencia derivados de cómo el invitado gestiona sus volúmenes dinámicos.

Restauración de máquinas virtuales Hyper-V con Copias de seguridad de Windows Server

Tan importante como saber hacer el backup es saber restaurarlo. Con Windows Server Backup, la recuperación de máquinas virtuales Hyper-V se hace normalmente a través del tipo de restauración “Aplicaciones”, seleccionando Hyper-V como aplicación objetivo en el asistente.

El proceso estándar es relativamente directo: abres Copias de seguridad de Windows Server desde Herramientas administrativas, eliges la opción “Recuperar” en el menú de Acciones y seleccionas el servidor del que quieres restaurar información. Después escoges la fecha y la hora de la copia de seguridad de la que quieres tirar.

En el siguiente paso, el asistente te pedirá el tipo de recuperación. Si eliges “Aplicaciones” y luego Hyper-V, el sistema se encarga de reconstruir las VMs utilizando los datos de volumen y la información de configuración que se guardó en el backup. Solo tienes que indicar la ubicación de destino —que puede ser el mismo host o uno distinto compatible— y dar a “Recuperar” para lanzar el proceso.

Hay, sin embargo, una limitación relevante: las máquinas virtuales que tienen dos o más snapshots encadenadas a menudo no se restauran correctamente mediante este método directo. Si te encuentras con que una VM no aparece o falla la restauración, lo más probable es que el origen sea precisamente el exceso de instantáneas.

La forma de resolverlo pasa por un procedimiento en dos fases. Primero, abres el Administrador de Hyper-V y eliminas la máquina virtual que no se ha podido restaurar, para limpiar el estado actual del host. Después vuelves a Windows Server Backup, pulsas otra vez en “Recuperar”, eliges servidor, fecha y hora, pero esta vez, cuando el asistente te solicite el tipo de recuperación, seleccionas “Archivos y carpetas”.

En ese modo de restauración, se localiza directamente el directorio en el que se almacenan las instantáneas y archivos de la máquina virtual problemática, se indica una ruta de destino donde quieres que se copien (puede ser una ubicación temporal), y pulsas de nuevo “Recuperar” para que se vuelquen todos esos ficheros.

Una vez finalizada esa primera restauración a nivel de archivos, vuelves a lanzar un segundo proceso de recuperación, esta vez de tipo “Aplicaciones” seleccionando Hyper-V. Con los archivos de snapshots ya restaurados, Hyper-V suele ser capaz de reconstruir correctamente la máquina virtual, incluyendo su estado y sus puntos de recuperación previos.

¿Vale con copiar la carpeta de la VM usando un backup de archivos?

En muchos entornos pequeños o con soluciones de copia de seguridad muy básicas aparece siempre la misma duda: si mi software de backup solo sabe copiar archivos y carpetas, ¿puedo simplemente hacer backup de la carpeta de la VM de Hyper-V y listo?

En teoría se puede, porque al final una máquina virtual de Hyper-V no es más que un conjunto de archivos de configuración, VHDX, checkpoints, etc. Sin embargo, si no coordinas el backup con VSS y con Hyper-V VSS Writer, la consistencia de los datos dentro de la VM no está garantizada. Podrías acabar con un disco virtual en un estado “a medio escribir”, con transacciones sin completar o bases de datos corruptas.

Si tu herramienta de backup ofrece integración con VSS (Volume Shadow Copy Service), es tentador pensar que marcar la casilla “usar VSS” y seleccionar la carpeta de la VM es suficiente. El problema es que VSS a nivel de host no sabe, por sí mismo, que tiene que avisar a Hyper-V para preparar las máquinas virtuales, a menos que utilice específicamente el escritor Hyper-V VSS Writer.

La forma recomendada de conseguir consistencia es usar wbadmin junto con Hyper-V VSSWriter. wbadmin es la utilidad de línea de comandos para gestionar Copias de seguridad de Windows Server, y cuando se configura correctamente con el escritor de Hyper-V, coordina la captura del estado de las VMs con el sistema de snapshots del host. Así, las aplicaciones dentro de las máquinas virtuales tienen oportunidad de vaciar buffers, cerrar transacciones y dejar el disco en un punto seguro.

De modo que, si solo dispones de un software de backup centrado en archivos y carpetas y no tiene soporte explícito para Hyper-V, lo más prudente es usarlo únicamente para copias en frío (apagando la VM) o como complemento, y delegar los backups en caliente consistentes en herramientas que sí hablen con Hyper-V VSS Writer, como wbadmin o Windows Server Backup.

Backups gratuitos para Hyper-V y VMware: opciones de terceros

Si tu entorno va creciendo o necesitas más flexibilidad, puede que te quedes corto con Windows Server Backup o con las herramientas más básicas. Para estos casos, existen soluciones gratuitas de terceros que permiten hacer copias de seguridad específicas de máquinas virtuales Hyper-V y VMware, con más opciones de programación, retención y restauración granular.

Una de las opciones conocidas es Nakivo Backup & Replication Free Edition. Esta edición sin coste ofrece soporte tanto para VMware como para Hyper-V, e incluso para entornos en AWS. Permite trabajar con copias incrementales y realizar backups específicos de VMs. En su versión gratuita suele prescindir de algunas funciones avanzadas (como la deduplicación global o la compresión muy agresiva), pero resulta suficiente para laboratorios o para un número moderado de máquinas.

Otra solución popular es Altaro VM Backup Free. Su versión gratuita permite proteger hasta dos máquinas virtuales por host, lo que encaja bien en entornos domésticos, pequeñas oficinas o laboratorios. Con esta herramienta se pueden programar copias de seguridad, aplicar una clave de cifrado y trabajar tanto con Hyper-V como con VMware ESXi y vCenter Server, manteniendo todo centralizado en una consola relativamente amigable.

También está disponible Vembu BDR Suite Free Edition, que proporciona una versión gratuita con ciertas restricciones respecto a la edición de pago, pero que permite hacer copias de seguridad de máquinas virtuales tanto en VMware como en Hyper-V. Esta suite incluye, además, opciones de recuperación ajustables, compresión de datos, cifrado y mecanismos de corrección de errores para mejorar la integridad de la información almacenada.

En la misma línea encontramos Unitrends Backup Free Edition, una alternativa orientada a proteger máquinas virtuales VMware con funciones bastante completas. Su edición gratuita soporta copias tanto en almacenamiento local como en la nube, ofrece la posibilidad de recuperación casi instantánea de VMs, restauración granular a nivel de archivos, clonación, copia, exportación y gestión de hasta cuatro máquinas virtuales.

Este tipo de herramientas, aunque sean gratuitas, suelen requerir instalación y cierta curva de aprendizaje, pero a cambio te dan un control mucho más fino sobre qué se copia, cómo, cuándo y dónde. Para entornos donde no quieras depender únicamente de las utilidades nativas del sistema operativo, pueden ser un buen equilibrio entre “no instalar nada” y no gastarte un euro en licencias; también puedes valorar alternativas de imagen como respaldos avanzados con Macrium Reflect.

BackupChain para copias en vivo de máquinas virtuales VMware

Dentro del ecosistema de soluciones de terceros destaca también BackupChain, sobre todo cuando hablamos de VMware corriendo sobre Windows. Esta herramienta está diseñada para realizar copias de seguridad en vivo de máquinas virtuales VMware Server y VMware Workstation alojadas en sistemas Windows, lo que permite proteger laboratorios, servidores de pruebas o incluso entornos productivos de tamaño medio.

Hay que tener presente una limitación importante: BackupChain no soporta ESX ni ESXi de forma directa. Si quieres hacer backup de máquinas virtuales que residen en ESX/ESXi, la alternativa es instalar BackupChain dentro de cada VM y realizar una copia de seguridad a nivel de disco (sector a sector) o a nivel de archivos desde el interior de la máquina virtual. No es tan cómodo como trabajar desde el host, pero funciona.

Cuando ejecutas BackupChain directamente en el equipo anfitrión de VMware sobre Windows, puedes crear tareas específicas para respaldar las carpetas donde residen las máquinas virtuales. Lo habitual es configurar una nueva tarea de tipo “VMware backup” y seleccionar únicamente los directorios que contienen los VMDK, los archivos de configuración .vmx y el resto de ficheros relacionados con la VM.

Por ejemplo, si tienes un servidor virtual con Windows Server 2008 R2 ubicado en C:\VmwareWorkstation, basta con seleccionar esa carpeta en la tarea de copia de seguridad. Conviene tener claro que BackupChain solo puede hacer copias “en vivo” de máquinas virtuales que estén almacenadas en discos locales; las VMs alojadas en rutas de red requieren apagarse primero (copias en frío) para garantizar integridad.

Si no sabes exactamente qué directorios usa una máquina virtual concreta, puedes abrir la configuración de la VM en VMware y comprobar la ruta del archivo VMDK. Normalmente el resto de archivos relacionados están en la misma carpeta o en subcarpetas, así que incluyendo esa ruta en la tarea de BackupChain estarás cubriendo todo el conjunto necesario.

Una vez definidos los orígenes, solo queda elegir un destino de backup, configurar la programación y ajustar, si lo necesitas, los parámetros de compresión, retención o cifrado. La tarea se puede guardar y lanzar cuando quieras; luego siempre podrás modificar más detalles según vayas viendo cómo se comporta en tu entorno.

Restauración de máquinas virtuales VMware con BackupChain

Restaurar VMs con BackupChain es bastante directo si entiendes la estructura de carpetas que crea la herramienta. El proceso arranca desde la opción “Restaurar archivos, carpetas y máquinas virtuales” del menú principal, donde debes indicar la ubicación en la que guardaste tus copias de seguridad.

En esa ubicación de backup encontrarás una carpeta raíz que representa la unidad de origen (por ejemplo, C_ en lugar de C:), junto con un archivo BackupChain.config y otras subcarpetas. Es fundamental seleccionar exactamente esa carpeta raíz, porque es la que contiene toda la información necesaria para interpretar los puntos de restauración.

A continuación eliges el punto de restauración que quieras, bien seleccionando una fecha en el calendario o, si no tienes claro cuándo se copió algo, usando la vista completa de todas las copias disponibles. Mientras tú seleccionas, BackupChain escanea en segundo plano las distintas copias en busca del disco virtual más antiguo totalmente recuperable, y te muestra esa fecha como referencia.

En la pantalla de restauración, si tu objetivo es recuperar la última versión completa de una máquina virtual, basta con que selecciones la carpeta de la VM en el árbol de la izquierda y no marques ningún archivo concreto. Así, la herramienta entenderá que debe restaurar todos los ficheros asociados a esa VM de una sola tacada.

Si, en cambio, necesitas volver a una versión anterior de un VMDK concreto, puedes hacer clic en el archivo de disco virtual y verás cómo la pantalla se divide en dos zonas. En la parte inferior aparecerán las diferentes versiones históricas de ese archivo; seleccionas la que te interese y la restauras sin marcar el fichero de la parte superior.

En ambos casos, el asistente te pedirá una ruta de destino donde dejar los datos restaurados. Puedes usar una ruta local o incluso un recurso compartido UNC, si te resulta más cómodo trabajar desde otro servidor. Una vez finaliza el proceso, solo tienes que ir al Explorador, localizar el archivo .vmx de la máquina virtual y abrirlo desde VMware.

Cuando VMware detecta que se ha abierto un .vmx restaurado, suele preguntarte si “has movido” o “has copiado” la máquina virtual. Lo habitual es seleccionar la opción “La he movido”, para que el gestor de VMs conserve el identificador de hardware original. Solo en el caso de que quieras ejecutar una copia de prueba en paralelo a la VM original te interesa usar “La he copiado”, lo que generará un nuevo identificador.

Es posible que al arrancar la VM restaurada aparezca un mensaje indicando que “Windows no se cerró correctamente”. Esto suele deberse a que la marca interna de apagado limpio no se había actualizado al hacer el backup. En general, si la restauración se ha hecho con un método consistente, la máquina virtual estará en buen estado y el sistema operativo terminará de ajustarse tras ese primer arranque.

Copias de seguridad en frío de VMware con BackupChain y vmrun

Aunque las copias de seguridad en vivo son muy cómodas, hay escenarios en los que los administradores prefieren realizar backups en frío, apagando la máquina virtual antes de copiar sus discos. Esto puede ser por requisitos de ciertas aplicaciones, por evitar cualquier posible inconsistencia o por pura política interna, por ejemplo documentando procedimientos de apagado automático con UPS y NUT.

BackupChain permite automatizar este flujo apoyándose en vmrun.exe, la utilidad de línea de comandos que proporciona VMware. La idea es sencilla: antes de lanzar la copia, se ejecuta un comando que detiene la VM, y cuando la tarea termina, otro que la vuelve a arrancar.

Por ejemplo, puedes configurar en la pestaña de opciones de BackupChain un comando a ejecutar al inicio de la tarea, como C:\ruta-a-vmware\vmrun.exe stop «C:\ruta-a-vm\mi_vm.vmx», y otro al finalizar la copia, como C:\ruta-a-vmware\vmrun.exe start «C:\ruta-a-vm\mi_vm.vmx». En ambos casos interesa que la tarea espere a que el comando externo complete su ejecución.

Con este enfoque, combinando la automatización de BackupChain con las órdenes de vmrun, consigues copias completamente coherentes a costa de unos minutos de parada planificada de la VM. Algunos administradores incluso alternan copias en frío y en caliente para tener una capa extra de seguridad en sus planes de recuperación.

Backup de VMs Hyper-V a un NAS QNAP: Hyper Data Protector vs Veeam

En muchas pymes el escenario es muy reconocible: dos servidores físicos con Windows Server 2016/2019, unas cuantas máquinas virtuales Hyper-V (menos de diez) y un NAS QNAP que hace de almacén de ficheros y, de paso, de destino de copias de seguridad, aplicando reglas de seguridad esenciales para carpetas compartidas. A partir de ahí surge la pregunta de qué solución gratuita tiene más sentido para trasladar los backups de las VMs al NAS.

Sin gastar un euro en licencias, un administrador se suele encontrar con varias opciones: usar Hyper Data Protector (HDP) del propio QNAP, desplegar Veeam Community Edition en un servidor físico separado algo antiguo o montar Veeam Community como máquina virtual en uno de los hosts Hyper-V. Todas son posibles, pero no todas son igual de razonables.

Con Hyper Data Protector, el principal atractivo es que viene integrado en el NAS, no requiere montar más servidores y permite lanzar copias directamente hacia el almacenamiento QNAP. Para entornos pequeños y relativamente sencillos suele funcionar bastante bien y, si ya lo estás usando sin problemas, te quita mucha faena de encima.

El lado menos bonito es que QNAP no es, precisamente, un fabricante especializado en software de backup empresarial, y su historial de vulnerabilidades y de tiempos de respuesta en parches de seguridad genera ciertas dudas. Apoyar toda tu estrategia de copias de seguridad de VMs en una única herramienta del NAS puede dejarte algo vendido si un fallo de software o un problema de firmware da la cara en el peor momento.

Veeam Community Edition, por su parte, es una solución mucho más madura y extendida en el mundo de la virtualización. Soporta escenarios complejos, ofrece un control muy fino sobre los jobs y la restauración, y está bastante bien optimizada para entornos Hyper-V y VMware. Instalarla en un servidor físico dedicado —aunque sea un Dell PowerEdge 1850 veterano— permite aislar el software de backup del resto de cargas de trabajo y evitar que una caída de los hosts principales se lleve también por delante la consola de administración de copias.

El problema de tirar de hardware tan antiguo es evidente: fallos de disco, fuentes de alimentación, componentes descatalogados y un consumo energético que ya no compensa. Además, si en algún momento este tercer servidor cae y no tienes una alternativa rápida, podrías encontrarte con dificultades para gestionar o restaurar copias hasta que resuelvas el fallo.

La otra alternativa es montar Veeam Community en una máquina virtual que corra en uno de los dos servidores Windows. Aquí se sacrifica algo de aislamiento —si el host tiene un problema, la VM con Veeam se ve afectada—, pero a cambio ahorras energía, hardware y simplificas bastante el entorno. Esta opción suele ser perfectamente válida si dimensionas bien la VM y te aseguras de que el almacenamiento de copias reside en el QNAP, no en el mismo host.

Con estas cartas sobre la mesa, muchos administradores consideran que la opción menos “ridícula” para una pyme de este tipo es probar Veeam Community en una VM dedicada y mantener Hyper Data Protector como solución de respaldo adicional mientras validan el rendimiento y la fiabilidad. Así no dependes de un único sistema y puedes ir valorando si te merece la pena, a la larga, migrar toda la estrategia de backup a Veeam o mantener un enfoque mixto.

Si buscas otras posibilidades gratuitas más allá de QNAP y Veeam, siempre puedes echar un ojo a las ediciones free de Nakivo, Altaro, Vembu o Unitrends, pero teniendo en cuenta que cada una introduce su propia consola, sus agentes y sus peculiaridades. Conviene no montar un Frankenstein de herramientas y centrarse en una o dos soluciones bien entendidas y bien probadas.

Al final, proteger máquinas virtuales sin montar un monstruo de infraestructura pasa por aprovechar al máximo VSS, los escritores de Hyper-V y las utilidades integradas como Windows Server Backup, y, cuando se necesiten más prestaciones, apostar por una o dos soluciones de terceros gratuitas que se ajusten a tu entorno. Con una combinación sensata de backups en caliente, copias en frío puntuales y un buen almacenamiento secundario (como un NAS QNAP bien configurado), puedes dormir bastante tranquilo aunque tengas todo tu negocio corriendo en máquinas virtuales.