VBR 13.1: Proxmox VM replication - capabilities, requirements and limits

Hello everyone,

I postponed sharing material like this for a long time because most of my Veeam observations ended up in project documentation, runbooks or technical conversations. It is time to start publishing them. I have been running VBR 13.1 in production since release day, within a controlled scope. I am opening this series with the change I had been waiting for most: Proxmox is no longer only a backup platform from Veeam’s perspective.

VBR 13.1 extends existing Proxmox protection with native VM replication. It separately adds Instant VM Recovery with Proxmox as the target. The current What’s New documentation marks this particular Instant Recovery direction as Experimental Support. The detailed procedure and Release Notes do not repeat that label. It does not apply to Entire VM Restore, native Proxmox replication, or Instant Recovery of a Proxmox backup to another platform.

The technical flows

These are two distinct data paths:

replication: VBR -> Proxmox plug-in -> worker -> source host and storage -> target host and storage

Instant VM Recovery: backup repository -> worker -> VM running on Proxmox -> migration to production storage

The worker, management and transport networks, VLAN mapping and storage performance therefore become part of RTO. Creating a replica or starting a VM without testing its network, dependencies and final migration does not prove DR readiness.

What changed

VM replication covers two core scenarios:

direct host-to-host replication, including smaller environments without shared storage;
replication between data centres, including between different storage types.

VBR 13.1 also adds:

Instant VM Recovery to Proxmox from image-level backups created on other supported platforms;
VLAN tag assignment for workers and recovered VMs;
automatic VirtIO driver injection when restoring machines from outside Proxmox;
more detailed restore statistics and progress in the Web UI;
wider Proxmox coverage in the Web UI;
Advanced RBAC for Proxmox protection management.

The Web UI also offers Instant Recovery of an image-level backup from a supported hypervisor to VMware vSphere, Microsoft Hyper-V or Nutanix AHV. That is not the same as running a workload directly from backup on Proxmox. The Experimental Support label in What’s New applies to Proxmox as the Instant Recovery target, not to every restore operation involving a Proxmox backup.

Why this matters in a project

A new job type is only the beginning. DR depends on the complete chain:

backup or replica -> VM start -> correct network mapping -> migration to production storage -> application test

I see three practical uses:

building a Proxmox-based DR site without adding another hypervisor solely for recovery;
migrating workloads from VMware or Hyper-V to Proxmox using existing backups;
rebuilding faster when the post-incident target platform does not have to match the source.

Requirements and support status

For VBR build 13.1.0.411, the current documentation specifies:

Proxmox VE 8.2-9.2, installed from an official ISO;
Veeam Plug-in for Proxmox VE 4, build 13.4.0.300;
workers based on Veeam JeOS 9.6;
one VUL instance per protected VM, with the VM continuing to count as protected for 31 days after a restore point is created.

Two support boundaries deserve particular attention:

What’s New and a Veeam Product Management statement identify Instant VM Recovery to Proxmox as Experimental Support. The detailed procedure and Release Notes do not repeat that label, so I would confirm the current status with Veeam before putting the function into an SLA;
Advanced RBAC for Proxmox also has Experimental Support status.

I would not extend that caveat to Entire VM Restore, Proxmox replication or recovery of a Proxmox backup to VMware, Hyper-V or Nutanix AHV. Each operation needs to be evaluated against its own requirements and limitations.

Native LXC container protection is not part of this scenario. A project that includes LXC still needs a separate strategy for the operating system, application data and recovery.

Project-relevant limitations

Replication jobs are configured in the desktop Remote Console, not in the Web UI.
The Web UI does not present a cluster as one object; its nodes must be added individually.
During replication within the same cluster, the source VM MAC address is not retained.
A job can fail when the source disk size is not a multiple of the target storage block size.
Native protection excludes, among other items, LXC, VM templates, passthrough disks, iSCSI disks attached inside a guest, and VMs on BTRFS or custom storage.
A Cloud Repository cannot be the direct target of a Proxmox VM backup job. The backup must first land in a regular repository and then be sent to a Cloud Repository by Backup Copy. VCC supports Proxmox as the source of that first Backup Copy, but not another Backup Copy created from an existing Backup Copy. On the tenant side, recovery of a Proxmox copy stored in VCC is limited to File-Level Restore. A service provider can perform Instant Recovery to VMware vSphere and, according to What’s New 13.1, Microsoft Hyper-V. Entire VM Restore is available on the provider side to Nutanix AHV, Proxmox VE, oVirt KVM, Scale Computing HyperCore and HPE Morpheus VM Essentials. The detailed Cloud Connect Guide still lists VMware vSphere as the only Instant Recovery target. That inconsistency means Hyper-V must be confirmed for the exact build before use.

What to test before production use

My minimum test plan covers:

Host-to-host replication at one site.
Replication between sites and different storage types.
Failover, failback and restore-point behaviour.
Instant VM Recovery of a backup from another platform to Proxmox.
Operating system start after VirtIO injection and validation of application services.
VLAN mapping for both the worker and recovered VM.
Migration of the running VM to production storage and complete cleanup of the restore session.
Actual RTO and utilisation of workers, network and repository resources.

Those results matter more than a job ending with Success. The VM must boot, obtain the correct network, reach its dependencies and pass an application test.

How are you designing DR for Proxmox?

Confirming that replication works says little about long-term operations. A simple branch host-to-host design behaves differently from a second data centre with separate storage, and both differ from using Proxmox as a migration target from another platform.

I would like to compare approaches in several areas:

when replication is the right choice and when Backup Copy plus a full restore remains preferable;
how replication traffic, workers and networks for VMs started after an incident are separated;
whether source and target use the same storage type and how that affects synchronisation time;
how failover, application testing and environment cleanup are performed;
whether Instant VM Recovery to Proxmox, documented as Experimental Support, is restricted to the lab or accepted as a controlled emergency option;
what RTO is achievable with realistic VM sizes and available bandwidth.

If you already have results from 13.1, the most useful context is the exact build, a general topology, approximate VM size and the main constraint. Useful engineering data does not require customer names or sensitive details.

Sources

Has anyone tested replication between different storage types or Instant VM Recovery from VMware or Hyper-V to Proxmox? I am particularly interested in boot times, network mapping and the migration stage to production storage.