A Real Story: Losing a VM at 2 AM
I run a homelab with Proxmox VE managing 12 VMs and containers — a playground for testing everything before it goes to production. One time, I updated the kernel on a VM running PostgreSQL, and after the reboot, it never came back up. I had forgotten to take a snapshot. The result: three hours of struggling to restore from a manual backup file that was a week old. If I’d had PBS back then, the entire restore process would have taken about 15 minutes.
After that incident, I switched to Proxmox Backup Server. If you’re running Proxmox VE and backing up on a “when I remember” basis — this guide will help you set up proper automated backups, once and for all.
What Is Proxmox Backup Server and Why Use It
PBS isn’t a generic backup tool — it’s software built by the Proxmox team themselves, designed specifically for the Proxmox VE ecosystem. Compared to manual backups with rsync or Clonezilla, there are a few key differences:
- Incremental backup — only stores what changed since the last backup. A 50GB VM that only changed 2GB uploads just 2GB
- Deduplication — eliminates duplicate data across VMs. My homelab saves ~65% of storage space thanks to this feature
- Zero-downtime backup — VMs keep running normally while PBS backs them up (live snapshot)
- Flexible restore — restore an entire VM or extract a specific file from inside a backup
- Prune policy — automatically deletes old backups according to predefined rules, so you never have to worry about running out of disk space
The biggest advantage for PVE users: PBS integrates directly into the Proxmox VE Web UI. Configure, monitor, and trigger manual backups — all from the familiar interface, without opening any extra tabs.
Installing Proxmox Backup Server
System Requirements
PBS must run on a separate machine — never install it on the same host or run it as a VM on the Proxmox VE you’re backing up. The reason is simple: if the main host fails, PBS needs to still be alive to restore from.
- CPU: 2 cores or more (x86_64)
- RAM: 2GB minimum, 4GB or more recommended
- Storage: roughly 1.5–2x the total size of all VMs you plan to back up
- OS: Debian 12 (PBS is Debian-based, installed from its own ISO)
My PBS machine is an old PC: 4GB RAM, 2TB HDD. Backing up 12 VMs with a 30-day retention runs comfortably with storage to spare.
Downloading the ISO and Installing
Download the PBS ISO from proxmox.com/en/downloads. The installation process is identical to Proxmox VE — boot from USB, choose your disk, set a static IP, hostname, and root password. Nothing surprising.
# After installation, access the Web UI at:
https://<PBS_IP>:8007
# Log in with:
# Username: root
# Realm: Linux PAM
# Password: the password you set during installationThe PBS interface looks a lot like PVE. If you’re already familiar with Proxmox VE, it takes about 5 minutes to get oriented.
Configuring PBS and Proxmox VE in Detail
Creating a Datastore on PBS
The datastore is where PBS stores all your backups. Point it to a dedicated disk — don’t share the OS disk, or a full disk will take down both.
# Mount the backup disk (e.g., /dev/sdb)
fdisk /dev/sdb # Create a partition if the disk is new
mkfs.ext4 /dev/sdb1
mkdir -p /mnt/backup-disk
mount /dev/sdb1 /mnt/backup-disk
# Add to /etc/fstab to auto-mount on reboot
echo "/dev/sdb1 /mnt/backup-disk ext4 defaults 0 2" >> /etc/fstabOnce mounted, go to Administration → Datastore → Add Datastore in the PBS Web UI:
- Name:
vm-backups - Backing Path:
/mnt/backup-disk
Connecting PBS to Proxmox VE
On Proxmox VE, go to Datacenter → Storage → Add → Proxmox Backup Server and fill in:
- ID:
pbs-main - Server: IP address of your PBS machine (e.g.,
192.168.1.50) - Username:
root@pam - Datastore:
vm-backups - Fingerprint: copy from PBS at Dashboard → Show Fingerprint
# Or add via CLI on the Proxmox VE node:
pvesm add pbs pbs-main \
--server 192.168.1.50 \
--datastore vm-backups \
--username root@pam \
--password YourPBSPassword \
--fingerprint AA:BB:CC:DD:... # Get the fingerprint from the PBS Web UICreating an Automated Backup Job
Go to Datacenter → Backup → Add on Proxmox VE. This is the core step — once configured, backups run automatically without you having to remember.
- Storage: select
pbs-main - Schedule:
0 2 * * *— backs up every day at 2:00 AM - Selection: All (back up all VMs) or select specific VMs/CTs
- Mode: Snapshot — VMs stay running during the backup
- Compression: Zstandard — fast, compresses well, just use it
- Send email to: enter an email address to receive alerts when a backup fails
# Run a manual backup immediately for testing (no need to wait for the schedule)
vzdump 100 --storage pbs-main --mode snapshot --compress zstdConfiguring Prune Policy — Automatically Cleaning Up Old Backups
Without a prune policy, your disk will fill up within weeks. Go to PBS Web UI: Datastore → vm-backups → Prune & GC.
The policy I use for my homelab:
- Keep Last:
3— keep the 3 most recent backups - Keep Daily:
7— 1 backup per day for the past 7 days - Keep Weekly:
4— 1 backup per week for the past 4 weeks - Keep Monthly:
3— 1 backup per month for the past 3 months
# Preview what prune will delete (--dry-run: nothing is deleted yet)
proxmox-backup-manager prune-datastore vm-backups \
--keep-last 3 \
--keep-daily 7 \
--keep-weekly 4 \
--keep-monthly 3 \
--dry-run
# Run Garbage Collection after pruning to actually reclaim disk space
proxmox-backup-manager garbage-collection start vm-backupsVerifying and Monitoring Backups
Checking Logs and Status
PBS Web UI → Dashboard shows an overview: deduplication ratio, used storage, and the last backup time. Go to Datastore → vm-backups → Content to see a list of backups for each VM by date.
# View backup logs on PBS
journalctl -u proxmox-backup -n 50
# On Proxmox VE, view vzdump task logs
pvesh get /nodes/<node-name>/tasks --typefilter vzdump
# List all backups in the datastore
proxmox-backup-client list \
--repository root@[email protected]:vm-backupsTest Restore — a Step You Should Never Skip
A backup you’ve never tested restoring is technically not a backup at all. After setting everything up, I always do a test restore of a VM into a new ID to confirm the data is intact.
# Restore VM 100 as a new VM with ID 200 for testing
qmrestore pbs-main:backup/vm/100/2025-03-01T02:00:00Z 200 \
--storage local-lvm \
--unique # Generate a new MAC address to avoid network conflictsBoot the test VM, verify your data, then delete it. The whole process takes 10–15 minutes — do it once and sleep soundly from then on.
Notifications and Alerts
PBS sends an email when a backup fails. Configure SMTP at Configuration → Notifications or via CLI:
# Configure SMTP
proxmox-backup-manager smtp-config set \
--server smtp.gmail.com \
--port 587 \
--mode starttls \
--username [email protected] \
--password "app-password-here"
# Send a test email
proxmox-backup-manager smtp-config test --email [email protected]Monitoring Performance via Dashboard
The PBS Dashboard has a few numbers worth checking regularly:
- CPU/RAM usage during active backup jobs
- Deduplication ratio — storage savings rate (typically 2x–4x)
- Backup size over time — track data growth rate
My homelab currently runs at a ~2.8x dedup ratio. 12 VMs totaling nearly 800GB raw, yet PBS only uses ~290GB on disk — thanks to incremental backups combined with deduplication.
Practical Tips from Real-World Experience
- PBS must run on a separate physical machine or host — never install PBS as a VM on the same Proxmox VE you’re backing up. When PVE goes down, PBS has to still be alive
- The first incremental backup is always slow because it has to transfer all the data — subsequent runs are much faster, uploading only what changed
- A 1Gbps local network is comfortable for overnight backups. Over WiFi it’s slow and prone to timeouts
- Remember to configure the no-subscription repo to receive security updates — the enterprise repo will throw errors without a valid license
# Configure the no-subscription repository for PBS
echo "deb http://download.proxmox.com/debian/pbs bookworm pbs-no-subscription" \
> /etc/apt/sources.list.d/pbs-no-subscription.list
apt update && apt dist-upgrade -yOnce this is set up, you have backups running automatically every night, old backups cleaned up on schedule, and email alerts when something goes wrong. Update kernels, experiment freely — worst case, restore yesterday’s snapshot and lose a few hours of work. No more lying awake at night dreading a full rebuild.
