remote-backups.comremote-backups.com
Contact illustration
Sign In
Don't have an account ?Sign Up

How to Backup Proxmox to Cloud: PBS vs VZDump Explained

  • November 24, 2025
  • 13 min read
Bennet Gallein
Bennet Gallein
remote-backups.com operator

How to Backup Proxmox to Cloud: PBS vs VZDump

Proxmox gives you two main ways to backup your VMs: the traditional vzdump tool (which has been around forever) and the newer Proxmox Backup Server (PBS). Both can back up to cloud storage, both protect your data, but they work completely differently under the hood.

If you're trying to decide which to use, or wondering whether to migrate from vzdump to PBS, this guide breaks down exactly how each works, their performance characteristics, and when to use each one.

The Quick Answer

TL;DR:

  • VZDump: Traditional full backup tool, creates single archive files (.vma.zst or similar), works everywhere, simple but less efficient
  • PBS: Modern deduplicated backup system, stores data as chunks, much more efficient for multiple/incremental backups, requires PBS server

For most users: Use PBS if you can. It's significantly better for regular automated backups. Use vzdump for one-off backups or when you need simple portable archives.

What Is VZDump?

VZDump is Proxmox's original backup utility. It's been part of PVE since the beginning and still works great for many use cases.

How VZDump Works

When you run a vzdump backup:

  1. Creates a snapshot of your VM (in snapshot mode)
  2. Reads all the VM data
  3. Compresses it into a single archive file
  4. Writes that file to your backup storage
  5. Done

The result is one file per backup. A 100GB VM becomes a 40GB .vma.zst file (with compression).

VZDump Characteristics

Pros:

  • Simple to understand (one VM = one backup file)
  • Portable archives (can move them anywhere)
  • No additional infrastructure required
  • Works with any storage that can hold files
  • Fast for single backups

Cons:

  • Every backup is full-size (incremental not really a thing)
  • No deduplication (identical data is stored multiple times)
  • Can be slow for large VMs
  • Wastes storage space over time
  • No built-in verify functionality

Typical use cases:

  • One-off backups before major changes
  • Portable backups you need to move
  • Simple setups with few VMs
  • Where storage space is cheap

What Is Proxmox Backup Server (PBS)?

PBS is Proxmox's modern backup solution, released in 2020. It's designed specifically for efficient, scalable VM backups.

How PBS Works

PBS uses a completely different architecture:

  1. Creates a snapshot of your VM
  2. Reads VM data in fixed-size chunks (4MB by default)
  3. Calculates hash for each chunk
  4. Checks if that chunk already exists in backup storage
  5. Only uploads chunks that don't exist
  6. Stores metadata about which chunks belong to which backup

PBS Characteristics

Pros:

  • Massive deduplication (60-90% space savings typical)
  • Incremental forever (only changed data is transferred)
  • Built-in verification
  • Content-addressed storage (data corruption is detectable)
  • Snapshot catalog for granular file recovery
  • Much faster for multiple backups over time
  • Bandwidth-efficient

