Proxmox Backup Server vs vzdump backups

Proxmox Backup Server vs vzdump: which backup approach fits your Proxmox VE estate

vzdump is enough for a small Proxmox VE estate with modest retention, while Proxmox Backup Server fits when storage growth, retention depth, encryption and restore planning start to matter. Both are open source, and both let you back up guests from the same Proxmox VE cluster. The difference is where the backups live and how they are stored. vzdump is built into Proxmox VE and writes full backups of each VM or container, including its configuration and all data, to storage such as NFS or local disks. Proxmox Backup Server is a separate client-server product, released under the GNU AGPL version 3 or later, that runs on its own host and stores backups as de-duplicated chunks with incremental runs. Proxmox's own documentation recommends a dedicated host for Proxmox Backup Server and names an NFS server as a good alternative, so the choice is partly a choice of an additional machine to build and operate.

vzdump's strengths are simplicity and few moving parts. It offers stop, suspend and snapshot modes, and snapshot mode gives the lowest downtime at the cost of a small inconsistency risk, so a team with a handful of guests, a short retention window and an NFS target can run it with little extra design. The cost shows up as storage growth: each vzdump run is a complete copy, so retention depth multiplies disk use. Before you decide, measure your current full backup size, the number of restore points you keep and the nightly change rate of your guests, then ask whether that growth fits your storage budget for the retention you need.

Choose Proxmox Backup Server when deduplication, encrypted off-site copies, or deep retention drive the design, and plan for the restore path before you commit. Confirm with Proxmox how the client-side AES-256-GCM encryption keys are stored and recovered, since losing them makes backups unusable. Check that the dedicated host has enough capacity and is itself backed up, and review the Proxmox Backup Server documentation for the datastore and client model. Test a restore of your largest guest on each option, because restore time is where the two approaches differ most in practice.

How vzdump and Proxmox Backup Server compare on backup behavior and cost drivers

This table compares how built-in vzdump backups and Proxmox Backup Server store, encrypt, grow and restore data, and what each costs to license. Read each row against your own VM count, change rate and retention needs, because storage growth and restore time depend on those inputs more than on the tool alone.

Factor	vzdump (NFS or local storage)	Proxmox Backup Server
Backup format	Always full backups containing the VM or container configuration and all data, so each run writes the complete guest	Backups stored as de-duplicated chunks and metadata, so repeated data is written once
Backup modes	Stop, suspend and snapshot. Snapshot mode gives the lowest downtime but carries a small inconsistency risk	Used through the Proxmox VE integration, which runs the same vzdump-driven job modes against a Backup Server datastore; confirm the exact mode set for your version
Incremental behavior	No incremental chain. Each run is a complete copy of the guest	Incremental backups, with only changed data sent after the first run
Encryption	Encryption depends on the target and tooling you add; confirm what your NFS or local storage setup provides	Client-side AES-256-GCM encryption before data leaves the guest host
Compression	Depends on the storage layer and compression settings you configure; confirm for your target	Zstandard compression, with SHA-256 checksums on stored data
Storage growth	Grows by the full size of every guest on every retained run, so retention count multiplies storage	Grows with unique changed data, so retention count adds less storage than full copies; the ratio depends on your data
Restore workflow	Restore the full archive from the target to the host, with restore time tied to archive size	Restore from a datastore through the client integration; restore time depends on datastore storage and network throughput, so benchmark your own setup
Target storage	NFS share, local directory or other supported storage named in the Proxmox VE configuration	A dedicated Proxmox Backup Server datastore, with the Proxmox VE documentation recommending a dedicated host
Licensing	Part of Proxmox VE, licensed under AGPL version 3	Free and open-source under AGPL version 3 or later
Subscription cost per year	Included with Proxmox VE, where the per-socket subscription differs only in support level	Per server per year at 560 euros (Community), 1,120 euros (Basic), 2,240 euros (Standard) or 4,480 euros (Premium), per Proxmox pricing; all tiers include unlimited storage and clients

How vzdump full backups behave on NFS and local storage

