Migrate vzdump to PBS: Step-by-Step

You've been running vzdump backups for years. They work. But every night, your backup job dumps another full copy of every VM onto your NFS share, and your storage keeps growing. Switching to Proxmox Backup Server cuts that storage by 60-80% and turns 30-minute backup windows into 4-minute incremental runs. This guide walks you through the full migration, step by step.

Why Migrate from vzdump to PBS?

vzdump creates a monolithic .vma archive for every backup. Each run produces a full-size file, even if only a few megabytes changed since last time. That model worked fine when VMs were small and storage was cheap. It doesn't scale.

Proxmox Backup Server takes a different approach. It splits VM data into fixed-size chunks, hashes each chunk with SHA-256, and stores only unique chunks. The result: your second backup of a 100 GB VM might transfer 3 GB instead of 40 GB.

Here's what you gain by switching:

• Deduplication across backups and VMs. Ten Ubuntu VMs share most of their OS chunks. PBS stores them once.
• True incrementals. Only changed chunks get transferred and stored. Backup windows shrink from tens of minutes to single digits.
• Built-in verification. PBS can verify chunk integrity on a schedule, catching bit rot before you need to restore.
• Native encryption. AES-256-GCM client-side encryption, applied before data leaves your PVE host.
• Sync jobs for offsite replication. Push encrypted backups to a remote PBS target with a single configuration.
• Tight PVE integration. Proxmox Backup Server shows up as a native storage type in PVE. File-level restore works directly from the GUI.

vzdump isn't deprecated. But PBS is where Proxmox invests its development effort, and the efficiency gains are hard to ignore. For a full technical breakdown of both tools, see the PBS vs vzdump comparison.

When vzdump Still Makes Sense

Not every setup needs PBS. vzdump remains a good fit for:

• Simple environments with 1-2 VMs and plenty of local storage.
• Portable backups. A .vma file is self-contained. Copy it to a USB drive, ship it offsite, restore it on any PVE node.
• Air-gapped scenarios. If you rsync backup files to offline media on a schedule, vzdump's single-file output is easier to handle.
• One-off snapshots. Quick backup before a risky upgrade? vzdump 100 --mode snapshot --compress zstd is hard to beat for simplicity.

If none of those apply to you, read on.

Prerequisites

You don't need a PVE subscription or a PBS subscription. Both work on the free tier. If you want a managed PBS target without running your own server, remote-backups.com provides ready-to-use datastores in EU datacenters.

Step 1: Add PBS Storage in PVE

Open your PVE web interface and navigate to Datacenter > Storage > Add > Proxmox Backup Server.

Fill in the connection details:

• ID: A name for this storage (e.g., pbs-main)
• Server: Your PBS hostname or IP
• Username: PBS user in user@realm format (e.g., backup@pbs)
• Password: The user's password or an API token
• Datastore: The datastore name on your PBS instance
• Fingerprint: The TLS certificate fingerprint from your PBS dashboard

pvesm add pbs pbs-main \
    --server pbs.example.com \
    --datastore main \
    --username backup@pbs \
    --password YOUR_PASSWORD \
    --fingerprint AA:BB:CC:DD:EE:FF:...

After adding, PVE will test the connection. If you see the storage listed without errors, you're connected.

Step 2: Create Your First PBS Backup Job

Navigate to Datacenter > Backup > Add and configure your first job.

Key settings:

• Storage: Select the PBS storage you just added
• Schedule: Pick a time outside business hours (e.g., 02:00)
• Selection mode: Start with a few non-critical VMs. Don't migrate everything at once.
• Mode: Snapshot (recommended; zero downtime)
• Compression: ZSTD

Retention Settings

PBS handles retention differently than vzdump. Instead of "keep N backup files," you set layered policies:

keep-last:    3
keep-daily:   7
keep-weekly:  4
keep-monthly: 6

This keeps 3 recent snapshots, a week of dailies, a month of weeklies, and half a year of monthlies. PBS pruning and garbage collection handles the rest automatically.

Run the job manually once to verify. Watch the task log. Your first backup will transfer all data (no dedup benefit yet), so expect it to take roughly as long as a vzdump run. From the second backup onward, you'll see the difference.

Step 3: Encryption Setup

If your PBS target is remote or managed by a third party, enable client-side encryption. This encrypts data on your PVE host before it leaves the network.

In your PVE storage configuration for the PBS target, set an encryption key. PVE generates a .json key file.

For a deeper walkthrough on encryption modes and key management, see the PBS client-side encryption guide.

What About Existing vzdump Backups?

This is the part most guides skip. You have weeks or months of vzdump .vma files sitting on your NFS share. What do you do with them?

You have three options:

Option 1: Keep Old Backups Until They Expire

Leave your vzdump storage mounted. Let your existing retention policy age out the old backups naturally. Meanwhile, PBS builds up its own history in parallel.

This is the safest approach. You lose nothing, and within a few weeks your PBS retention depth matches what you had with vzdump.

Option 2: Re-Baseline Critical VMs

If you need a specific old backup point preserved in PBS:

1. Restore the VM from the vzdump archive (to a temporary VM ID)
2. Back up the restored VM to PBS
3. Delete the temporary VM

This is manual and time-consuming. Only do it for VMs where you need that specific point-in-time in your PBS history.

Option 3: Run Both in Parallel

Keep your vzdump backup jobs running alongside PBS jobs for 2-4 weeks. Once PBS has enough retention depth:

1. Disable the vzdump jobs (don't delete them yet)
2. Wait another week
3. Verify PBS restores work by testing a restore
4. Remove the vzdump jobs and reclaim storage

Performance: vzdump vs PBS

The storage difference compounds over time. After 30 days with 10 VMs, vzdump consumes roughly 4x more space than PBS. With similar VMs (same OS, same base packages), PBS deduplication pushes that ratio even higher.

Optimizing PBS After Migration

Once your migration is complete, tune these settings:

Pruning and Garbage Collection

Set up a weekly garbage collection job on your PBS instance. Pruning marks old snapshots for removal; GC actually frees the disk space. Without regular GC, your datastore grows even after pruning. See the pruning and GC guide for recommended schedules.

Verification Jobs

Schedule weekly verification on your PBS datastore. Verification reads stored chunks and checks their SHA-256 hashes against the manifest. It catches silent corruption before you discover it during a restore.

Offsite Sync

If your PBS instance is local, add a sync job to replicate backups to a remote Proxmox Backup Server. Use --encrypted-only if your remote target is managed by a third party. This ensures only pre-encrypted chunks leave your network. Full details in the sync jobs guide.

Common Migration Mistakes

Deleting vzdump backups too early. Run PBS in parallel for at least as long as your vzdump retention before removing old backups.

Forgetting the encryption key backup. The .json key file is your only way to decrypt PBS backups. Lose it, lose everything.

Skipping restore tests. Backups you've never restored are backups you hope work. Schedule a quarterly DR drill.

No garbage collection schedule. Pruning without GC doesn't free disk space. Set a weekly GC job on your PBS instance.

Ignoring verification failures. If PBS reports bad chunks, investigate immediately. Waiting turns a recoverable problem into data loss.

Wrapping Up

Migrating from vzdump to Proxmox Backup Server is straightforward, but it requires patience. Run both systems in parallel, wait for PBS to build up sufficient retention depth, test your restores, then cut over. The storage savings and faster backup windows make the effort worth it within the first week.