Proxmox Backup Strategies: How to Never Lose a VM Again

Disclosure: This article may contain affiliate links. If you purchase through these links, we may earn a commission at no additional cost to you. We only recommend products we have personally tested or thoroughly researched.

---

I lost three months of work in 2019. Not because I didn't have backups - I had a perfectly good rsync script running every night to a USB drive. The problem? I'd never actually tested restoring from it. When the NVMe died, I plugged in the USB drive, ran the restore, and discovered the rsync script had been silently failing for two months due to a permission error I'd introduced during a system update.

That was the day I stopped treating backups as a checkbox and started treating them as infrastructure. If you're running Proxmox and your backup strategy is "I'll figure it out when something breaks," this article is for you.

Why Proxmox Backups Are Different (and Why That Matters)

If you've come from a traditional Linux environment, you might think backing up Proxmox is as simple as copying a few config files. It's not. Proxmox manages virtual machines and containers, each with their own disk images, configuration metadata, and network state. A proper backup needs to capture all of it - not just the files, but the VM's identity within Proxmox.

Proxmox gives you two main approaches:

Approach 1: Built-in vzdump - Proxmox's native backup tool. It handles live backups (no downtime), snapshots for supported storage backends, and exports to tar or VMA format. It's the Swiss Army knife - does everything reasonably well.

Approach 2: Proxmox Backup Server (PBS) - A dedicated backup solution from the Proxmox team. Think of it as vzdump on steroids - incremental backups, data deduplication, built-in verification, and a proper web UI for managing backup jobs. It's the purpose-built tool that most homelab setups should be using.

More on choosing between these later. First, let's talk about what a backup strategy actually means.

The 3-2-1 Rule for Homelabs

The 3-2-1 backup rule is deceptively simple: 3 copies of your data, on 2 different media types, with 1 copy offsite. It's been around since the early 2000s, and it's still the gold standard. Here's how it maps to a Proxmox homelab:

Copy 1: Your production VMs - The running instances on your Proxmox host. This is your primary data, not a backup.

Copy 2: Local backup - vzdump or PBS running to a local NAS, USB drive, or separate disk. This is your fast restore option - when a VM goes sideways at 2 AM, you want this within arm's reach.

Copy 3: Offsite backup - A copy that lives somewhere else. Could be a second PBS instance at a friend's house, a cloud storage bucket, or a Raspberry Pi at your parents' place running Restic to Backblaze B2.

Two media types means your backup copy shouldn't be on the same physical disk as your production data. If you're running PBS on the same NVMe as your VMs, a disk failure takes out both. Put your backup storage on a different physical device - a separate SSD, a NAS over NFS, or even a USB-connected drive.

One offsite copy protects you against fire, theft, flood, or the more common scenario: your housemate accidentally unplugging everything while vacuuming.

Method 1: vzdump - Proxmox's Built-in Backup

vzdump is what Proxmox uses under the hood for all its backup operations. You can run it from the web UI (Datacenter → Backup), the command line, or via cron for automation. Let's cover the essentials.

Basic vzdump Command

The simplest backup command looks like this:

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

