La reciente integración entre Veeam Backup & Replication 13.1 y Proxmox VE está ganando atención debido a su innovador enfoque para realizar copias de seguridad de imagen sin requerir la instalación de componentes permanentes en los nodos del clúster. Este desarrollo, aunque prometedor, carece de una documentación pública exhaustiva sobre su funcionamiento interno. Sin embargo, después de analizar un laboratorio con un clúster de Proxmox VE 9 y estudiar el comportamiento durante una copia de seguridad, se puede comprender mejor el proceso involucrado.
Una de las características más sorprendentes de esta implementación es que el hipervisor Proxmox permanece prácticamente intacto durante el proceso de copia de seguridad. A diferencia de otras plataformas de virtualización que requieren la instalación de componentes o servicios permanentes en los hosts, Veeam Backup & Replication no introduce ningún paquete adicional en los nodos Proxmox. Tampoco se implantan agentes permanentes dentro de las máquinas virtuales protegidas.
El protagonista de este proceso es una máquina virtual denominada «worker», encargada del trabajo pesado, no el nodo Proxmox. Durante la ejecución de la copia de seguridad, Veeam se encarga de reconfigurar automáticamente esta máquina virtual, la inicia al comienzo del trabajo, verifica su correcto funcionamiento mediante QEMU Guest Agent, lleva a cabo la copia de seguridad y finalmente apaga el «worker» al finalizar el proceso. Este modus operandi explica por qué los «workers» permanecen apagados la mayor parte del tiempo, activándose solo cuando se necesita realizar un trabajo de respaldo.
En términos técnicos, el disco de la máquina protegida se exporta mediante NBD (Network Block Device) desde QEMU, y el «worker» recibe esta exportación sin acceder directamente al volumen original. El mecanismo se basa en funcionalidades nativas de QEMU, lo que evita que el «worker» abra directamente el disco de la máquina protegida. En su lugar, el QEMU de la máquina protegida levanta un servidor NBD que transmite los datos al «worker».
Esta metodología también esclarece cómo operan los snapshots durante el proceso de copia. A pesar de que las nuevas escrituras de la máquina virtual se almacenan según la configuración de snapshots seleccionada, el «worker» sigue leyendo los datos desde la exportación NBD sin necesidad de acceder al volumen físico. Así, el snapshot no tiene que presentarse como un volumen independiente para ser leído por el «worker».
Sin embargo, antes de implementar esta solución en entornos corporativos, hay aspectos que deben considerarse. La documentación de Veeam especifica 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 soporta la autenticación mediante claves SSH ni cuentas protegidas mediante MFA para este acceso. Para organizaciones con estrictas políticas de seguridad, esto podría implicar la necesidad de planificar excepciones específicas.
En conclusión, aunque Veeam abstrae gran parte del funcionamiento interno de su integración con Proxmox VE, el proceso aprovecha capacidades existentes en QEMU, como la exportación de discos mediante NBD. El resultado es un mecanismo que minimiza la instalación de software permanente en los hosts y reduce el impacto sobre el hipervisor, delegando el procesamiento en una máquina virtual temporal gestionada por la plataforma de respaldo.