Every vzdump backup is a full backup. The Proxmox VE backup documentation states that each run captures the VM or container configuration and all of its data, so there is no built-in notion of an incremental chain to maintain. vzdump offers three backup modes. Stop mode shuts the guest down for the duration, suspend mode pauses it, and snapshot mode keeps the guest running and gives the lowest downtime, at the cost of a small inconsistency risk for applications that write continuously. Before you pick snapshot mode for a database or a mail server, confirm that the application can tolerate a crash-consistent copy or that it has its own dump step, and test a restore before you rely on it.

Because vzdump writes straight to a storage target, it needs no additional server. The target can be local storage on the node, or an NFS export, which the Proxmox VE documentation names as a good alternative to a dedicated Proxmox Backup Server host. The trade-off is growth. Each retained copy is a complete image, so retention settings and the free space on the target drive the total footprint directly. Size the target for the number of restore points you keep multiplied by the full size of every guest, and check how your storage administrator will alert on a full export. Restores are simple, since a single archive brings back the configuration and the data together, but restore time depends on how fast the target can read the full image.

How Proxmox Backup Server stores, syncs and restores backups

This sequence shows how a Proxmox VE node or client moves backup data into a Proxmox Backup Server datastore, how later runs and remote syncs send only changes, and how restores read the data back. Each step names what is produced so you can check it against your own environment.

Point the Proxmox VE node at a backup datastore
The Proxmox VE administrator adds Proxmox Backup Server as a storage target in the Proxmox VE web interface, which connects to a datastore on the backup host. For QEMU virtual machines and LXC containers, the integrated Proxmox Backup Server client handles the connection. For other Linux amd64 hosts, the proxmox-backup-client command-line tool does the same job. The step is complete when the datastore appears as available storage and a test backup job can reach it.
Encrypt backup data on the client
Before data leaves the source, the client can encrypt it with AES-256-GCM, so the datastore holds ciphertext rather than readable disk images. Encryption keys stay with the client side of the setup, which means losing them makes the backups unreadable. Confirm your key storage and recovery process before the first production run, because the server cannot recover a lost key for you.
Store the first backup as deduplicated chunks
The client splits the guest data into chunks and sends them to the datastore, which stores each unique chunk once and keeps metadata that describes how a backup snapshot is assembled from those chunks. The first run therefore carries the full data set. The step closes when the backup task reports success and the snapshot is listed in the datastore with its metadata.
Send only changed data on incremental runs
On later scheduled runs, the client checks which chunks already exist on the datastore and transmits only the new or changed ones, while the metadata records the new snapshot. Storage growth depends on how much data changes between runs and how similar the guests are to each other. Compare the datastore usage after several runs with your expected change rate to confirm the growth matches your planning.
Sync only new data to a remote datastore
A sync job copies snapshots from one datastore to another, such as a second site or a remote backup host, and transfers only chunks the remote side does not already hold. In Proxmox Backup Server 4.2, push sync jobs can encrypt snapshots before sending them, which keeps data protected in transit and at rest on the receiving side. The step is complete when the remote datastore lists the same snapshots and the sync log shows no failed transfers.
Request a restore through the RESTful API
When a restore is needed, the Proxmox VE node or proxmox-backup-client sends a request to the Proxmox Backup Server RESTful API, which reads the required chunks and metadata from the datastore and rebuilds the selected guest or files. Restore speed depends on the network path, the disk performance of the backup host and how many chunks must be read. Run a timed test restore of a representative guest to measure this in your own environment before you rely on it for recovery objectives.
Verify the restored guest and the datastore
After a restore, the administrator starts the recovered virtual machine or container and checks that its services, configuration and data match the expected state. The team also confirms that the source snapshot remains intact in the datastore. The step closes with a documented test record, which is the evidence you need for internal review and for any backup control evidence your auditors request.

What drives storage growth and restore speed in each approach

Storage growth and restore time are where vzdump and Proxmox Backup Server diverge most in practice. The cards below cover what each approach writes, how retention multiplies that cost, and what happens on the restore path, so you can measure both in a pilot before committing to a backup host.

Full-backup growth under vzdump

