Setting Up Veeam v13 with Proxmox VE: A Complete Integration Guide

The VMware Exodus and What It Means for Backup

If you've spent the last couple of years watching VMware licensing costs climb after the Broadcom acquisition, you probably already know where a lot of those workloads landed. Proxmox VE absorbed a huge chunk of the VMware refugee population, and honestly, for good reason. It's open source, it's mature, it runs KVM under the hood, and it does the job without a per-socket subscription renewing on you every year.

The backup question always comes right after the migration question. You moved your VMs. Now how do you protect them? If you're already running Veeam for Windows, Linux, or any remaining VMware infrastructure, the answer in v13 is cleaner than it's ever been. Proxmox VE is a native platform in VBR now. Same console, same job wizard, same repository targets. This guide walks through the complete setup from scratch.

Fair warning up front: the Proxmox integration has some real architectural differences from what you might be used to with VMware or Nutanix, and a longer limitations list than either of those platforms. I'll call out the important ones as we go so you're not caught off guard after you're already mid-deployment.

How It All Fits Together

Like the Nutanix AHV integration, Veeam uses a worker VM model for Proxmox. A worker is a lightweight Linux VM that Veeam deploys onto your Proxmox host to handle the actual data movement. VBR coordinates the jobs and manages the infrastructure side of things. The worker is what reads VM data and transfers it to the repository.

The most important thing to understand about Proxmox workers is that they are not persistent. Veeam powers the worker on when a backup or restore session starts and shuts it down automatically when the session ends. On AHV, workers stay running between jobs. On Proxmox, they spin up, do the work, and shut back down every time. This is by design. The worker VM will appear in your Proxmox inventory during backup windows and sit stopped between sessions. That's normal, not a problem.

Changed Block Tracking is supported for Proxmox VMs and uses QEMU Dirty Bitmaps. During the first full backup, Veeam creates a bitmap for each disk attached to the VM. On subsequent runs, it reads those bitmaps to find only what changed since the last session, which is how you get fast incrementals instead of full reads every time.

There's a real gotcha here you need to know about: for VMs with disks in RAW or VMDK format, QEMU automatically removes the bitmaps whenever those VMs are powered off or restarted. If a VM rebooted between backups, Veeam has no bitmap to read and falls back to processing the full disk for that session. This is a Proxmox technical limitation, not a Veeam issue. It affects disk format decisions and is worth factoring into your design if you have VMs that reboot regularly.

VBR connects to each Proxmox node directly over SSH on port 22. There is no cluster-level management endpoint in Proxmox the way Prism Central works in the Nutanix world. Every node is its own connection. If you're running a Proxmox cluster, you add each node individually to VBR.

Before You Start: Requirements and Hard Stops

Work through this table before you open any wizard. A few of these are hard stops that will block you if you hit them mid-setup instead of before.

A Word on Licensing

Same deal as Nutanix: Proxmox workloads require Veeam Universal License (VUL). Each protected VM consumes one instance. If you're running a mixed environment with some VMware VMs on socket-based licensing and new Proxmox VMs alongside them, those Proxmox VMs need VUL instances. The socket license doesn't cover them.

For shops that came from VMware specifically, this is usually the first licensing conversation. Your old VMware socket licenses don't convert to VUL automatically. Talk to your Veeam account team before assuming you're already covered.

Step 1: Add the Proxmox VE Server to VBR

Unlike Nutanix where you add a single Prism Central connection and get visibility across all clusters, Proxmox requires adding each node individually. Three-node cluster means three additions. Budget the time accordingly.

Step 2: Configure Your Backup Repository

Proxmox backup jobs support the same repository types as other VBR workloads. Standard Windows and Linux repositories, CIFS shares, deduplication appliances, and Scale-Out Backup Repositories all work. Two things worth calling out before you pick your target:

HPE Cloud Bank Storage cannot be used as a primary backup job target for Proxmox VMs. It can be used for backup copies. If that's part of your architecture, route primary Proxmox jobs to a standard repository and use a backup copy job to move data there.

Repository-level encryption is supported. Job-level encryption is not supported for Proxmox backup jobs. Set encryption at the repository and it applies to everything landing there automatically.

