Veeam’s per-workload (VUL) subscription rises with every VM you protect, and the socket-to-instance licensing changes pushed many renewals sharply upward. For teams already moving their hypervisor to Proxmox VE, or just looking to cut backup spend, Proxmox Backup Server (PBS) is the natural destination: deduplicated, incremental-forever backups with optional immutability, tightly integrated with the Proxmox scheduler, and free of per-workload licensing. The critical mindset: backups don’t migrate, you re-protect workloads and let the old chain age out.
Why backups are re-baselined, not copied
You cannot meaningfully convert a Veeam backup chain into a PBS datastore, the formats, dedup, and metadata are entirely different. Instead you stand up PBS, point your workloads at it, and take fresh full backups on the new platform. The Veeam repository stays read-only and retained until its retention (and any legal-hold) obligations age out. This is normal and safe; the risk is deleting the old chain too early, not the re-baseline itself.
What you gain, and what you give up
PBS gives you content-addressable deduplication across the datastore, incremental-forever backups with fast restores, verify jobs that re-check backup integrity, and optional immutability for ransomware resilience, at no license cost. You give up Veeam’s breadth: application-aware processing for a wide range of enterprise apps, SureBackup automated restore testing, and the polished multi-platform console. For VM-centric Proxmox estates, PBS covers the core need well; for heavy physical-server or broad application-aware backup, scope the gap honestly.
The dedup story usually surprises teams in a positive direction. Because PBS deduplicates at the chunk level across the whole datastore, VMs that share an OS image or common data collapse together, and the incremental-forever model avoids periodically re-writing full synthetic backups. That tends to shrink effective storage per protected TB, but the ratio you actually achieve depends on your workloads, so measure it on real data during the parallel run rather than assuming a headline figure. Size the datastore for your data plus honest dedup headroom, and remember that verify jobs and pruning also consume I/O on the same storage.
What maps and what doesn’t
Think of the move as re-expressing Veeam policy in Proxmox terms rather than porting files:
- A Veeam backup job becomes a Proxmox backup job targeting a PBS datastore, with the same set of protected VMs.
- The Veeam schedule becomes the Proxmox schedule for that job; keep the same windows so backup timing and load stay predictable.
- Veeam GFS retention (grandfather-father-son) becomes PBS prune and retention rules on the datastore or job. Translate keep-daily, keep-weekly, keep-monthly, and keep-yearly counts deliberately rather than approximating them.
- Veeam copy jobs to a second repository or object storage become PBS sync jobs to a second PBS (optionally append-only) or a remote datastore.
What does not carry over cleanly: application-aware quiescing for a broad range of enterprise applications, automated restore-verification suites, and the single multi-platform pane of glass. If a workload needs application-consistent processing that PBS does not provide natively, plan pre/post scripting or accept a scoped gap, and document the decision.
The migration flow
- Inventory Veeam jobs: protected VMs, schedules, retention (GFS), and offsite/immutable copies. Capture RPO/RTO per workload.
- Deploy PBS with a datastore on resilient storage (ZFS is common), sized for your data plus dedup headroom. Add it to the Proxmox cluster under Datacenter → Storage.
- Configure backup jobs in Proxmox pointing at the PBS datastore; set retention to match your GFS policy. Enable verify jobs and, if needed, an append-only/immutable remote sync (Proxmox Backup remote + sync jobs to a second PBS).
- Re-baseline, take first full backups on PBS while Veeam continues as primary. Keep both running in parallel.
- Test restores (the part that matters): file-level restore, full-VM restore, and a complete DR rehearsal. Confirm backup windows fit and dedup ratios are acceptable.
- Switch primary schedules to PBS once restores validate; keep the Veeam repository read-only until retention lapses, then decommission.
The re-baseline, and proving restores
The re-baseline is the load-bearing step, so plan it as a project rather than a checkbox. Your first PBS backup of each VM is a full, and until that full completes and verifies, Veeam remains the only line of defense for that workload. Stagger the initial fulls so you do not saturate the network or the datastore’s write path all at once, and prioritize the VMs whose data changes least so their chains stabilize quickly. Once the first fulls land, incremental-forever backups take over and the ongoing load drops sharply.
Restore testing is where you earn the right to switch. For each class of workload, restore into a scratch location and confirm the result: a file-level restore to check granular recovery, a full-VM restore to check boot and integrity, and at least one end-to-end DR rehearsal that exercises your immutable or offsite copy. Run PBS verify jobs so silent corruption surfaces before you rely on a backup, and put restore drills on a recurring calendar rather than treating them as a one-time gate. A backup you have never restored is an assumption, not a recovery point.
Keeping the old repository around
Do not delete the Veeam repository on day one. Keep it read-only and intact until every restore point it holds has aged past your retention and any legal-hold requirement. During that overlap window, new backups go to PBS while pre-cutover restores still come from Veeam, and you retire the Veeam infrastructure only after its last obligated restore point expires. Pulling the old repository early to stop paying for it a few months sooner is exactly how teams discover, mid-audit or mid-incident, that a point they were required to keep is gone. Budget for the parallel-run overlap as a real cost of the migration, because that double-running window is where the project actually spends money.
Immutability and the 3-2-1 rule
Don’t lose your offsite/immutable copy in the move. PBS supports sync jobs to a second PBS (which can be append-only) and backup to remote datastores, plus you can layer object-storage targets. Recreate your 3-2-1 posture on the new platform before you trust it as primary, a single PBS instance is not a DR strategy.
The bar for cutting over
Treat “we can restore the workloads we care about, within RPO/RTO, including a full DR failover” as the acceptance bar, not “backups are green.” Run real restores, verify immutability/ransomware recovery end to end, and confirm the verify jobs pass. Only then retire Veeam on a schedule.
Is it worth switching?
Veeam → Proxmox Backup Server is a re-protection project, not a data copy: stand up PBS, re-baseline in parallel, prove restores and immutability, then age out the Veeam chain. The savings are real for VM-centric estates; the risk is operational discipline around retention and DR. Model your per-workload savings in the calculator above, and treat the figures as illustrative until you confirm your retention and DR requirements.