Every vzdump backup contains the full configuration and all data of the guest, so each retained copy adds the complete disk footprint. Growth tracks guest size and retention count rather than how much data actually changed. Check the total size of your largest guests, multiply by the number of copies you keep, and confirm the target storage has room for that figure plus headroom for a running backup job.

Deduplication and incremental effects

Proxmox Backup Server stores data as de-duplicated chunks and metadata, and it supports incremental backups. Unchanged data is referenced rather than written again, so storage growth follows your daily change rate instead of guest size. Measure that change rate on a representative guest during a pilot, because databases and log-heavy systems can change far more than file servers.

Retention policy effects

Retention decides how many restore points exist at any time, and it multiplies whatever each backup writes. With vzdump, a longer retention window means more full copies on the target. With Proxmox Backup Server, retention prunes chunk references, so the storage cost of extra restore points is usually much lower. Ask your team which restore points you actually need, then model storage for that schedule.

Restore path differences

A vzdump restore reads a full archive from the target and writes the guest back, so restore time depends on target throughput and archive size. A Proxmox Backup Server restore reconstructs the guest from chunks over the network from a datastore that may be on a separate host. Test both paths with your real storage and network, because the bottleneck may be the NFS server, the backup host network or the target disks.

Compression and encryption trade-offs

Proxmox Backup Server uses Zstandard compression and client-side AES-256-GCM encryption, so data is compressed and encrypted before it leaves the client. Encrypted data does not compress or deduplicate well across clients using different keys. Confirm how you will store the encryption key, because losing it makes encrypted backups unrecoverable, and measure the CPU cost of compression on your hypervisor hosts during a backup window.

Testing restores before you rely on them

A backup is only proven when a restore completes within your recovery target. Schedule restore tests for both vzdump archives and Proxmox Backup Server snapshots, including a bare-metal or full-host scenario where the backup host itself is down. Record the restore duration, the data verified and any manual steps, and compare those figures with the recovery time your business has agreed to.

Operating a backup host, monitoring and skills for each option

This table compares what it takes to keep vzdump backups and a dedicated Proxmox Backup Server running, from upgrades and verification to capacity, hardware and skills. Read each row as a question to answer in your own environment, because most of the effort depends on your storage target, backup volume and how many people already run Proxmox VE. The main takeaway is that vzdump adds little new infrastructure, while Proxmox Backup Server adds a second system you must patch, monitor and restore-test.

Operating area	vzdump to NFS or local storage	Proxmox Backup Server
Upgrade cadence	Upgrades follow Proxmox VE itself, so no separate backup product release train is added	Releases track Debian: 4.0 on August 6, 2025, 4.1 on November 26, 2025 and 4.2 on April 29, 2026 (Debian Trixie 13.4); plan a separate upgrade window
Upgrade dependencies	Only the hypervisor and the NFS or storage target need coordinated patching	Confirm compatibility between the PBS version, your Proxmox VE hosts and any client packages before each upgrade
Backup verification	Verify restores manually or with your own scripts; vzdump does not maintain a chunk store to check	Confirm which verification jobs your PBS version runs on datastores and how failures are reported to you
Monitoring	Monitor the backup job status in Proxmox VE and the free space on the NFS or local target	Monitor datastore usage, job results, sync jobs and the health of the host itself; confirm what the API exposes to your monitoring stack
Datastore capacity planning	Growth tracks full copies of each guest per retention cycle, so size the target for every retained full backup	Deduplication and incremental chunks reduce growth, but the real ratio depends on your data; measure it on a pilot before sizing
Dedicated host hardware	Usually no extra server; the backup target is a share on existing storage	Proxmox recommends a dedicated host; confirm CPU, memory, disk and network sizing with Proxmox and your data profile
Encryption key handling	Encryption depends on the tooling you add, so confirm how keys are stored and recovered	Client-side AES-256-GCM encryption is built in; plan key custody and recovery before the first backup
Skills needed	Proxmox VE administration plus NFS or storage administration and scripted restore testing	Proxmox VE administration plus Linux server operations, datastore management, retention policy and restore drills
Where the work sits	Mostly in the Proxmox VE and storage team, with restore testing owned by whoever runs the platform	Shared between the platform team, the storage team and whoever owns backup retention and recovery objectives
Support entitlement	Support depends on your Proxmox VE subscription tier; confirm what is covered for backups	Each PBS subscription level adds a support ticket allowance and response time; confirm the tier before go-live

