La integración entre Veeam Backup & Replication 13.1 y Proxmox VE ha despertado mucho interés porque promete copias de seguridad de imagen sin instalar componentes permanentes en los nodos del clúster. Sin embargo, el funcionamiento interno apenas está documentado públicamente. Tras analizar un laboratorio con un clúster de Proxmox VE 9 y observar el comportamiento durante una copia de seguridad, es posible entender mejor cómo se realiza realmente el proceso.

Las claves del backup de Veeam en Proxmox en 20 segundos

• Veeam no instala software permanente en los nodos Proxmox durante el backup.
• Utiliza una máquina virtual worker que crea y gestiona automáticamente.
• El disco de la máquina protegida se exporta mediante NBD desde QEMU.
• El worker recibe esa exportación sin abrir directamente el volumen original.
• El mecanismo se basa en funcionalidades nativas de QEMU.

Uno de los aspectos más llamativos de esta implementación es que el hipervisor permanece prácticamente intacto. A diferencia de otras plataformas de virtualización donde se despliegan componentes persistentes o servicios específicos en los hosts, durante esta prueba no apareció ningún paquete adicional de Veeam instalado en los nodos Proxmox ni tampoco agentes permanentes dentro de la máquina virtual protegida.

El laboratorio utilizado estaba formado por un clúster de Proxmox VE 9 de dos nodos, una instalación de Veeam Backup & Replication 13.1 independiente y una máquina virtual Windows con un disco de 40 GB.

El protagonista es la máquina virtual worker

En realidad, quien realiza el trabajo pesado no es el nodo Proxmox sino una máquina virtual denominada worker.

Durante la ejecución del trabajo de copia, Veeam:

• Reconfigura automáticamente el worker.
• Lo inicia cuando comienza el backup.
• Comprueba mediante QEMU Guest Agent que el sistema ha arrancado correctamente.
• Ejecuta la copia de seguridad.
• Apaga nuevamente el worker cuando el proceso termina.

Esto explica por qué, en una instalación normal del plugin de Proxmox, estos workers permanecen apagados la mayor parte del tiempo y únicamente se activan cuando deben participar en un trabajo de backup.

Comunicación directa con QEMU

Otra observación interesante apareció al analizar el monitor QMP (QEMU Machine Protocol) de la máquina virtual protegida.

Mientras el backup estaba en ejecución, una consulta manual al monitor devolvió un timeout, recuperando su funcionamiento habitual una vez finalizado el trabajo.

Se trata únicamente de una observación realizada en este laboratorio concreto, no de una limitación documentada por Veeam o Proxmox. Aun así, sugiere que durante la copia conviene evitar operaciones administrativas sobre esa máquina virtual, como lanzar manualmente un snapshot adicional o iniciar una migración en caliente.

El disco nunca lo abre el worker

La parte más interesante del análisis apareció al inspeccionar los procesos QEMU.

Inicialmente parecía lógico pensar que el worker abriría directamente el volumen de almacenamiento de la máquina protegida. Sin embargo, no ocurre así.

Durante la prueba:

• El proceso QEMU del worker no mantenía ningún descriptor abierto sobre el volumen de la máquina virtual.
• Era el QEMU de la VM protegida quien mantenía abierto el disco.
• Ese mismo proceso levantaba un servidor NBD (Network Block Device) escuchando sobre la interfaz de loopback.
• El QEMU del worker simplemente se conectaba a esa exportación NBD.

La captura del tráfico entre ambos procesos permitió observar incluso el handshake inicial del protocolo, donde aparecen las cadenas NBDMAGIC e IHAVEOPT, características del protocolo NBD.

En otras palabras, el disco nunca pasa directamente al worker. Lo que recibe es una exportación realizada por el propio QEMU de la máquina protegida utilizando mecanismos nativos del hipervisor.

Así encajan los snapshots

Esta observación también ayuda a entender el comportamiento de los snapshots.

Durante el backup, las nuevas escrituras de la máquina virtual continúan almacenándose según la configuración elegida para los snapshots (ya sea sobre la propia LUN o sobre un almacenamiento temporal externo).

Pero, independientemente de esa configuración, el worker sigue leyendo los datos desde la exportación NBD proporcionada por el QEMU de la máquina protegida, sin acceder directamente al volumen físico.

Este detalle aclara una duda habitual al revisar el almacenamiento durante un trabajo de copia: el snapshot no necesita presentarse como un volumen independiente para que el worker pueda leerlo.

Un aspecto importante para producción

Más allá del funcionamiento técnico, hay un requisito que sí conviene tener presente antes de implantar esta solución en entornos corporativos.

La documentación de Veeam indica que el acceso a los hosts Proxmox requiere una cuenta con privilegios root o con capacidad para elevar privilegios a root. Además, actualmente no se admite la autenticación mediante claves SSH ni cuentas protegidas mediante MFA para este acceso.

En organizaciones con políticas de endurecimiento (hardening) o controles estrictos de acceso privilegiado, este punto debe planificarse previamente, ya que puede requerir excepciones específicas en la política de seguridad.

Aunque Veeam abstrae gran parte del funcionamiento interno de su integración con Proxmox VE, este laboratorio permite comprobar que el proceso aprovecha principalmente capacidades ya existentes en QEMU, especialmente la exportación de discos mediante NBD. El resultado es un mecanismo que evita instalar software permanente en los hosts y reduce el impacto sobre el hipervisor, delegando el procesamiento en una máquina virtual temporal gestionada automáticamente por la propia plataforma de backup.