Breaking that down: - 100 - The VM or container ID you want to back up - --storage local - Where to save the backup (uses Proxmox's storage definitions) - --compress zstd - Use zstd compression (best speed-to-ratio ratio for most homelabs) - --mode snapshot - Take a snapshot first, then backup from the snapshot (no downtime)

Backup Modes Explained

You have three modes to choose from, and picking the right one matters:

Snapshot mode (--mode snapshot) - Takes a storage snapshot, backs up from the snapshot, then removes it. Requires a storage backend that supports snapshots (ZFS, LVM-thin, etc.). This is what you should be using for most VMs.

Suspend mode (--mode suspend) - Pauses the VM briefly while backing up. Causes a short downtime (seconds to minutes depending on disk size). Use this when your storage doesn't support snapshots.

Stop mode (--mode stop) - Shuts down the VM, backs it up, then starts it again. Guaranteed consistency but causes downtime. Use this only for critical VMs where data consistency outweighs availability.

Practical vzdump Cron Script

Here's the cron setup I actually use on my homelab. It backs up different VMs at different times with different retention:

# /etc/cron.d/proxmox-backups

# Backup VMs 100-109 daily at 2 AM, keep 7 days
0 2 * * * root vzdump 100-109 --storage local --compress zstd \
  --mode snapshot --keep 7 --mailto admin@example.com 2>&1

# Backup VMs 200-209 weekly on Sunday at 3 AM, keep 4 copies
0 3 * * 0 root vzdump 200-209 --storage local --compress zstd \
  --mode snapshot --keep 4 --mailto admin@example.com 2>&1

# Backup container 300 daily at 4 AM (it's a database, needs frequent backups)
0 4 * * * root vzdump 300 --storage local --compress zstd \
  --mode snapshot --keep 14 --mailto admin@example.com 2>&1

Retention Policies That Actually Work

The --keep flag in vzdump handles retention automatically. But "keep 7 backups" might not be what you want. Consider this instead:

# Keep daily backups for 7 days, weekly for 4 weeks, monthly for 6 months
vzdump 100 --storage local --compress zstd --mode snapshot \
  --keep-daily 7 --keep-weekly 4 --keep-monthly 6

This gives you a reasonable retention window without eating all your disk space. For a typical VM with 50GB of used disk and zstd compression, expect backups to take roughly 15-25GB each. A retention policy like the above would need about 200-300GB of backup storage per VM.

Method 2: Proxmox Backup Server (PBS)

PBS is the dedicated backup solution from the Proxmox team, and it's what I'd recommend for any homelab running more than a handful of VMs. It uses a purpose-built datastore format with content-aware deduplication, which means incremental backups only store the changed blocks.

Why PBS Over Raw vzdump?

The main advantages:

Incremental backups - After the first full backup, PBS only transfers changed blocks. For a VM where you update a few packages weekly, this can reduce backup traffic by 90%+.

Built-in verification - PBS can automatically verify backup integrity on a schedule. Remember my rsync story? PBS would have caught that.

Deduplication - If you have 10 VMs running Ubuntu, PBS stores the common base blocks once. This can save 50-70% of storage space compared to full backups of each VM.

Web UI - A proper dashboard for managing backup jobs, monitoring storage usage, and browsing restore points.

Setting Up PBS

PBS can run as a separate machine or as a VM/container on your Proxmox host. For a homelab, running it as a VM is perfectly fine:

# On your Proxmox host, download the PBS ISO
wget https://mirrors.proxmox.com/iso/pbs/Proxmox_Backup_Server_3.2.iso \
  -O /var/lib/vz/template/iso/pbs-3.2.iso

# Create a VM for PBS (adjust resources as needed)
qm create 9000 --name proxmox-backup \
  --memory 4096 --cores 2 --net0 virtio,bridge=vmbr0 \
  --scsihw virtio-scsi-pci --scsi0 local-lvm:32 \
  --ide2 local:iso/pbs-3.2.iso,media=cdrom \
  --boot order=scsi0;ide2

For smaller homelabs (under 10 VMs), you can also install PBS directly on a Raspberry Pi or a separate mini PC. The hardware requirements are modest - 2 cores, 2GB RAM, and whatever storage you need for backups.

Configuring PBS Datastores

Once PBS is installed, create a datastore for your backups:

# Via the PBS web UI (port 8007):
# Administration → Storage / Disks → Initialize disks
# Datastore → Add Datastore

# Or via CLI:
proxmox-backup-manager datastore create homelab /dev/sdb1

The datastore will automatically manage deduplication and chunk storage. You don't need to worry about the underlying format.

Setting Up Backup Jobs

In PBS, create a backup job that pulls from your Proxmox host:

# In PBS Web UI:
# Datastore → Add Backup Job
# - Source: your Proxmox host (add via Datastore → Remote → Add)
# - Include: all VMs/CTs (or select specific IDs)
# - Schedule: daily at 2:00 AM
# - Retention: keep daily 7, weekly 4, monthly 6
# - Prune: enabled

PBS will connect to your Proxmox host and pull backups on schedule. The incremental nature means subsequent backups are fast.

Method 3: Restic for Offsite and Cloud Backups

Restic is my go-to for offsite backups. It's a backup program that supports multiple backends (local, SFTP, S3, Backblaze B2, etc.) and has built-in encryption, deduplication, and verification.

Why Restic for Offsite?

• Encrypted by default - Your backups are encrypted before they leave your network
• Multiple backends - Works with any S3-compatible storage, Backblaze B2, or even SFTP
• Fast incremental - Similar to PBS, only backs up changed blocks
• Restore flexibility - Can restore individual files or entire VMs

Restic + Proxmox Workflow

The workflow is: vzdump creates a local backup, then Restic copies it offsite.

#!/bin/bash
# /usr/local/bin/proxmox-offsite-backup.sh

# Step 1: Create fresh backup with vzdump
vzdump 100 --storage local --compress zstd --mode snapshot \
  --output json > /tmp/vzdump-result.json

# Step 2: Check if vzdump succeeded
if [ $? -ne 0 ]; then
  echo "vzdump failed for VM 100" | mail -s "Backup Alert" admin@example.com
  exit 1
fi

# Step 3: Sync the backup to offsite with Restic
export RESTIC_REPOSITORY=s3:s3.amazonaws.com/my-backup-bucket
export RESTIC_PASSWORD_FILE=/root/.restic-password

# Find the latest vzdump file
LATEST_BACKUP=$(ls -t /var/lib/vz/dump/vzdump-qemu-100-*.vma.zst | head -1)

# Backup to offsite
restic backup "$LATEST_BACKUP" --tag proxmox --tag vm-100

# Step 4: Clean up old offsite backups (keep 30 days)
restic forget --keep-daily 30 --keep-weekly 12 --keep-monthly 6 --prune

# Step 5: Verify the offsite backup
restic check

Backblaze B2 Setup

For most homelabs, Backblaze B2 is the most cost-effective offsite option at $0.005/GB/month. That's about $5/month for 1TB of backup storage.

# Install Restic
apt install restic

# Initialize the repository (first time only)
export RESTIC_REPOSITORY=s3:s3.us-east-005.backblazeb2.com/my-proxmox-backups
export RESTIC_PASSWORD_FILE=/root/.restic-password
export AWS_ACCESS_KEY_ID=your-key-id
export AWS_SECRET_ACCESS_KEY=your-application-key

restic init

Backup Verification: The Step Everyone Skips

A backup you haven't tested is a hope, not a strategy. Here's my verification process:

Automated Verification Script

#!/bin/bash
# /usr/local/bin/verify-backups.sh

LOG_FILE="/var/log/backup-verification.log"
ALERT_EMAIL="admin@example.com"

echo "$(date): Starting backup verification" >> "$LOG_FILE"

# List recent backups
BACKUPS=$(vzdump --list 2>/dev/null | grep "backup" | tail -5)

if [ -z "$BACKUPS" ]; then
  echo "WARNING: No recent backups found!" >> "$LOG_FILE"
  echo "No recent Proxmox backups found - check vzdump cron jobs" | \
    mail -s "BACKUP ALERT: No backups found" "$ALERT_EMAIL"
  exit 1
fi

# Verify backup integrity
for BACKUP_FILE in $(ls -t /var/lib/vz/dump/vzdump-qemu-*.vma.zst | head -3); do
  echo "Verifying: $BACKUP_FILE" >> "$LOG_FILE"

  # Test decompression
  if zstd -t "$BACKUP_FILE" 2>/dev/null; then
    echo "  PASS: Decompression OK" >> "$LOG_FILE"
  else
    echo "  FAIL: Decompression error" >> "$LOG_FILE"
    echo "Backup verification failed: $BACKUP_FILE" | \
      mail -s "BACKUP ALERT: Verification failed" "$ALERT_EMAIL"
  fi
done

# For PBS backups, use the built-in verification
proxmox-backup-manager verification run homelab --notify email

echo "$(date): Verification complete" >> "$LOG_FILE"

Manual Restore Testing

Once a month, I pick a random VM and do a full restore to verify the entire pipeline:

# 1. Create a test VM from backup (doesn't affect production)
vzdump 100 --storage local --compress zstd --mode snapshot

# 2. Import the backup as a new VM
qmrestore /var/lib/vz/dump/vzdump-qemu-100-*.vma.zst 999

# 3. Start the test VM and verify it works
qm start 999

# 4. Check the VM boots and services are running
qm guest cmd 999 get-networkinterfaces

# 5. Clean up
qm stop 999
qm destroy 999

Backup Storage Calculations

How much storage do you actually need? Here's a rough guide:

VM Type	Used Disk	Backup Size (zstd)	With Dedup (PBS)
Ubuntu Server	10GB	3-4GB	2-3GB
Windows Server	40GB	15-20GB	10-15GB
Docker Host	20GB	6-8GB	4-6GB
Database Server	50GB	20-30GB	15-25GB

With a 7-day retention policy, a single Ubuntu VM needs about 20-30GB of backup storage. A homelab with 5-10 VMs should budget 200-500GB for local backups, depending on your retention window.

For offsite/cloud, the numbers are similar but compressed further if you're using Restic with deduplication.

Common Mistakes I've Made (So You Don't Have To)

