Companies moving to Proxmox VE usually reach backup planning early in the migration. Proxmox is straightforward to run, and its licensing gives teams more freedom in how they build their infrastructure.
For many environments, Proxmox Backup Server is the right answer. It comes from the same company and plugs straight into Proxmox VE. PBS provides incremental backups, deduplication, encryption, replication, file-level restore from VM and container backups, live restore that starts a VM while its data is copied, and tape support. A Proxmox-only environment with retention measured in weeks or months may have no need for a second product.
The practical threshold comes when PBS stops covering the needs of the wider environment.
Where teams start looking for more
The pressure usually comes from the systems and requirements around Proxmox.
Most companies do not run a single platform. Moving off VMware takes years, and during that time both hypervisors run side by side. There are still physical servers and file servers to protect. Some data has to be kept for seven or ten years, not ninety days. Auditors want one report covering everything, not a separate console for each cluster. And backup systems tend to stay in place far longer than the hypervisor they were bought to protect.
That is the point where a broader platform starts to make sense, and it is why DPX 4.16 now covers Proxmox backup and recovery.
What DPX 4.16 does for Proxmox
DPX protects Proxmox VMs without installing software inside them. It reads VM data through the Proxmox API and a DPX plugin on the host, then writes the backup to vStor, Catalogic’s backup storage.
Backups are incremental forever. The first run copies all allocated data, and every run after that transfers only the blocks that changed. The decision is made per disk rather than per VM, so one machine can have some disks backed up incrementally and others rebased in the same run, without you having to think about it. Default retention is 90 days and you set it per job.
Disk format affects how incremental backups behave. Proxmox VE drops its change tracking for RAW and VMDK disks whenever a VM is powered off or restarted, so the next backup of that disk is a full one. QCOW2 disks keep their change tracking across a restart and carry on incrementally. This behaviour comes from Proxmox. If you can choose the format for machines that reboot often, QCOW2 gives you the smoother chain.
A single backup job can protect virtual machines across more than one Proxmox cluster. If you run separate clusters per site or per environment, that is one job definition and one retention policy instead of one of each per cluster. When a job covers many VMs and a few of them fail, DPX reports partial success. The machines that worked still produce valid recovery points, and you only rerun the ones that did not.
Restore rebuilds the virtual machine from any recovery point you pick. DPX copies the disks to whichever Proxmox storage you choose and recreates the VM with its original settings, powering it on afterwards if you want. You can restore to a different node than the one it came from, which is what you need during hardware failures and during migrations. If a VM with that name is already running, DPX creates the restored copy under a new name rather than overwriting anything. In this first release, DPX backs up and restores whole virtual machines.
Planning depends on two practical details. You need Proxmox VE 8.4 or later because the integration uses the backup plugin API that arrived in that version. The connection to Proxmox runs through storage plugins written in Perl and published as plain source in a public Catalogic repository under AGPLv3, as Proxmox requires for storage plugins. You can inspect the code that runs on your hypervisor hosts.
What the storage layer adds
The storage layer creates the clearest distinction from a Proxmox-only setup.
DPX gives every protected virtual machine its own volume on vStor. Each successful backup seals a snapshot of that volume as a recovery point. The resulting volumes can use vStor’s protection and data-movement controls:
Immutability. Fixed snapshot protection prevents a recovery point from being changed or deleted before its retention expires. vStor also provides volume deletion protection, with MFA required for deletion-protection controls.
Replication to a second site. vStor replication copies a volume to a partner system manually or on a schedule. Your Proxmox backups get an offsite copy without a separate replication product or another backup job. Replicated snapshots can also use deletion protection on the target.
Offload to object storage. Push older recovery points to S3-compatible or cloud object storage for long-term retention, with S3 Object Lock available where the target supports it. Long retention can use object capacity instead of consuming local disk for the entire period.
Ransomware scanning. GuardMode Scan checks mounted filesystems for potential ransomware infection or malicious encryption. This helps identify a suspect recovery point before it is restored to production.
Getting individual files back. vStor Snapshot Explorer can mount supported disk images from Proxmox backup snapshots. From the vStor interface, you can browse the filesystem and recover selected files or folders, including directly to a network share. This handles a deleted file without restoring the whole VM.
These capabilities live in vStor, so they require no additional software inside the protected Proxmox guests.
One platform through the migration
A unified platform matters most for companies in the middle of leaving VMware.
Large migrations can take years. Throughout that period, both hypervisors remain in service alongside any physical servers that will never be virtualized. Separate backup products bring separate schedules, retention rules, reports and operational knowledge at the same time the team is trying to simplify its environment.
DPX manages Proxmox alongside VMware, physical servers and other supported workloads. Jobs, retention policies, reporting and backup storage remain in one system. When the migration finishes, the team stops creating VMware jobs while Proxmox protection continues. If the migration pauses, both environments remain under the same backup platform.
Which one fits
Start with what your environment actually needs.
| Your situation | Better fit |
|---|---|
| Proxmox is all you run, backups kept for weeks or months | Proxmox Backup Server |
| You regularly pull individual files out of VM backups | Either. PBS restores files from the backup itself; DPX does it through vStor Snapshot Explorer. |
| You back up LXC containers as well as VMs | Proxmox Backup Server (DPX covers QEMU VMs) |
| Still on Proxmox VE 8.3 or older | Proxmox Backup Server (DPX needs 8.4+) |
| Running VMware and Proxmox side by side during a migration | DPX |
| Physical servers or file servers to protect as well | DPX |
| Immutable backup storage and ransomware scanning are requirements | DPX |
| Offsite replication and long-term retention in object storage | DPX |
| Several Proxmox clusters you would rather manage as one | DPX |
| One set of reports and audit records across sites and systems | DPX |
A Proxmox-only environment with short-to-medium retention is a good fit for PBS. DPX fits when Proxmox is one platform among several and the requirements extend to immutability, offsite copies, long retention and central reporting.
Closing
Proxmox gives infrastructure teams another credible hypervisor option. Backup strategy is a separate decision, and both PBS and DPX can be sensible choices.
PBS remains a strong fit for Proxmox-only environments. DPX 4.16 is designed for companies that need to protect several platforms, retain data for years, use immutable storage and report across the wider environment.
Full details are in the DPX 4.16 documentation.


