Migration
Backup design for a VMware to Proxmox migration
Migration projects budget for compute and storage and forget that the backup product is changing at the same time. Designing the PBS layer while the VMs are still moving is far cheaper than retrofitting it once they have landed.
What changes when you leave VMware
- Backup becomes PBS-shaped: chunk store, dedup, prune, garbage collection, verify jobs
- Capacity planning shifts from full-plus-incremental thinking to deduplicated chunk growth
- Restore testing has to be re-established — your old runbook assumes a different product
- PVE host configuration (cluster, storage, firewall, jobs) needs its own backup, which VMware-era runbooks never covered
- Licensing arithmetic changes, which is usually what funded the migration in the first place
Do this during the migration, not after
Each of these is dramatically cheaper while the estate is already in motion.
- Size the PBS datastore against measured dedup ratios from the first migrated workloads, not a vendor rule of thumb
- Decide retention against what your auditors and insurers actually require
- Stand up the offsite copy before production lands, not in the quarter after
- Set prune and GC windows that do not collide with the backup window at full load
- Enable client-side encryption from the first job rather than re-seeding later
- Prove one restore per workload class — database, file server, application — before cutover
What we bring to a migration
- Proxmox Silver Partner engineers who do these migrations as the day job
- Backup design delivered as part of the migration rather than as a later project
- A documented restore of a nominated VM before you call the migration complete
- Handover documentation your team can operate from, if you would rather run it yourself
Questions people ask on this
Can we keep Veeam and point it at Proxmox?
Support for Proxmox outside the VMware world has improved, but it is worth asking what you are buying it for. If the migration was funded by escaping per-socket licensing, carrying a second commercial backup licence across deserves a deliberate decision rather than inertia. PBS is free, native, and deduplicates well against Proxmox workloads. Run the numbers both ways — we will help even if the answer is that you keep what you have.
How do we size the PBS datastore?
Not from a rule of thumb. Migrate a representative slice first, measure the actual dedup and compression ratio on your data, then extrapolate with headroom for retention growth. Sizing from a vendor multiplier is how estates end up at 90 percent full two quarters in, at which point jobs start failing and the fix is a procurement cycle away.
When in the migration should backup be designed?
Before the first production workload lands. The expensive version of this project is the one where three hundred VMs are already running on Proxmox and somebody asks where the offsite copy is.
We are a Proxmox customer already. Does this apply?
If your estate grew organically rather than being designed, much of it will. The most common inherited problems are a datastore sized by guesswork and an offsite copy that was always going to be set up next quarter.
Design the backup layer while the estate is still moving
Whether the migration is ours or someone else's, we will look at the backup design before production lands. Thirty minutes, no cost.