Mistake 1: Backing up to the same disk. I once ran PBS on the same NVMe as my VMs. When the drive failed, both production and backups were gone. Always use separate physical storage.

Mistake 2: Never testing restores. The rsync story from the beginning of this article. I've since added monthly restore tests to my calendar.

Mistake 3: Forgetting about config files. vzdump backs up VM disks, but your Proxmox host configuration (network, storage, firewall rules) lives in /etc/pve/. Back that up separately:

# Add to your cron jobs
tar czf /var/lib/vz/dump/pve-config-$(date +%Y%m%d).tar.gz /etc/pve/

Mistake 4: No alerting. A silent backup failure is worse than no backup at all. Set up email alerts for failed backup jobs and monitor your backup storage usage.

Mistake 5: Over-retaining. I kept 30 daily backups of every VM once. My 4TB backup drive filled up in weeks. Be realistic about retention - do you really need daily backups of that test VM from three months ago?

Recommended Backup Architecture

Here's the setup I recommend for most homelabs:

Production VMs (Proxmox Host)
  ├── Local Backup (vzdump → NAS/Separate Disk)
  │     ├── Daily: keep 7 days
  │     ├── Weekly: keep 4 weeks
  │     └── Monthly: keep 6 months
  └── Offsite Backup (Restic → Backblaze B2)
        ├── Daily: keep 30 days
        ├── Weekly: keep 12 weeks
        └── Monthly: keep 6 months

