vzdump vs Proxmox Backup Server: Which Backup Method Should You Use in Proxmox VE?

Introduction

Ask ten Proxmox homelab users whether they bother with Proxmox Backup Server, and you'll get ten different answers. Some treat it as day-one essential. Others have backed up straight to an NFS share with the built-in vzdump tool for years and never had a reason to change.

Both groups are right, which is exactly the problem. Most write-ups either treat Proxmox Backup Server (PBS) as something every install needs, or wave it off as overkill for anyone without a server rack. Neither answer fits everyone, because the right tool depends on how much you're protecting and how much babysitting you're willing to do.

This one skips the sales pitch. You'll get a straight look at what vzdump and PBS each actually do, where they genuinely differ, and a practical way to decide which one is worth your Saturday afternoon. We're working from Proxmox VE 9.2 and Proxmox Backup Server 4.x, though almost everything here has worked the same way since PVE 8.x.

What You Will Learn

• What vzdump does and where its backups actually go
• What Proxmox Backup Server adds on top of that, and why it exists at all
• The real difference between a full backup and a deduplicated one
• How to check what you're currently doing for backups right now
• How to run a manual vzdump backup and measure its size
• How to point an existing backup job at a PBS datastore instead
• Which setup makes sense for a two-VM homelab versus a dozen-VM cluster

What Is This Feature?

vzdump is the backup tool built directly into Proxmox VE. It's been there since the early Proxmox 1.x days, and it's what runs behind the scenes whenever you click Backup Now in the web interface or set up a scheduled backup job under Datacenter > Backup. It archives a VM or LXC container's disks and configuration into a single file, usually a .vma.zst for VMs or a .tar.zst for containers, and drops it wherever you point it: local disk, an NFS share, a CIFS share, or any other storage Proxmox VE recognizes.

Proxmox Backup Server is a completely separate application. It's not a feature you enable inside Proxmox VE — it's its own piece of software you install, either on dedicated hardware, inside its own VM, or nested inside your existing Proxmox VE host if you just want to try it out. Once it's running, you add it to Proxmox VE as a storage target, the same way you'd add an NFS share, and your existing backup jobs can write to it instead of a plain folder.

The core difference between the two isn't really about where the files land. It's about deduplication. A plain vzdump backup is a complete, independent copy of the VM's disks every single time it runs. If you back up a 40 GB VM every night for a week, you've got roughly 280 GB sitting on your storage, even if only a text config file changed inside that VM all week. PBS instead breaks each backup into small chunks (4 MB by default), checks whether it's already stored an identical chunk from a previous run, and only writes the ones that changed. The end result still looks like seven full, independently restorable backups — you're just not paying for seven full copies of unchanged data.

That chunk-based storage is called the datastore, and it's the other piece vzdump simply doesn't have. A vzdump target is just a folder full of archive files. A PBS datastore is a structured chunk store with its own metadata, which is also how PBS can verify, on a schedule, that none of those chunks have quietly gone corrupt on disk — something a folder full of .vma.zst files has no way to check on its own.

Here's the short version side by side:

Why Would You Use It?

Here's where a lot of comparisons get vague, so let's be specific about who benefits from what.

Stick with plain vzdump if you're running two or three VMs on a single node, backing up to a spare drive or an NFS share with plenty of room, and you're fine with backups taking up more space than the VMs themselves. There's nothing wrong with that setup. It's simple, it has no extra moving parts to maintain, and restoring is exactly as straightforward as backing up.

Reach for Proxmox Backup Server once any of these start to bite:

• Your backup storage keeps filling up faster than your actual VM storage does
• You want backups running every few hours instead of once a night, without your storage exploding
• You manage more than one Proxmox VE node and want a single place to browse and restore from
• You care about backup integrity checks — PBS can verify that stored chunks haven't quietly rotted on disk, which vzdump alone can't do
• You want encrypted, offsite-friendly backups without scripting rsync yourself

If none of those describe you, PBS is a solid tool you don't need yet. Installing it "just in case" mostly buys you another service to patch and monitor.

Prerequisites

To follow along and compare both approaches, you'll want:

• A working Proxmox VE 8.x or 9.x host with at least one VM or LXC container to test with
• Root or admin access to the Proxmox VE web interface, plus SSH access if you want to run commands directly
• Somewhere for vzdump backups to land — local disk, an NFS share, or similar, with a few gigabytes free
• Optional: a second machine, spare hardware, or a small VM (2 CPU cores, 2 GB RAM, and roughly 32 GB of disk is enough to start) if you want to actually install PBS rather than just read about it

You don't need a Proxmox subscription for any of this. Backups, PBS, and everything covered here work on the free, no-subscription install.

Step-by-Step Tutorial

1. Check what you're already doing for backups

Before comparing anything, find out what's actually configured right now. In the Proxmox VE web interface, go to Datacenter > Backup. If you see a job listed there, click it to see which storage it's writing to and on what schedule. If the list is empty, you're not backing up anything yet, and that's worth fixing before you worry about which tool is "better."

2. Run a manual vzdump backup and look at the size

Pick a VM you don't mind testing with. In the web UI, select it, click Backup, then Backup now. Choose a storage target, set the mode to Snapshot (this backs up the running VM without shutting it down), and set compression to ZSTD, which is the fastest option on modern Proxmox releases.