Cons:

  • Requires PBS server infrastructure
  • More complex to set up initially
  • Not as portable (can't just copy files around)
  • Slightly more overhead for single backups

Typical use cases:

  • Regular automated backups
  • Multiple VMs with similar OS/data
  • Limited storage or bandwidth
  • Production environments
  • Anything where you want incremental backups

Performance Comparison

Let's look at real-world performance differences.

Test Setup

  • Test VM: Ubuntu 22.04 with 100GB disk (60GB used)
  • Changes between backups: 5GB of data modified
  • Network: 1Gbps connection
  • Storage: Both writing to same NAS over NFS

First Full Backup

Initial Backup Performance
Metric
VZDump
Traditional backup
PBS
Chunk-based backup
Backup Time
Time to complete
28 minutes
32 minutes
Storage Used
Space consumed on backup storage
42GB
38GB
Network Usage
Data transferred over network
42GB transferred
38GB transferred
CPU Usage
Average CPU load during backup
45-60%
50-70%
First backup performance is similar because both methods transfer all data.

For the first backup, performance is comparable. VZDump might be slightly faster because there's less overhead, but the difference is minimal.

Second Backup (5GB Changed)

Now the difference becomes clear:

Incremental Backup Performance
Metric
VZDump
Full backup again
PBS
Incremental chunks
Backup Time
Time to complete
27 minutes
4 minutes
Additional Storage
New space consumed
41GB
3.2GB
Network Usage
Data transferred
41GB transferred
3.2GB transferred
Total Storage
Space for both backups
83GB
41GB
PBS is 6.8x faster and uses less than half the storage for two backups.

This is where PBS shines. Because only changed chunks are transferred and stored, the second backup is dramatically faster and more efficient.

30 Days of Daily Backups

Let's extend this to a month of daily backups with typical changes (5-10GB/day):

VZDump:

  • 30 full backups × 42GB each = 1,260GB total storage
  • 30 backups × 28 minutes = 14 hours total backup time
  • 30 × 42GB = 1,260GB network bandwidth used

PBS:

  • Initial 38GB + (29 incremental × 4GB average) = 154GB total storage
  • Initial 32 min + (29 × 4 min) = 2.5 hours total backup time
  • 87% less storage used
  • 82% less backup time
  • 87% less bandwidth used
Deduplication Impact

PBS's deduplication means 30 days of backups use roughly the same space as 3-4 vzdump backups. For environments with multiple similar VMs, the savings are even more dramatic.

Deep Dive: How Deduplication Works

PBS's secret weapon is content-addressed storage with deduplication. Here's how it actually works:

Chunk-Based Storage

PBS splits your VM disk into fixed-size chunks (4MB default). Each chunk gets a SHA-256 hash calculated.

VM Disk (100GB)
├── Chunk 1 (4MB) → Hash: aa3f8c2...
├── Chunk 2 (4MB) → Hash: bb7d2e1...
├── Chunk 3 (4MB) → Hash: aa3f8c2...  ← Same as Chunk 1!
├── Chunk 4 (4MB) → Hash: cc9a1f4...
└── ...

When Chunk 3 has the same hash as Chunk 1, PBS doesn't store it twice. It just references the existing chunk.

Why This Is Powerful

Between backups: Only changed chunks need to be stored. If you modify one file in a VM, maybe only 2-3 chunks change. The rest reference existing chunks from previous backups.

Between VMs: If you have 10 Ubuntu 22.04 VMs, the OS itself is largely identical. Those chunks are stored once and referenced 10 times.

Compression is still applied: Each chunk is compressed before storage, so you get compression savings on top of deduplication savings.

Real-World Example

Let's say you have:

  • 5 Ubuntu 22.04 VMs
  • 3 Debian 11 VMs
  • 2 Windows Server 2022 VMs

Without deduplication:

  • Each VM is 50GB
  • 10 VMs × 50GB = 500GB raw
  • With compression: ~250GB stored
  • After 7 days of daily backups: ~1.75TB

With PBS deduplication:

  • First Ubuntu VM: 50GB raw, stores ~22GB compressed
  • Second Ubuntu VM: 50GB raw, but 70% is duplicated from first VM, stores ~7GB additional
  • Remaining Ubuntu VMs: ~5GB each additional
  • Similar for Debian and Windows VMs
  • First full backup set: ~120GB instead of ~250GB
  • After 7 days: ~200GB instead of ~1.75TB

That's 88% less storage used.

Bandwidth Considerations

For cloud backups, bandwidth matters. A lot.

VZDump to Cloud

Every backup transfers the full compressed VM size:

100GB VM with 40% compression = 60GB per backup
Daily backups = 60GB × 30 = 1.8TB/month bandwidth

On a 100Mbps connection:
60GB = 480,000 megabits
480,000 Mb ÷ 100 Mbps = 4,800 seconds = 80 minutes per backup

That's manageable for one VM. Scale to 10 VMs and you're looking at 13+ hours of backup time per day, consuming 18TB/month of bandwidth.

PBS to Cloud

First backup: Same as vzdump (full transfer)

Subsequent backups: Only changed chunks

100GB VM, 5GB changed daily = ~2-3GB compressed chunks transferred
Daily backups = 3GB × 30 = 90GB/month (after initial)

On a 100Mbps connection:
3GB per backup = 4 minutes

10 VMs = 40 minutes total backup time
Bandwidth: ~300GB/month (after initial seeding)

For cloud backups, PBS is essential if you have:

  • Slow upload speeds
  • Data caps
  • Multiple VMs
  • Large VMs

When to Use VZDump

Despite PBS being better for most scenarios, vzdump still has its place:

One-Off Backups

Before a risky upgrade or major configuration change:

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

Quick, simple, no fuss. Creates a portable backup file you can keep or move elsewhere.

Portable Backups

Need to move a VM to another system without PBS?

VZDump creates a single file you can:

  • Copy to USB drive
  • Transfer via rsync
  • Upload to simple cloud storage
  • Import on any Proxmox system

Simple Environments

If you have:

  • Just 1-2 VMs
  • Plenty of storage
  • Infrequent backups
  • No deduplication benefits (all different VMs)

Then vzdump might be simpler than setting up PBS infrastructure.

Backup Before PBS Migration

Ironically, use vzdump to backup your VMs before migrating to PBS. Safety first.

When to Use PBS

Use PBS when you have:

Regular Automated Backups

Daily or more frequent backups benefit massively from deduplication. The storage and bandwidth savings pay for the setup complexity within weeks.

Multiple Similar VMs

5 web servers running the same OS? 10 desktop VMs for users? PBS deduplication will save 70-90% storage on those.

Limited Bandwidth

Slow internet connection? PBS incremental backups might transfer 1/10th the data of vzdump.

Limited Storage Budget

PBS can fit 3-4x more backup history in the same storage space through deduplication.

Cloud or Offsite Backups

For any remote backup scenario, PBS is dramatically more efficient.

Long-Term Retention

Need to keep months or years of backups? PBS makes this practical through deduplication. VZDump would eat absurd amounts of storage.

Setting Up PBS for Cloud Backups

If you're convinced PBS is the way to go, here's a quick setup guide for cloud backups:

Option 1: Managed PBS (Easiest)

Use a managed PBS service like Remote-Backups.com:

  1. Sign up for account
  2. Create datastore
  3. Add to Proxmox as PBS storage
  4. Create backup job
  5. Done

No server to manage, automatic updates, infrastructure handled for you.

Option 2: PBS on Cloud VPS

Run your own PBS instance in the cloud:

  1. Spin up a VPS (2 cores, 4GB RAM minimum)
  2. Install Proxmox Backup Server
  3. Add cloud storage (S3, local disk, whatever)
  4. Configure from Proxmox VE
  5. Set up backup jobs

More control, but you manage the PBS server yourself.

Option 3: Local PBS + Cloud Sync

Run PBS locally for fast backups, sync to cloud for offsite:

  1. Install PBS on local hardware
  2. Configure as backup target for Proxmox
  3. Set up remote sync to cloud storage
  4. Backups go to local PBS (fast)
  5. PBS syncs to cloud (automatic, in background)

Best of both worlds but most complex setup.

Migration Guide: VZDump to PBS

Already using vzdump and want to switch? Here's how:

Step 1: Set Up PBS

Either use managed PBS or install your own PBS server.

Step 2: Test with Non-Critical VMs

Don't migrate everything at once:

  1. Pick a test VM
  2. Add PBS storage to Proxmox
  3. Create backup job for test VM to PBS
  4. Run backup and verify
  5. Test restore
  6. Confirm everything works

Step 3: Parallel Running

Run both vzdump and PBS backups for a week:

  • Keep existing vzdump jobs
  • Add new PBS jobs
  • Monitor both
  • Compare storage usage and times
  • Verify PBS backups work

Step 4: Migrate Production VMs

Once confident:

  1. Update backup jobs to use PBS
  2. Disable old vzdump jobs (don't delete yet)
  3. Let PBS backups run for a week
  4. Keep one final vzdump backup as safety
  5. Delete old vzdump backups after PBS proven stable

Step 5: Cleanup

After a month of successful PBS backups:

  1. Remove vzdump backup jobs
  2. Delete old vzdump archives
  3. Update documentation
  4. Reclaim storage space
Keep Safety Backups

During migration, maintain at least one recent vzdump backup of critical systems until you're 100% confident in PBS. Better safe than sorry.

Troubleshooting Common Issues

PBS Backup Slow Despite Deduplication

Possible causes:

  1. CPU bottleneck: Deduplication and compression are CPU-intensive
  2. Network latency: High latency to PBS server slows chunk uploads
  3. First backup: First backup of a VM is always full-speed (no dedup yet)

Solutions:

  • Check CPU usage during backup
  • Run PBS network benchmark: proxmox-backup-client benchmark
  • Verify it's not the first backup
  • Consider faster network or local PBS

VZDump Faster Than PBS?

If vzdump is beating PBS on backup time, you're probably:

  1. Comparing first-ever backups (both are similar speed)
  2. Not benefiting from deduplication (all-unique data)
  3. CPU-bottlenecked on PBS

For single large backups of unique data, vzdump can be faster. But for repeated backups, PBS will be faster by the second or third run.

PBS Using More Storage Than Expected

Check deduplication ratio in PBS web interface. If it's lower than expected:

  • VMs might be more unique than you thought
  • Encryption can prevent deduplication
  • Check for VMs with randomized data (databases, swap)

Cannot Restore from PBS

Make sure:

  • PBS server is online and accessible
  • Fingerprint matches
  • Credentials are correct
  • Backup actually completed successfully

Check PBS logs and task history for details.

Conclusion

Use PBS for:

  • Regular automated backups
  • Multiple VMs
  • Limited storage or bandwidth
  • Cloud/offsite backups
  • Long-term retention

Use VZDump for:

  • One-off backups
  • Portable archives
  • Simple single-VM setups
  • Maximum compatibility

For most Proxmox users, PBS is the better choice. The initial setup complexity is worth it for the massive storage and bandwidth savings. But vzdump still has its place for specific use cases.

If you're running production workloads or more than 2-3 VMs, invest the time to set up PBS. Your storage costs and backup times will thank you.