For small homelabs (1-5 VMs): vzdump to a USB-connected drive + Restic to Backblaze B2. Total cost: ~$5/month for B2 storage.

For medium homelabs (5-15 VMs): PBS on a separate mini PC or VM + Restic for offsite. Budget 500GB-1TB for local backup storage.

For large homelabs (15+ VMs): Dedicated PBS server with RAID + Restic to cloud. Consider a second PBS instance at a remote location.

Frequently Asked Questions

How often should I backup my Proxmox VMs?

For production VMs, daily backups are the minimum. For critical services (databases, email, anything with user data), consider backing up every 6-12 hours. Test VMs and development environments can get away with weekly backups. The frequency depends on how much data you can afford to lose - if you're running a home lab with critical self-hosted services, daily is the floor.

Does Proxmox have built-in backup?

Yes - Proxmox includes vzdump, a command-line backup tool that supports snapshots, compression, and scheduling. It's accessed through the web UI (Datacenter → Backup) or via the command line. For more advanced features like deduplication and a management UI, the Proxmox team also offers Proxmox Backup Server (PBS) as a separate product.

What is the difference between vzdump and Proxmox Backup Server?

vzdump is Proxmox's built-in backup command - it creates backup archives of VMs and containers. PBS is a dedicated backup solution that adds incremental backups, deduplication, verification, and a web management interface. Think of vzdump as the engine and PBS as the complete vehicle. For simple setups, vzdump alone is fine. For anything beyond 5-10 VMs, PBS is worth the extra setup.

Can I backup Proxmox to an external hard drive?

Absolutely. Connect a USB drive, add it as storage in Proxmox (Datacenter → Storage → Add → Directory), then point your vzdump jobs at it. The main caveat is speed - USB 3.0 drives top out around 100-150 MB/s, which is fine for most backup windows but can be slow for large initial backups. For better performance, consider a NAS connected via 1GbE or 10GbE.

How do I restore a Proxmox VM from backup?

The simplest method: go to the Proxmox web UI, navigate to your backup storage, find the backup, and click "Restore." From the command line: qmrestore /path/to/backup.vma.zst NEW_VM_ID. The VM will be recreated with its original settings and disk contents. Always restore to a new VM ID to avoid overwriting your production instance.

---

Related Reading

• Proxmox LXC vs VM: The Complete Decision Guide - Choosing between containers and VMs affects your backup strategy
• Proxmox ZFS Setup: The Only Guide Your Homelab Actually Needs - ZFS snapshots complement your backup strategy
• Docker Backup Strategies - Backup strategies for containerized workloads running inside Proxmox VMs
• Homelab Backups and Monitoring - The boring infrastructure that keeps your homelab running
• Proxmox vs ESXi vs Hyper-V 2026 - Why Proxmox's backup ecosystem is a key advantage

Official Documentation

• Proxmox VE Backup & Restore - Official vzdump documentation
• Proxmox Backup Server Documentation - Complete PBS reference
• Restic Documentation - Official Restic backup tool docs

---

Marcus Chen is a senior systems engineer who learned the hard way that backups are only as good as your last successful restore. He runs a 12-node Proxmox cluster in his home lab and hasn't lost a VM since 2019 (the year of the Great rsync Incident).