Questions buyers ask before adding a Proxmox Backup Server

How much does a Proxmox Backup Server subscription cost per year?

Proxmox prices Proxmox Backup Server per server per year at 560 euros (Community), 1,120 euros (Basic), 2,240 euros (Standard) and 4,480 euros (Premium), according to the Proxmox Backup Server pricing page. Each paid tier includes unlimited backup storage and clients and access to the Enterprise Repository. The tiers differ in support: Basic includes 5 tickets a year with a one business day response, Standard includes 15 tickets with a 4-hour critical response, and Premium includes unlimited tickets with a 2-hour critical response. Community has no enterprise ticket support. Count the servers you will run, not the Proxmox VE hosts you back up, and confirm with Proxmox whether your setup needs one license per server.

Does Proxmox Backup Server need a subscription to run?

No. Proxmox Backup Server is free and open-source software under the GNU AGPL version 3 or later, and all features are available at every subscription level. The tiers differ only in support entitlement, ticket allowance and response time. A subscription gives access to the Enterprise Repository, which Proxmox recommends for production, while the no-subscription repository suits testing and non-production use. Teams that run production backups without a subscription accept that they handle updates and troubleshooting themselves, so confirm the repository choice and support expectations before you rely on the server for restores.

How long does a Proxmox Backup Server setup take, and what drives it?

The duration depends on the number of datastores, the size of the existing backup estate, the storage layout and whether you migrate from vzdump files. The main drivers are the chosen storage backend (local disks, ZFS, or an S3-compatible object store, which Proxmox Backup Server 4.2 moved to full support), the number of Proxmox VE hosts and guests that will point at the server, retention rules, sync jobs to a second site, and the work to validate restores. Proxmox does not publish a setup duration in the sources used here, so ask any implementation partner for a written timeline tied to a defined scope.

What does the team need to run Proxmox Backup Server?

The team needs Linux administration skills, familiarity with Proxmox VE backup jobs, and a plan for datastore capacity, retention and encryption key management. Proxmox Backup Server clients are integrated into Proxmox VE for QEMU virtual machines and LXC containers, and the proxmox-backup-client tool covers other Linux amd64 hosts. Someone must own the encryption keys, because client-side AES-256-GCM encryption protects backups only if the keys are stored and recovered correctly. Restore testing is also an operating task that must be scheduled, not assumed.

Does Proxmox Backup Server have to run on a dedicated host?

Proxmox recommends running Proxmox Backup Server on a dedicated host because of its advanced features, according to the Proxmox VE documentation. The documentation also names an NFS server as a good alternative when a dedicated host is not practical. A dedicated host keeps backup storage and its service separate from the guests it protects, which limits the blast radius of a failed or compromised hypervisor. If you run it on shared hardware, confirm that the backup datastore sits on separate disks and that a single host failure cannot take out both production guests and their backups.

When is vzdump alone still the right choice?

vzdump alone fits small estates where backups are full, infrequent and written to NFS or local storage, and where storage growth and restore speed are not pressing concerns. Proxmox VE backups are always full backups that include the configuration and all data, and vzdump offers stop, suspend and snapshot modes. Snapshot mode gives the lowest downtime at the cost of a small inconsistency risk. Keep vzdump when you have few guests, low change rates, spare NFS capacity and no need for deduplicated retention, sync to a second site or tape. Move to Proxmox Backup Server when full copies stop fitting the storage budget or the restore window.

What should I ask for in a quote for this work?

Ask for a written scope that lists the Proxmox VE hosts and guests in scope, the datastore design, the storage backend, the retention policy, the sync or offsite plan, the encryption key handling and the restore test plan. Ask which items are one-time work, such as installation, migration and initial validation, and which recur, such as updates, subscription renewals and restore tests. Confirm which licenses you buy directly from Proxmox and which the implementation covers. DeployOpen does not publish a price list, and a quote follows from the written scope.

What is the difference between subscription and implementation costs?

