Backups are the foundation of any reliable homelab. Whether you’re running production services or just experimenting, losing your virtual machines and containers to hardware failure, accidental deletion, or ransomware is a nightmare you can avoid with proper Proxmox backup strategies.

💡 This article contains affiliate links. If you buy through them, we earn a small commission at no extra cost to you. Learn more.

Proxmox VE offers multiple backup solutions, each designed for different use cases. In this comprehensive guide, we’ll explore every backup method available in Proxmox, from built-in vzdump to the powerful Proxmox Backup Server, and help you design a backup strategy that matches your needs and budget.

Why Proxmox Backups Matter

Before diving into the technical details, let’s be clear about why backups are non-negotiable:

Hardware fails. SSDs wear out, hard drives click their last click, power supplies fry motherboards. It’s not a question of if, but when.

Mistakes happen. You’ll accidentally delete the wrong VM, misconfigure a network, or break something during an upgrade. A good backup lets you roll back in minutes instead of rebuilding for hours.

Security incidents are real. Ransomware, compromised credentials, or a vulnerability in one of your services could destroy your data. Offline backups are your insurance policy.

Testing and development need safety nets. Want to try a major update? Test new configurations? With backups, you can experiment freely knowing you can restore if things go wrong.

Proxmox Backup Methods Overview

Proxmox VE provides several backup approaches:

  1. Vzdump — Built-in backup tool that creates archive files (.vma, .tar, .tar.gz)
  2. Proxmox Backup Server (PBS) — Dedicated backup solution with deduplication and encryption
  3. Snapshots — Point-in-time copies (not true backups, but useful for pre-upgrade safety)
  4. Replication — Live VM/CT replication to another Proxmox node
  5. External scripts — Custom solutions using rsync, rclone, or other tools

Let’s explore each method in detail.

Method 1: Vzdump — The Built-In Solution

Vzdump is Proxmox’s native backup tool. It’s included with every Proxmox VE installation and requires zero additional setup. Vzdump creates archive files of your VMs and containers that can be stored locally or on network storage.

How Vzdump Works

When you trigger a vzdump backup:

  1. Snapshot mode (default): Proxmox creates a snapshot of the VM/CT, backs up the snapshot, then removes it. The VM stays running with minimal downtime.
  2. Stop mode: The VM is shut down, backed up completely, then restarted. Guarantees consistency but causes downtime.
  3. Suspend mode: The VM is suspended (like hibernate), backed up, then resumed. Useful for VMs that don’t support snapshots.

For containers (LXC), vzdump creates a .tar archive. For VMs (QEMU), it creates a .vma (Proxmox Virtual Machine Archive) file.

Setting Up Vzdump Backups

In the Proxmox web UI:

  1. Go to Datacenter → Backup
  2. Click Add to create a backup job
  3. Configure your settings:
    • Node: Where the backup runs
    • Storage: Where to save backups (local disk, NFS, SMB, etc.)
    • Schedule: Cron-style timing (e.g., daily at 2 AM)
    • Selection mode: Which VMs/CTs to back up
    • Retention: How many backups to keep (e.g., keep 7 daily, 4 weekly)
    • Mode: Snapshot (recommended), stop, or suspend
    • Compression: None, LZO, GZIP, or ZSTD

Example configuration for a daily backup:

Schedule: Daily at 03:00
Mode: Snapshot
Compression: ZSTD
Retention: Keep 7 backups
Storage: local-zfs (or your backup storage)

Vzdump via Command Line

For more control, use vzdump from the command line:

1
2
3
4
5
6
7
8

# Backup VM 100 to local storage with ZSTD compression
vzdump 100 --storage local-zfs --mode snapshot --compress zstd

# Backup all VMs on the node
vzdump --all --storage backup-nfs --compress zstd

# Backup specific VMs with email notification
vzdump 100,101,102 --storage backup-nfs --mailto admin@example.com

Pros and Cons of Vzdump

