The integration between Veeam Backup & Replication 13.1 and Proxmox VE has generated significant interest because it promises image backups without installing permanent components on the cluster nodes. However, the internal operation is barely documented publicly. After analyzing a test environment with a Proxmox VE 9 cluster and observing the behavior during a backup, we can better understand how the process actually works.
The key points of Veeam backup on Proxmox in 20 seconds
- Veeam does not install permanent software on Proxmox nodes during the backup.
- It uses a worker virtual machine that is automatically created and managed.
- The protected machine’s disk is exported via NBD from QEMU.
- The worker receives this export without directly opening the original volume.
- The mechanism is based on native QEMU features.
One of the most striking aspects of this implementation is that the hypervisor remains virtually untouched. Unlike other virtualization platforms where persistent components or specific services are deployed on hosts, during this test no additional Veeam packages or permanent agents were installed inside the Proxmox nodes or the protected virtual machine.
The test setup consisted of a Proxmox VE 9 cluster with two nodes, an independent Veeam Backup & Replication 13.1 installation, and a Windows virtual machine with a 40 GB disk.
The main actor is the worker virtual machine
In reality, the heavy lifting is performed not by the Proxmox node but by a virtual machine called the worker.
During the backup process, Veeam:
- Automatically reconfigures the worker.
- Starts it when the backup begins.
- Checks via QEMU Guest Agent that the system has booted properly.
- Executes the backup.
- Shuts down the worker again once the process completes.
This explains why, in a typical Proxmox plugin setup, these workers remain powered off most of the time and only activate when participating in a backup job.
Direct communication with QEMU
Another interesting observation came from analyzing the QEMU Machine Protocol (QMP) monitor of the protected VM.
While the backup was running, a manual query to the monitor returned a timeout. Normal operation resumed once the backup was finished.
This is solely an observation from this specific environment, not a documented limitation by Veeam or Proxmox. Still, it suggests that during the backup, administrative operations on that VM—such as manually creating a snapshot or initiating live migration—should be avoided.
The worker never opens the disk directly
The most intriguing part of the analysis emerged from inspecting QEMU processes.
It initially seemed logical that the worker would open the protected machine’s storage volume directly. However, that’s not the case.
During testing:
- The QEMU process of the worker did not keep any descriptor open on the VM’s disk.
- The QEMU process of the protected VM was the one holding the disk open.
- This same process was running a NBD (Network Block Device) server listening on the loopback interface.
- The worker’s QEMU simply connected to this NBD export.
Capturing the traffic between these processes revealed the initial handshake of the protocol, showing the NBDMAGIC and IHAVEOPT strings—features of the NBD protocol.
In other words, the disk is never directly passed to the worker. It receives an export created by the protected VM’s QEMU using native hypervisor mechanisms.
How snapshots fit in
This observation also clarifies how snapshots behave.
During backup, the VM’s ongoing writes are stored according to the snapshot configuration—be it on the LUN itself or on external temporary storage.
Regardless of this setup, the worker continues reading data from the NBD export provided by the QEMU of the protected VM, without directly accessing the physical volume.
This detail dispels the common misconception that the snapshot must be presented as a separate volume for the worker to read it.
An important consideration for production
Beyond the technical operation, one critical requirement should be noted before deploying this solution in enterprise environments.
Veeam’s documentation states that access to Proxmox hosts requires an account with root privileges or with the ability to elevate privileges to root. Currently, SSH key-based authentication or MFA-protected accounts are not supported for this access.
In organizations with strict hardening policies or privileged access controls, this point must be carefully planned, as it may necessitate specific security exceptions.
Although Veeam masks much of its internal workings with Proxmox VE, this lab demonstrates that the process primarily leverages existing QEMU capabilities, especially disk exports via NBD. The mechanism avoids installing permanent software on hosts and minimizes hypervisor impact by delegating processing to a temporary virtual machine managed automatically by the backup platform.