Also think about the network path between your Proxmox nodes and your repository. Workers run directly on Proxmox hosts and transfer data straight to the repository target. The throughput on that path determines whether you hit your backup window.

Step 3: Deploy Worker VMs

Workers on Proxmox are ephemeral per session. Veeam powers them on when a job starts and shuts them down when it ends. The worker VM sits in your Proxmox inventory as a stopped VM between sessions. That's normal behavior, not a deployment failure.

Step 4: Create a Backup Job

Servers added, workers deployed. The job wizard should feel familiar at this point.

Step 5: Verify and Monitor

After the first job run, open Home > Last 24 Hours and work through this:

• Job status: Success or Warning. Read every warning on the first run. Most first-run warnings point to guest processing credential issues or VMs on nodes without workers deployed.
• From run two onward, confirm VMs are processing incrementally. If you see full backup mode on a VM that didn't reboot, dig into the job log to understand why the bitmap wasn't held.
• Confirm restore points appear in Backups > Disk for all protected VMs.
• The worker VM should show as stopped (not missing) between backup windows. A completely absent worker VM means the deployment failed and needs to be redeployed.

Set up email notifications in Options > E-mail Settings if you haven't already. In the first few weeks of a new Proxmox integration, you want to be watching every job result closely while credentials, scope, and storage behaviors settle in.

Known Limitations Worth Knowing

These are all confirmed from the official Veeam v13 documentation. Read through them before you finalize your protection design:

• IPv6 is not supported. Everything communicates over IPv4.
• Open vSwitch networking is not supported. Linux Bridge is required. Workers and guest processing will fail in OVS environments.
• BTRFS storage is not supported for VM disks or worker deployment.
• Custom storage types are not supported. All other Proxmox VE storage types are supported for VM protection.
• S3 buckets connected as Proxmox storage are not supported. VMs residing on S3-connected Proxmox storage cannot be backed up.
• SSH private key credentials are not supported. Username and password only.
• MFA accounts cannot be used for the Proxmox server connection.
• NAT gateway connections are not supported. VBR needs a direct path to each node.
• FQDNs in the server name field are not supported. Use hostname or IP.
• Renaming the Proxmox cluster after adding nodes to VBR breaks the integration. All nodes must be removed and re-added.
• OCSP certificates are not supported for accessing the Proxmox VE server.
• Job-level encryption is not supported. Set encryption at the repository level.
• LXC containers, VM templates, and linked clones cannot be backed up. Full clones are supported.
• iSCSI disks attached to VMs are automatically skipped. Passthrough (directly attached) disks are also skipped.
• VMs with duplicate BIOS UUIDs cannot be backed up.
• VM permissions (user, group, API token grants) are not backed up.
• VM replication is not supported for Proxmox VE workloads in the current release.
• QEMU dirty bitmaps for RAW and VMDK disks are removed on VM power off or restart. Veeam falls back to a full read for that session when bitmaps are gone.
• Concurrent backup operations per storage are limited to 4 by default. Contact Veeam Support to raise this limit.
• VLAN-tagged environments require manual VLAN ID assignment on worker VMs after deployment or redeployment.
• HPE Cloud Bank Storage cannot be used as a primary backup job target for Proxmox VMs. Backup copies to Cloud Bank Storage are supported.

Closing Thoughts

The Proxmox integration in Veeam v13 is genuinely solid. But the limitations list is longer than what you'll see with Nutanix or VMware, and that's worth being honest about. Some of those limitations, like the RAW/VMDK CBT behavior and the per-storage concurrency cap, have real operational implications that you want to discover before deployment rather than during your first major backup window.

The three questions that determine whether this works in your environment at all: was Proxmox installed from the official ISO, are you running Linux Bridge or OVS, and what storage types are your VMs sitting on. Get clear answers to those first. Everything else in the setup is straightforward once the prerequisites are confirmed.

And if you're running a mixed environment with VMware still in play alongside Proxmox, VBR handles both from the same console without issue. That consolidated management is genuinely one of the best things about the platform, and it works exactly as advertised.