Proxmox VE handles virtualisation. It doesn't, on its own, protect what's running on it — that's a separate decision every Proxmox deployment has to make. The three realistic Proxmox backup solutions available are Proxmox Backup Server (PBS), the native option built by the same company; NAKIVO Backup & Replication, a third-party platform with dedicated Proxmox VE support; and rolling a custom setup out of ZFS snapshots, rsync and cron. Each has a real place — the question is which one fits the environment actually being protected, not which one sounds most impressive on paper.
Proxmox Backup Server: the native option
PBS is Proxmox's own backup platform, and for a large share of Proxmox VE deployments it's the obvious starting point simply because it's built for the same virtualisation layer by the same team. It backs up VMs and LXC containers with client-side deduplication at the chunk level — new backups only upload the data blocks that have actually changed, using QEMU dirty bitmaps to identify them fast, rather than re-reading and re-transferring an entire disk image every run. VM data is broken into fixed-size chunks and container/host data into variable-size chunks, both checksummed so identical blocks across multiple VMs — the parts of an OS image every VM shares, for instance — are stored once rather than once per VM.
Backups can be encrypted client-side with AES-256-GCM before they ever leave the source, and PBS's own archive format (pxar) supports granular file-level restore from an image backup without needing a full VM restore first. Retention is handled with prune and garbage-collection jobs rather than manual deletion, and verify jobs can be scheduled to confirm stored chunks are actually intact — catching quiet storage corruption before it's discovered at restore time.
PBS is also fully functional without a paid subscription — deduplication, encryption and the incremental-forever model all work on the no-subscription repository. A subscription buys access to the enterprise package repository and support, priced per backup server per year rather than per socket or per VM: Community starts at €560, rising through Basic (€1,120) and Standard (€2,240) to Premium (€4,480), with every tier covering unlimited storage and unlimited clients on that server.
For a single-cluster deployment that's staying on Proxmox VE and doesn't need to protect anything outside it, PBS does the job cleanly, and the subscription cost is genuinely optional rather than a functional gate.
NAKIVO for Proxmox VE: what it adds
NAKIVO's case is different: it doesn't compete with PBS on Proxmox alone, it competes on everything a Proxmox VE cluster typically sits next to. NAKIVO Backup & Replication backs up Proxmox VE agentless, at the host level, with full and incremental backups using either Proxmox's own change tracking or NAKIVO's own change-block-tracking method, plus image-based and app-aware backup for consistent recovery. Flash VM Boot brings a protected VM back online in seconds rather than waiting on a full restore, and granular recovery pulls individual files and folders out of a backup to either the original or a custom location.
Where it earns its licence cost over PBS is everywhere Proxmox isn't the whole story. The same NAKIVO deployment that protects a Proxmox cluster also covers VMware vSphere, Hyper-V, Nutanix AHV, AWS EC2 and Microsoft 365 from one console — genuinely useful for an environment mid-migration off VMware onto Proxmox, or one that's landed on Proxmox for new workloads while older VMware hosts are still running out their hardware life. Replication extends to Proxmox VE VMs across a wide range of storage backends — local ZFS, BTRFS, CephFS, LVM-thin, Ceph/RBD, ZFS over iSCSI, SMB/NFS and GlusterFS — for failover targets that don't have to match the production storage layer exactly. Immutable backups land on S3, Wasabi, Azure Blob or Backblaze B2, with AES-256 encryption at source, in transit and at rest, and an air-gapped copy option via tape or detached storage for the ransomware scenario where even the backup repository gets targeted.
The trade-off is straightforward: NAKIVO is a licensed product sitting on top of the infrastructure it's protecting, where PBS is free at its core. That cost buys a single pane of glass across a mixed hypervisor estate and a wider set of replication and immutability targets — value that's real for a multi-platform environment and largely wasted on a Proxmox-only shop that will never open the VMware or Hyper-V modules.
Rolling your own: ZFS snapshots, rsync, and why it's riskier than it looks
The third option shows up constantly in Proxmox forums: skip both platforms and build a backup process out of ZFS snapshots, replication and a bit of scripting. It's cheap, it's transparent, and for a homelab or a single low-stakes VM it can be entirely reasonable. For anything a business actually depends on, it comes with sharper edges than it looks like it has.
The first is consistency. When Proxmox VE takes a backup or snapshot through its own mechanism, it can freeze the guest filesystem and flush its cache to disk first, so what's captured is application-consistent. A ZFS snapshot triggered outside that mechanism doesn't do that automatically — it captures whatever state the disk happens to be in at that instant, which is usually fine for a crash-consistent restore but is a real risk for anything with an open database or an application mid-write. The second is scope: a snapshot-and-replicate script backs up the disk, but the VM's configuration — CPU, memory, network and storage mappings — lives in a separate config file that's easy to leave out of the script, and its absence is the difference between a fast restore and a slow one at the exact moment a fast one matters. The third is that ZFS itself, while mature, isn't infallible — a serious ZFS bug can affect production and its snapshots at the same time, since a snapshot on a broken pool is still a snapshot of a broken pool, not an independent copy on different infrastructure.
None of this makes ZFS snapshots useless — used well, they're a legitimate part of a layered strategy, and tools like Sanoid exist specifically to manage snapshot scheduling and retention properly rather than leaving it to a one-off cron job. The point is narrower: a roll-your-own setup replaces a platform whose backup and restore path has been tested by a large user base with one whose reliability depends entirely on whoever wrote the script, and the honest way to price that option isn't "free" — it's "free until the person who understands it leaves, or until it's needed under pressure and doesn't work exactly as remembered."
Choosing among Proxmox backup solutions
For a Proxmox-only environment with no other hypervisor to worry about, PBS is the sensible default — it's built for exactly this, costs nothing to start with, and the paid tiers only matter once support and the enterprise repository are worth paying for. For an environment running Proxmox alongside VMware, Hyper-V or a meaningful Microsoft 365 footprint, NAKIVO is worth the licence cost for the single console and the wider set of replication targets alone — protecting three platforms through three separate tools is its own ongoing cost, it just doesn't show up on an invoice. ZFS snapshots and scripting have a real place as a supplementary layer — fast local rollback alongside a proper backup platform — but shouldn't be the only copy of anything the business can't afford to lose.
Proxmox itself remains the platform decision underneath all three; see our Proxmox vs VMware comparison for how the migration case stacks up before the backup question even comes into it.
Sources: Proxmox Backup Server pricing, Proxmox Backup Server subscription cost breakdown — Zmanda, Proxmox Backup Server enterprise overview — Stackscale, What Proxmox Backup Server is and why you should use it — HorizonIQ, NAKIVO Proxmox Backup Solution, NAKIVO Proxmox VE Backup — Help Center, NAKIVO v11.2: Proxmox VE 9.0 support — BleepingComputer, ZFS Snapshot Replication for Automated VM Backup — GnTech, Best practice for Proxmox self-backup — Proxmox Forum