Catalogic Software

HomeBlogBeyond Proxmox Backup Server: When Do You Need More?

Beyond Proxmox Backup Server: When Do You Need More?

· 7 min read

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 situationBetter fit
Proxmox is all you run, backups kept for weeks or monthsProxmox Backup Server
You regularly pull individual files out of VM backupsEither. PBS restores files from the backup itself; DPX does it through vStor Snapshot Explorer.
You back up LXC containers as well as VMsProxmox Backup Server (DPX covers QEMU VMs)
Still on Proxmox VE 8.3 or olderProxmox Backup Server (DPX needs 8.4+)
Running VMware and Proxmox side by side during a migrationDPX
Physical servers or file servers to protect as wellDPX
Immutable backup storage and ransomware scanning are requirementsDPX
Offsite replication and long-term retention in object storageDPX
Several Proxmox clusters you would rather manage as oneDPX
One set of reports and audit records across sites and systemsDPX

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.

Share this article

Pawel Staniec

Pawel Staniec

CTO

Pawel is CTO at Catalogic Software, where he owns DPX product architecture and technology direction and works with our developers, alliance partners and customers across EMEA to keep what we build aligned with how our data protection products are actually deployed. He writes about the engineering behind our releases, including NDMP backup management, Proxmox VE protection, and where hypervisor-native backup tooling stops being enough.

LinkedIn Profile 28 articles by this author