If you'd rather do this from the shell, SSH into the node and run:

vzdump 100 --storage local --mode snapshot --compress zstd

Replace 100 with your VM's ID, which you can find in the top left of its summary page in the web UI. Once it finishes, check the file size:

du -sh /var/lib/vz/dump/*100*

Run that same backup again tomorrow without changing anything inside the VM, and you'll get a second file that's nearly as large as the first. That's the behavior PBS is built to avoid.

3. Add a PBS datastore as backup storage (if you want to compare directly)

If you've got PBS installed already, or you install it on a spare VM using the official ISO, add it to Proxmox VE from Datacenter > Storage > Add > Proxmox Backup Server. You'll need the PBS server's address, a datastore name you created on the PBS side, and either the root password or, better, a scoped API token created just for backups. You can grab the server's TLS fingerprint straight from the PBS web interface under Certificates, or by running this on the PBS host:

proxmox-backup-manager cert info

4. Point an existing backup job at PBS instead

Once PBS shows up as a storage option, edit your existing backup job under Datacenter > Backup and change its storage target to the PBS datastore. Run it manually once, then run it again the next day. Check the datastore usage on the PBS side under Datastore > Summary — you'll notice the second backup barely moves the needle on disk usage, even though it shows up as a complete, restorable backup point.

Commands Explained

Common Errors

A few things trip up almost everyone the first time they try PBS after only ever using vzdump:

"Connection error - 401 unauthorized" when adding PBS as storage usually means the username is wrong. PBS usernames need a realm suffix, so backup@pbs works but plain backup doesn't.

"certificate verification failed" shows up if you paste the wrong fingerprint, or paste it with extra spaces from a copy-paste. Regenerate it with proxmox-backup-manager cert info and copy it fresh.

Backups silently taking far longer than expected on the first PBS run is normal, not an error. The first backup to a new datastore has nothing to deduplicate against yet, so it behaves like a full vzdump backup. Backups two and three onward are the ones that get fast.

"unable to create chunk store" during datastore creation almost always means the path you gave PBS doesn't exist yet, or the disk isn't mounted at that path. Create the directory first, confirm it's actually your intended disk with df -h /mnt/datastore, then create the datastore again.

vzdump job stuck at "0.00%" for a long time on a VM using snapshot mode usually points to slow underlying storage, not a frozen job. This is common on spinning HDDs with several VMs backing up at once — stagger your schedule instead of running everything at midnight.

Troubleshooting

If a vzdump job fails outright, check Datacenter > Backup, click the job, and open the task log — it almost always names the exact storage or permission problem. Running out of space on the backup target is the single most common cause, and it's easy to miss because Proxmox VE won't warn you in advance.

If PBS backups are running but restores feel slow, check whether you're restoring over a 1 Gbps link. Deduplication saves storage space, but a restore still has to pull every chunk back over the network, so restore speed depends heavily on your connection between the Proxmox VE node and the PBS server.

If storage on the PBS side keeps growing despite deduplication, it's usually retention settings, not a broken feature. Check Datastore > Prune & GC jobs — without a prune schedule, PBS happily keeps every single backup forever.

Best Practices

• Don't run backups on the same physical disk as your VMs. If that disk dies, you lose both the VM and the backup at once.
• Set a retention policy on day one, whichever tool you use. "Keep everything" quietly turns into a full disk six months later.
• If you do adopt PBS, create a dedicated API token scoped to backup permissions only, instead of using the PBS root account from Proxmox VE.
• Test a restore at least once, on both tools, before you actually need one. A backup you've never restored from is a guess, not a plan.
• Honestly, if you're running a single VM for personal use, plain vzdump to a cheap USB drive is genuinely fine. Don't feel pressured into PBS just because it's the "advanced" option.

Frequently Asked Questions

Can I use vzdump and PBS at the same time?

Yes. Nothing stops you from keeping a vzdump job to local storage as a quick fallback while also sending backups to PBS. Some homelab users do exactly this for extra redundancy.

Does PBS replace snapshots?

No. Snapshots are a point-in-time state you roll back to instantly on the same storage, and they're not a substitute for an actual backup stored elsewhere. PBS and vzdump both create real, separate backup files; snapshots don't protect you if the underlying storage fails.

Is Proxmox Backup Server free?

Yes, PBS is free to install and use without a subscription, the same as Proxmox VE itself. Subscriptions are optional and mainly relevant for businesses that want vendor support.

How much overhead does PBS add to a small homelab?

Budget roughly 2 CPU cores, 2 GB of RAM, and 32 GB of disk for the PBS instance itself, on top of whatever storage your actual deduplicated backups need.

Which one should a total beginner start with?

Start with vzdump. It's already built in, it works the moment you click Backup, and there's nothing extra to install or maintain. Move to PBS once you notice backup storage becoming a real problem.

Conclusion

Neither tool is objectively better — they solve different-sized problems. vzdump gets a homelab backed up in five minutes with zero extra infrastructure. PBS earns its keep once storage space, backup frequency, or multi-node management start costing you real time.

If you've never backed up your VMs at all, don't overthink this. Set up a scheduled vzdump job today, to any storage you have spare. You can always add PBS on top of that once you actually feel the pain it solves.