Pros:

  • Built-in, no additional software needed
  • Simple to configure via web UI
  • Works with any Proxmox storage backend
  • Supports compression and retention policies
  • Can back up to NFS, SMB/CIFS, or local storage

Cons:

  • No deduplication (backups are full copies each time)
  • No built-in encryption
  • Large storage requirements for multiple VMs
  • Slower restores compared to PBS
  • No incremental backups (though snapshots reduce downtime)

Best for: Small homelabs, local backups, simple setups without specialized backup infrastructure.

Method 2: Proxmox Backup Server (PBS) — The Professional Solution

Proxmox Backup Server is a dedicated backup solution that takes Proxmox backups to the next level. It’s a separate product (free and open-source) designed specifically for backing up Proxmox VE hosts.

Why Use PBS?

PBS solves the biggest problems with vzdump:

Deduplication: PBS stores data in chunks and deduplicates across all backups. If 10 VMs all have Ubuntu 22.04 base images, PBS stores those common blocks once, not ten times.

Incremental backups: After the first full backup, PBS only backs up changed data. This dramatically reduces backup time and storage usage.

Encryption: PBS supports AES-256 encryption at rest. Your backup data is encrypted before leaving the Proxmox host.

Verification: PBS automatically verifies backup integrity to catch bit rot or corruption.

Retention policies: Flexible retention with prune rules (keep 7 daily, 4 weekly, 12 monthly).

Fast restores: Thanks to the chunk-based architecture, you can restore individual files or entire VMs quickly.

Setting Up Proxmox Backup Server

PBS runs on its own machine (physical or virtual). Here’s the quick setup:

1. Install PBS:

Download the ISO from proxmox.com and install on a dedicated machine or VM. PBS needs its own storage — ideally a large disk array or external USB drives for budget setups.

2. Configure storage:

