Backup & Replication 13.1 shipped on July 29 with the two Proxmox VE features everyone was waiting for: replication and Instant Recovery. Here is what works today, what remains on the roadmap, and how to leave VMware without betting the company on the move.
01 — The two features everyone was holding out for
For two years, the same conversation has repeated in every VMware renewal review we run. The customer wants off VMware. The renewal quote made the decision for them. Proxmox VE is on the shortlist because the numbers work, and we walked through those numbers in Field Notes No. 01.
Then somebody asks the adult question: what happens to our disaster recovery?
Until this week, the answer was a compromise. Veeam has backed up Proxmox VE since 2024, but two capabilities that VMware shops treat as table stakes were missing: VM replication and Instant Recovery. Veeam's own forums filled up with IT teams and service providers saying they were holding migration projects on those two features alone.
On July 29, Veeam shipped Backup & Replication 13.1. Both features are in it.
02 — What shipped
Straight from Veeam's What's New documentation, dated the same day.
Replication for Proxmox VE. VM-level replica jobs, including direct host-to-host replication without shared storage and cross-data center replication. Replicas can land on a different storage type than the source. True replica semantics, rather than a backup copy with extra steps.
Instant Recovery to Proxmox. Boot a VM on Proxmox VE directly from a backup of nearly any platform Veeam protects, then migrate it to production storage. Sources include vSphere, Hyper-V, Nutanix AHV, physical servers via Agent, AWS, Azure and Google Cloud. The source list is the whole point.
The boring plumbing. VirtIO drivers are injected automatically when you restore a non-Proxmox VE backup onto Proxmox VE, and restored VMs can carry VLAN tags. Veeam calls the VLAN feature out as being for migration scenarios, which tells you how they expect this to be used.
Veeam's framing in the same document: workload migrations are accelerating, and Veeam is built to move with them. The subtext is loud. The same release added five more hypervisors to the supported list. Veeam is positioning itself as the portability layer for the post-Broadcom data center.
03 — The question everyone will ask
So can I replicate my VMware environment to a Proxmox VE target?
No. Replica jobs in 13.1 run Proxmox VE-to-Proxmox VE only. Cross-hypervisor replicas are absent, and continuous data protection for Proxmox VE is absent too. What you can do across hypervisors is restore-based: back up the VMware VM, then restore it, or Instant Recover it, onto Proxmox VE. The practical difference is the recovery point.
- Replica-based DR: a warm standby VM and a recovery point measured in minutes. In 13.1 this requires Proxmox VE on both ends.
- Restore-based DR: a recovery point equal to your backup frequency, and a recovery time equal to a restore, or to a boot-from-backup with Instant Recovery. Works VMware to Proxmox VE today.
- The status caveat: Instant Recovery to Proxmox VE ships under Veeam's experimental support status. It works, and Veeam will take your ticket, but nobody should write it into a contractual RTO yet.
Our publishing rule is that the fine print sits next to the promise. Instant Recovery to Proxmox VE is real and it is useful, and it is also labeled experimental in this release. We treat it as the bonus path until it graduates, and we quote recovery times from timed full restores, because that is the number a business can hold us to.
04 — The DR-first migration
Here is the play this release enables, and it is the safest VMware exit pattern we know how to run.
Phase 1, now: keep VMware. Point your DR at Proxmox VE. Production stays exactly where it is. Your Veeam backups gain a second life: on a schedule, restore the important VMs onto a Proxmox VE environment and prove they boot, network, and serve. Recovery stays restore-based, with the recovery points you already run. The part I like most is that every DR test is now a migration rehearsal. Instead of wondering whether your workloads could run on Proxmox VE someday, you watch them run on Proxmox VE this quarter, with a stopwatch out, while VMware still carries production.
Phase 2, at renewal: cut over on your schedule, not Broadcom's. When the renewal numbers say go, the cutover is the procedure you have already run: final backup, restore to Proxmox VE, validate, move the network. If an application misbehaves on the new platform, restores run in both directions, so the retreat path is the same tool as the advance path. That symmetry is what makes this a safety net instead of a trapeze.
Phase 3, after: real replication, Proxmox VE on both sides. After the cutover, your production Proxmox VE cluster replicates, VM by VM, to a second Proxmox VE site, including a different data center on different storage. Now you have warm-standby DR with tight recovery points, on the platform you just moved to, from the backup vendor you already own.
If the ransomware recovery playbook taught one lesson, it is that recovery is a sequence you rehearse rather than a product you buy. That lesson stands. This release just makes the rehearsal cheaper and the sequence portable.
05 — The fine print that belongs in your plan
We verified these against the release notes and Veeam's forum statements this week. Plan around them.
- Missing: Cloud Connect support at initial release. Confirmed by Veeam product management on the R&D forums. The classic multi-tenant model, replicate to your service provider, has yet to arrive for Proxmox VE. Provider-side replication has to be built co-managed, with one backup server that can see both sites. Watch this one: when Cloud Connect lands, Proxmox VE DRaaS becomes turnkey.
- Experimental means experimental. Instant Recovery and granular RBAC for Proxmox VE both carry experimental support status in 13.1. Useful in a rehearsal, though never something to write into a contractual recovery time until Veeam graduates them.
- Replica jobs have rough spots. From the release notes: a replication job can fail when a source disk's size sits off the target storage's block-size boundary, and TPM devices ignore per-VM storage mapping for now.
- RHEL 10 family restores need one setting. RHEL, CentOS and Rocky 10, restored onto Proxmox VE from another hypervisor, may refuse to boot until you change the VM's processor type from the default x86-64-v2-AES to x86-64-v3. One line in VM settings, easy to script, brutal to discover at 2 a.m.
- Version floors. You need Backup & Replication 13.1 with the version 13.4 Proxmox plug-in, and Proxmox VE 8.2 through 9.2. Keep in mind that v13 dropped vSphere 6.x support entirely, so the longer a legacy environment waits, the fewer doors stay open.
- Backups are still the foundation. A replica will never be a backup. It happily replicates your ransomware along with your data. Everything in Field Notes No. 04 still applies: at least one copy immutable, isolated from production credentials, and restore-tested. Replication raises availability. Immutability is what gets you back when an attacker is inside.
A word on Nakivo. Veeam is the tool this piece covers because it is what most of our customers already own, and this release means they can keep it through a Proxmox VE move. If you are shopping rather than standing pat, Nakivo deserves a serious look. It shipped agentless Proxmox VE backup, replication and instant recovery ahead of Veeam, it is an official Proxmox VE solution provider, and in the quotes that cross our desk it tends to land at roughly half the cost of comparable Veeam licensing. It is a good product, and we say that as a shop that quotes both. The takeaway is the same either way: the Proxmox VE DR tooling grew up, and whichever backup vendor you pay probably supports it now.
06 — How we run this at ModernOps
We built our managed recovery practice in two forms, and this release slots into both. In our co-managed model, we operate the customer's existing Veeam estate: we add a Proxmox VE recovery environment, schedule the restore tests, run the stopwatch, and keep the runbook current. In our hosted model, replication and restores flow into Proxmox infrastructure we operate in our Pennsylvania and Arizona data center regions, pre-staged and isolated from the customer's production credentials, with Backup as a Service underneath it on enterprise storage with immutability built in.
The new 13.1 capabilities change our answer to one question we hear weekly. When a mid-market IT director asks whether they can get off VMware without gambling their disaster recovery, the answer is now: keep VMware, DR onto Proxmox VE with us, rehearse until the timings bore you, cut over when your renewal calendar says so, and fail back if you ever need to. We will run the stopwatch either way.
07 — The 60-second exit-readiness check
- You know your VMware renewal date and the current quote, per core, in writing.
- You have booted one of your production workloads on Proxmox VE, from your own backups, in the last quarter.
- Your recovery point for Tier 1 systems is written down, and restore-based DR meets it, or the plan gets you to Proxmox VE-to-Proxmox VE replication.
- At least one backup copy is immutable and outside production credentials, on both the old platform and the new one.
- If the cutover went wrong at hour six, you know in minutes how long the restore back to VMware takes.
A "no" is simply the next item on the rehearsal schedule. If the renewal clock is already ticking, this is exactly the work our free Rapid Infrastructure Resiliency Assessment scores.
08 — Sources
- Veeam, Backup & Replication 13.1 Release Notes, GA July 29, 2026
- Veeam, 13.1 What's New, Hypervisor Protection section
- Veeam R&D Forums, Proxmox VE replication scope and Cloud Connect timing
- Veeam Help Center, Restore to Proxmox VE, supported source workloads and Proxmox VE 8.2 to 9.2
- NAKIVO, Proxmox VE replication and Instant Recovery documentation
- ModernOps Field Notes No. 01, No. 02 and No. 04: the economics, the sequence and the rules this builds on
Originally published at modernops.com.
Disclosure: I work for ModernOps, and section 06 describes our own managed recovery services. The product capabilities and limitations above are drawn from Veeam's public documentation and forum statements listed in Sources. Verify them against your own versions before you build on them, and expect the details to shift as 13.1 matures.