Subscription costs are paid to Proxmox for each server per year, and they cover software access and support entitlement, not the design or the work of running backups. Implementation costs are paid for planning, installation, configuration, integration, restore testing and documentation, and they depend on the scope agreed in writing. Subscription costs recur each year, while implementation is usually one-time work plus any retainer you choose for ongoing support. Keep the two budgets separate so that a change in one does not hide a change in the other.

When the extra backup server pays off

A second server pays off when the cost of full copies starts to outweigh the cost of running Proxmox Backup Server. vzdump writes a complete image of every guest on each run, and the Proxmox VE documentation says its backups are always full backups containing configuration and all data. With an NFS target, that means capacity grows with the number of VMs multiplied by the number of retained copies. Count your guests, the size of their disks, how often they change, and how many restore points your policy keeps. If that product is climbing toward what the NFS array can hold with headroom, the deduplicated, incremental model of Proxmox Backup Server becomes the practical fix.

The other triggers are less about storage and more about policy. Encryption requirements, offsite copies, and tape or S3 targets each push toward a dedicated backup host. Proxmox Backup Server encrypts client-side with AES-256-GCM and can sync only new data to a remote datastore, and version 4.2 moved S3-compatible object store datastores to full support and allows push sync jobs to encrypt snapshots before sending them. Confirm whether your target object store and sync topology match the version you will deploy, because those features are version-specific.

Small estates with short retention often do not justify a second machine. If you run a handful of guests, keep a few restore points, and restore rarely, a well-sized NFS share with scheduled vzdump jobs may meet your needs with less to operate. Decide with measurements rather than estimates: record your daily change rate per guest, the restore time you must meet for each tier of service, and the capacity your retention policy will consume over a year. Then ask your backup host vendor or DeployOpen for a written scope that includes the hardware, the datastore layout and the restore tests.

Which option fits small, growing and regulated Proxmox estates

A small estate with one Proxmox VE cluster and a modest number of guests often has a simple requirement: get a full copy of each guest to a location that survives a host failure, and restore it when needed. Proxmox VE backups are always full backups containing the VM or container configuration and all data, and vzdump can write them to local storage or to an NFS share. For this profile, vzdump with an NFS target can be enough, provided the NFS server is separate from the cluster and has enough space for several retained generations.

Backup modes: vzdump offers stop, suspend and snapshot modes. Snapshot mode gives the lowest downtime but carries a small inconsistency risk, so confirm which guests can tolerate it.
Storage growth: Each retained backup is a full copy, so the NFS target grows with every generation kept.
Restore path: Restores are straightforward because no separate backup server sits between the target and the cluster.
Dedicated host: A single NFS server avoids a second Proxmox component, which suits a team with limited operating time.
Recurring cost: Storage capacity and its monitoring are the main ongoing items.

Confirm how many generations you need to keep, how long a full restore takes on your network, and whether the NFS server itself is backed up.

How DeployOpen scopes, delivers and supports backup deployments

DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside the client's own infrastructure, so a Proxmox backup design is built around your clusters, storage and network. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.

How we scope

Inventory the Proxmox VE nodes, guest counts, backup windows and retention targets that the backup design must cover.
Document which guests need snapshot-mode vzdump jobs and which would benefit from a dedicated Proxmox Backup Server host.
Agree in writing whether the scope includes a dedicated backup host, an NFS target, or both, along with the deliverables.

How we build

Set up the backup target, datastores, retention settings and encryption keys in your own infrastructure with documented choices.
Configure backup jobs for each guest type and test restores of both VMs and LXC containers before the schedule goes live.
Validate storage growth against the chosen deduplication and retention settings using measured results from your environment.

How we hand over

Deliver runbooks covering job configuration, key custody, restore steps and the procedure for a failed backup host.
Document the encryption key handling and the offsite sync setup so your team can audit and reproduce the configuration.
Walk your operators through a restore drill and record the results as evidence for your own assessments.

How we support

Ongoing support, upgrades and continuous testing are available as retainers once the handover is complete.
Track Proxmox Backup Server and Proxmox VE release changes and plan upgrades against the written scope.
Confirm with Proxmox which subscription level fits your support needs, since DeployOpen does not resell subscriptions.