In the PBS web UI (https://pbs-ip:8007):

  • Add a datastore (the storage pool for backups)
  • Set up retention policies
  • Optional: Configure encryption with a key file

3. Add PBS to Proxmox:

In Proxmox VE:

  • Go to Datacenter → Storage → Add → Proxmox Backup Server
  • Enter PBS server IP, datastore name, and credentials
  • PBS now appears as a backup target in Proxmox

4. Create backup jobs:

Use the same Datacenter → Backup interface, but select your PBS datastore as the target.

PBS Encryption

PBS encryption is client-side — data is encrypted on the Proxmox host before transmission to PBS. This means:

  • PBS server never sees unencrypted data
  • You can safely store backups on untrusted storage or cloud providers
  • You must keep the encryption key safe — losing it means losing your backups

To enable encryption, generate a key when creating the PBS storage in Proxmox:

1
2

# Generate encryption key on Proxmox host
proxmox-backup-client key create my-pbs.key --kdf none

Then upload this key when adding PBS storage in the Proxmox web UI. Store the key file in a safe location (password manager, offline storage).

PBS Deduplication Example

Let’s say you have 5 Ubuntu VMs and 3 Debian VMs:

Without PBS (vzdump):

  • Each VM backup is 10 GB
  • 8 VMs × 10 GB = 80 GB per backup cycle
  • Keep 7 days = 560 GB storage

With PBS:

  • First backup: 80 GB (full)
  • Incremental backups: ~5 GB (only changed data)
  • Deduplication reduces shared OS data to ~15 GB
  • 7 days of backups: ~45-60 GB storage

PBS can reduce storage requirements by 70-90% in typical homelab scenarios.

PBS Retention Policies

PBS uses a sophisticated retention system called prune:

keep-last: Keep the last N backups
keep-daily: Keep one backup per day for N days
keep-weekly: Keep one backup per week for N weeks
keep-monthly: Keep one backup per month for N months
keep-yearly: Keep one backup per year for N years

Example retention policy for a homelab:

keep-last: 3      # Always keep 3 most recent
keep-daily: 7     # One per day for a week
keep-weekly: 4    # One per week for a month
keep-monthly: 6   # One per month for half a year

This gives you granular recovery options (yesterday’s backup, last week’s, two months ago) without wasting storage.

Pros and Cons of PBS

Pros:

  • Massive storage savings via deduplication
  • Fast incremental backups
  • Built-in encryption
  • Automatic verification
  • Designed for Proxmox (tight integration)
  • Can back up multiple Proxmox nodes to one PBS instance

Cons:

  • Requires a separate machine/VM for PBS
  • More complex setup than vzdump
  • Additional hardware cost (storage, backup server/NAS)
  • Encryption key management is critical

Best for: Medium to large homelabs, production environments, anyone running multiple Proxmox nodes or needing enterprise-grade backup.

Method 3: ZFS/LVM Snapshots — Quick Safety Nets

Snapshots are not backups. Let’s be clear about that. If your disk dies, snapshots die with it. But they’re incredibly useful for:

  • Pre-update safety: Snapshot before upgrading a VM, roll back if it breaks
  • Testing: Try risky changes and revert in seconds
  • Accident recovery: Restore a VM you accidentally broke 5 minutes ago

Creating Snapshots

In Proxmox UI:

  1. Select a VM or container
  2. Go to Snapshots tab
  3. Click Take Snapshot
  4. Add a description (e.g., “Before Nextcloud 28 upgrade”)

You can roll back to any snapshot instantly from the UI.

Snapshot Limitations

  • Storage overhead: Snapshots consume storage as data changes. A heavily modified VM’s snapshots can grow large.
  • Performance impact: Too many snapshots can slow down disk I/O.
  • Not a replacement for backups: Snapshots live on the same storage as the VM. Hardware failure = lost snapshots + lost VM.

Use snapshots for short-term safety during maintenance. Use vzdump or PBS for disaster recovery.

Method 4: Replication — Live VM Copies

Proxmox replication copies VMs/containers to another Proxmox node in near-real-time. This is useful for:

  • High availability (HA) setups
  • Disaster recovery across different physical locations
  • Quick failover if one node fails

How Replication Works

Replication uses ZFS send/receive (for ZFS storage) or LVM snapshots to sync VM disks to a target node every 15 minutes (configurable).

To enable replication:

  1. Datacenter → Replication → Add
  2. Select source VM and target node
  3. Set schedule (e.g., every 15 minutes)

The target node will have a read-only copy of the VM. If the source fails, you can activate the replica and start it.

Replication is NOT a Backup

Replication protects against hardware failure of one node. It does NOT protect against:

  • Accidental deletion (replicated immediately to the target)
  • Ransomware or corruption (replicated immediately)
  • User errors (replicated immediately)

You still need vzdump or PBS for versioned, restorable backups. Replication is a complement, not a replacement.

Method 5: External Backup Scripts

For ultimate flexibility, you can script your own backups using tools like rsync, rclone, or restic.

Rclone to Cloud Storage

Example: Back up Proxmox backups to Backblaze B2, AWS S3, or any cloud provider.

1
2
3
4
5
6

#!/bin/bash
# Sync local backups to B2
rclone sync /mnt/pve/backup-storage/dump/ b2:my-proxmox-backups \
  --progress \
  --checksum \
  --exclude "*.log"

Add this to cron for automated cloud backups.

Restic for Encrypted Cloud Backups

Restic provides encrypted, deduplicated backups to local or cloud storage:

1
2
3
4
5
6
7
8

# Initialize restic repo
restic -r /mnt/backup-repo init

# Back up Proxmox backup directory
restic -r /mnt/backup-repo backup /mnt/pve/backup-storage/dump/

# Or to cloud
restic -r s3:s3.amazonaws.com/my-bucket backup /mnt/pve/backup-storage/dump/

Restic handles encryption, deduplication, and incremental backups automatically.

Building Your Backup Strategy: The 3-2-1 Rule

A solid backup strategy follows the 3-2-1 rule:

  • 3 copies of your data (original + 2 backups)
  • 2 different storage types (e.g., local disk + NAS, or local + cloud)
  • 1 offsite copy (cloud, remote location, or external drive stored elsewhere)

Example Homelab Backup Strategy

Tier 1: Daily local backups

  • Vzdump or PBS to local NFS storage every night
  • Retention: 7 days
  • Purpose: Quick restores for accidents or failed updates

Tier 2: Weekly offsite backups

Tier 3: Monthly cold storage

  • Copy critical backups to an external USB drive, disconnect and store in a safe
  • Retention: 12 months
  • Purpose: Protection against ransomware, long-term archival

This strategy costs under $200/year (storage + cloud) and protects you from 99% of disasters.

Backup Best Practices

Test your backups. Restore a VM from backup every few months to verify your backups actually work. Untested backups are backups that don’t exist.

Automate everything. Manual backups will be forgotten. Use Proxmox’s scheduled jobs, PBS automation, or cron.

Monitor backup jobs. Enable email notifications in Proxmox so you know when a backup fails. Check logs regularly.

Secure your backups. Use PBS encryption for sensitive data. Store encryption keys separately from backups.

Document your restore process. Write down (or save in a password manager) how to restore from backups, where keys are stored, and any gotchas. Future-you will thank you.

Exclude what doesn’t need backup. Temporary data, cache directories, ISO storage — skip backing up data you can easily re-download.

Disaster Recovery: Restoring from Backups

Restoring from Vzdump

In Proxmox UI:

  1. Go to your backup storage location
  2. Find the backup file (.vma or .tar)
  3. Click Restore
  4. Select target node and VM ID
  5. Choose whether to keep the existing VM or replace it

Or via command line:

1
2
3
4
5

# Restore VM 100 from backup
qmrestore /path/to/vzdump-qemu-100.vma.zst 100

# Restore to a different VM ID
qmrestore /path/to/vzdump-qemu-100.vma.zst 999

Restoring from PBS

In Proxmox UI:

  1. Go to Datacenter → Backup
  2. Browse PBS storage
  3. Select the backup snapshot
  4. Click Restore
  5. Choose target node and VM ID

PBS restores are fast thanks to deduplication — it only downloads blocks that aren’t already on the Proxmox host.

Complete Disaster Recovery (Bare Metal)

If your entire Proxmox host dies:

  1. Install fresh Proxmox VE on new hardware
  2. Add your backup storage (NFS, PBS, etc.)
  3. Restore VMs one by one from backups
  4. Reconfigure networking and any host-specific settings

This is why offsite backups are crucial. Local backups are useless if your server room floods or catches fire.

Hardware Recommendations for Backups

For PBS or NAS backup targets:

For cold storage:

Common Backup Mistakes to Avoid

Backing up to the same disk as your VMs. If the disk fails, you lose both the VM and the backup. Use separate physical storage.

Not testing restores. Backups mean nothing if you can’t restore them. Test at least once every 6 months.

Skipping offsite backups. Fire, flood, theft — all destroy local backups. Always have one copy somewhere else.

Forgetting to back up Proxmox config. Your VM backups don’t include Proxmox’s own configuration. Use pvecm config backup or manually back up /etc/pve/.

Relying only on snapshots. Snapshots are not backups. They live on the same storage. Use them for short-term safety, not disaster recovery.

Conclusion

Proxmox offers robust backup options for every use case and budget. For small homelabs, vzdump with local storage is simple and effective. For larger setups or production environments, Proxmox Backup Server provides enterprise-grade features like deduplication, encryption, and fast incremental backups.

The best backup strategy combines multiple methods: local backups for quick restores, offsite backups for disasters, and regular testing to ensure everything works when you need it most.

Start with automated vzdump or PBS backups today. Add offsite replication or cloud storage next month. Your future self will thank you the first time you need to restore a VM — and you will need to restore a VM eventually.

Backups aren’t optional. They’re the difference between a minor inconvenience and a catastrophic data loss. Build your strategy, automate it, test it, and sleep better knowing your homelab is protected.