Beyond Proxmox Backup Server: When Do You Need More?

A lot of companies are moving to Proxmox VE. It is a solid hypervisor, it is straightforward to run, and the licensing suits teams that want more freedom in how they build their infrastructure. Once the migration starts, the next question is always the same: how do we back this up?

For many environments the answer is Proxmox Backup Server, and that is the right answer. PBS comes from the same company, plugs straight into Proxmox VE, and works well. You get incremental backups, deduplication, encryption, replication, file-level restore from VM and container backups, live restore that starts a VM while the data is still being copied, and tape support. If Proxmox is all you run and you keep backups for weeks or months, there is no reason to add a second product.

The question worth asking is a different one. Not “which backup software is best,” but “when does PBS stop being enough for us?”

Where teams start looking for more

Usually it has nothing to do with what PBS does badly. It has to do with everything sitting 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.

What DPX 4.16 does for Proxmox

Protection is agentless. Nothing is installed inside your virtual machines. DPX reads VM data through the Proxmox API and a DPX plugin on the Proxmox host, and writes it 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.

One detail worth knowing when you plan formats: 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. That is a Proxmox platform behaviour rather than anything DPX does, but if you have a choice of format for the machines you 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. And when a job covers many VMs and a few of them fail, the job 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.

Two practical points for planning. You need Proxmox VE 8.4 or later, because the integration uses the backup plugin API that arrived in that version. And the connection to Proxmox runs through storage plugins written in Perl, published as plain source in a public Catalogic repository under AGPLv3, as Proxmox requires for storage plugins. The code that runs on your hypervisor hosts is code you can read.

What the storage layer adds

This is the part that is easy to miss, and it is where the difference from a Proxmox-only setup is widest.

DPX gives every protected virtual machine its own volume on vStor, and each successful backup seals a snapshot of that volume as a recovery point. Those are ordinary vStor volumes, which means everything vStor does to a volume applies to your Proxmox backups:

Immutability. Lock a volume so its snapshots cannot be deleted or altered before their retention expires, including by an administrator whose credentials have been stolen. Ransomware that reaches your backup storage cannot remove the recovery points you need.

Replication to a second site. vStor replicates volumes to a partner appliance, snapshot-based and asynchronous, sending only changed blocks. Your Proxmox backups get an offsite copy without a separate replication product or a second backup job.

Offload to object storage. Push older recovery points out to S3-compatible or cloud object storage for long-term retention, with S3 Object Lock available where the target supports it. Keeping seven years of data does not mean buying seven years of local disk.

Ransomware scanning. DPX GuardMode can scan vStor snapshots for signs of encryption and suspicious file activity, so you find out a recovery point is contaminated before you restore from it rather than after.

Getting individual files back. Each recovery point is a mountable snapshot, and vStor Snapshot Explorer lets you mount one, browse the filesystem inside the machine’s disks from the vStor interface, and recover individual files or folders — including straight to a network share. A single deleted file does not have to turn into a full VM recovery, and because Snapshot Explorer reads the snapshot directly, it still works when the backup catalog is unavailable.

None of these require anything extra on the Proxmox side. They are properties of where the backups land.

One platform through the migration

This is the part that matters most for companies in the middle of leaving VMware.

A migration of any size takes two or three years. Throughout that period you are running both hypervisors, plus whatever physical servers never get virtualized. Protecting them with separate products means separate schedules, separate retention rules, separate reports and separate people who know how each one works, exactly when the team is trying to simplify things.

With DPX, Proxmox sits in the same interface as VMware, physical servers and the other workloads DPX supports. The same job model, the same retention policies, the same reporting, the same backup storage underneath. When the migration finishes, nothing about your backup setup needs to change; you simply stop creating VMware jobs. And if the migration stalls halfway, which happens more often than anyone plans for, you are not stuck running two backup systems indefinitely.

Which one fits

The useful comparison is not feature by feature. It is what you actually need.

The pattern is simple. If Proxmox is the whole picture, PBS is the better answer and you should stay with it. If Proxmox is one platform among several, and your requirements run past the hypervisor into immutability, offsite copies, long retention and central reporting, that is where DPX fits.

Closing

Proxmox is giving infrastructure teams a genuine choice again, and with it a second choice about how to protect what they build. Both answers are defensible.

For Proxmox-only environments, PBS is a strong product and well worth keeping. For companies running several platforms, holding data for years, and answering to auditors across the whole environment, DPX 4.16 brings Proxmox into a backup platform that already covers the rest of what you run.

Full details are in the DPX 4.16 documentation.