Proxmox Backup Server: 3-2-1 Backup Setup Guide

By LK Wood IV · 2026-06-13 · ~15 min read · St. Louis County, MO

Most homelab Proxmox setups have no real backup strategy. They rely on ZFS snapshots (local-only, same hardware), maybe Clonezilla images that haven’t been tested, or a mental note to “set up backups eventually.” Eventually usually means the day a drive fails.

This guide walks through setting up Proxmox Backup Server (PBS) to cover the 3-2-1 rule: 3 copies of data, on 2 different media, with 1 copy off-site. By the end you’ll have automated daily backups, verified restores, and an off-site sync. All free, all running in your homelab.

What the 3-2-1 rule means in practice

3 copies — the production data (on your Proxmox host), a local PBS backup, and an off-site copy.

2 different media — your main host storage and the PBS datastore on separate disks or separate machines. Storing PBS on the same physical disk as your VMs is not 2-media.

1 off-site — a copy that survives your house burning down. For homelabs this is typically: a second PBS instance at a friend’s or family member’s house synced via PBS sync jobs, or a cloud backup using restic to Backblaze B2.

This guide builds copies 2 (local PBS) and 3 (off-site sync) assuming copy 1 (production) already exists on your Proxmox host.

Prerequisites

• Proxmox VE 8.x running with at least one VM or LXC container to protect
• A separate machine (or a VM on a separate host) to run PBS — bare metal is ideal
• For off-site: a second PBS node at a remote location, or a Backblaze B2 bucket

If you want to run PBS as a VM on your single Proxmox host to start, that works — you get deduplication and scheduling — but it is not a true 3-2-1 until you add the off-site piece.

Step 1: Install Proxmox Backup Server

Download PBS. Get the ISO from proxmox.com/en/downloads/proxmox-backup-server. As of 2026 the current release is PBS 3.x.

Install on bare metal or VM. The PBS installer is similar to PVE’s — choose a target disk, set hostname (I use pbs01.lan), IP address, and root password. Use a static IP on your LAN for PBS since PVE will connect to it by IP or hostname.

If installing PBS as a VM on PVE, allocate at least 2 vCPUs, 2GB RAM, and pass through or assign a dedicated disk for the backup datastore. Do not use the same physical disk your VMs live on.

Step 2: Configure a datastore

A PBS datastore is a directory that holds chunked backup data. Log into the PBS web UI at https://pbs-ip:8007.

1. Navigate to Datastore → Create Datastore
2. Set Name (e.g., pve-backups)
3. Set Backing Path — this should point to your backup disk. For a dedicated drive mounted at /mnt/backup-drive, set the path to /mnt/backup-drive/pve-backups
4. Leave Chunk Order at default (inode)
5. Click Create

Configure garbage collection. Go to the datastore → GC settings. Enable it on a schedule — daily at 3am works. GC removes chunks that are no longer referenced by any backup snapshot.

Configure prune settings. Under the datastore’s Options, set prune defaults:

Keep Last:    3
Keep Daily:   7
Keep Weekly:  4
Keep Monthly: 3

This keeps 3 most-recent backups, the last 7 daily, 4 weekly, and 3 monthly. Adjust to your storage capacity.

Step 3: Add PBS to Proxmox VE

In PVE’s web UI:

1. Datacenter → Storage → Add → Proxmox Backup Server
2. Set ID (e.g., pbs01)
3. Set Server to the PBS IP or hostname
4. Set Username to root@pam (or create a dedicated PBS user — preferred for production)
5. Set Password and the Datastore name you created
6. Click Add

PVE will connect to PBS and verify credentials. If this fails, check that port 8007 is reachable between PVE and PBS and that the PBS firewall allows the connection.

Better: create a dedicated PBS user. In PBS web UI:

Administration → Access Control → Add User
Username: pve-backup@pbs
Password: (strong password)

Then assign the DatastoreBackup role to this user on the specific datastore:

Administration → Access Control → Permissions → Add
Path: /datastore/pve-backups
User: pve-backup@pbs
Role: DatastoreBackup

Use pve-backup@pbs as the username when adding PBS to PVE instead of root@pam. This limits what the PVE connection can do on your PBS server.

Step 4: Schedule automated backups

In PVE:

1. Datacenter → Backup → Add
2. Set Storage to your PBS storage entry (pbs01)
3. Set Schedule — 00:30 daily is a good default (after midnight, before your morning activity)
4. Set Mode — Snapshot for VMs (live, no downtime), Suspend or Stop for LXC
5. Under Selection, choose which VMs/LXCs to back up — I recommend selecting all and excluding specific ones you don’t care about
6. Enable Send email notification and enter your email

For LXC containers, Snapshot mode requires the underlying storage to support snapshots (ZFS or LVM-thin). If you’re using a directory-backed storage, use Suspend mode instead.

Per-VM backup settings. On individual VMs/LXCs, you can override retention under the Backup tab. This lets high-value VMs keep 30 days of dailies while less critical containers keep only 7.

Step 5: Verify a restore

A backup you haven’t tested is not a backup. After your first scheduled backup runs:

1. In PVE, go to the VM or LXC → Backup tab
2. Select the most recent backup entry
3. Click Restore → set a new VMID (not the same one — you don’t want to overwrite production)
4. Boot the restored VM and verify it starts and the data is intact
5. Delete the test VM

Do this monthly. Seriously. Backup software has bugs, datastores corrupt, configurations drift. A monthly manual restore is the only way to know your backups are actually usable.

# Or test from the PBS CLI — list backups:
proxmox-backup-client list --repository root@pam@pbs-ip:8007:pve-backups

# Restore a VM disk to a local path for inspection:
proxmox-backup-client restore vm/100/2026-06-13T00:30:00Z \
  drive-scsi0.img:drive-scsi0.img \
  --repository root@pam@pbs-ip:8007:pve-backups

Step 6: Off-site sync (completing 3-2-1)

Option A: Second PBS node at a remote location

If you have a second PBS instance running at a trusted location (family member’s house, colocated mini PC, etc.):

1. In PBS web UI → Remotes → Add Remote
2. Enter the remote PBS IP/hostname, port (8007), and credentials
3. Navigate to Datastore → pve-backups → Sync Jobs → Add
4. Set Remote to the remote you just added, Remote Store to the remote datastore
5. Set Schedule — 06:00 daily works (a few hours after local backups complete)
6. Set Delete Vanished if you want the remote to mirror exactly (remove backups that no longer exist locally)

PBS sync is bandwidth-efficient — only changed chunks transfer. After the initial full sync, daily incrementals for a typical homelab are a few hundred MB.

Option B: Backblaze B2 with restic

If you don’t have a second site, Backblaze B2 gives you off-site object storage at $0.006/GB/month. For 100GB of compressed, deduplicated backup data, that’s about $0.60/month.

Install restic on PBS or on a separate backup machine:

apt install restic

# Initialize the B2 repository
export B2_ACCOUNT_ID=your-account-id
export B2_ACCOUNT_KEY=your-application-key
restic -r b2:your-bucket-name:pve-backups init

# Back up the PBS datastore directory
restic -r b2:your-bucket-name:pve-backups backup /mnt/backup-drive/pve-backups \
  --exclude "*.tmp"

Set this up as a systemd timer that runs after PBS’s garbage collection:

# /etc/systemd/system/restic-b2.service
[Unit]
Description=Restic backup to Backblaze B2
After=network-online.target

[Service]
Type=oneshot
EnvironmentFile=/etc/restic/b2.env
ExecStart=/usr/bin/restic -r b2:your-bucket:pve-backups backup /mnt/backup-drive/pve-backups
ExecStartPost=/usr/bin/restic -r b2:your-bucket:pve-backups forget \
  --keep-daily 7 --keep-weekly 4 --keep-monthly 3 --prune

# /etc/systemd/system/restic-b2.timer
[Unit]
Description=Run Restic B2 backup daily

[Timer]
OnCalendar=*-*-* 07:00:00
Persistent=true

[Install]
WantedBy=timers.target

systemctl enable --now restic-b2.timer

Store your B2 credentials and restic password in /etc/restic/b2.env with chmod 600. Do not hardcode them in the unit file.

Monitoring: know when backups fail

Backups that silently fail for weeks are common. Set up monitoring before you need to rely on the backups.

PBS built-in: Enable email notifications in PBS → Administration → Notifications. PBS will email on backup failure, verify errors, and GC issues.

Uptime Kuma push monitor. Add a push-type monitor in Uptime Kuma. At the end of your backup cron or systemd service, add:

curl -s "https://uptime.yourdomain.com/api/push/YOUR_PUSH_KEY?status=up&msg=PBS%20OK"

If Uptime Kuma doesn’t receive a push within your expected window, it pages you. This catches silent failures where PBS thinks it succeeded but the data is corrupted.

PBS verify jobs. In the PBS web UI, under each datastore, schedule a Verify Job. This reads every backup chunk and checks its SHA-256 hash against the stored checksum. Run it weekly. A verify job that fails means corruption — find out before you need a restore.

What this setup protects against

The one thing this doesn’t protect: your B2 account getting compromised. Restic’s encryption ensures the data itself is safe even if B2 is breached, but an attacker with B2 credentials can delete your bucket. Enable B2’s Object Lock (immutable storage) on the bucket for protection against deletion.

Storage sizing reference

Running this on a homelab power budget? A small PBS node on a mini PC with a 4TB HDD adds around 6–8W idle to your setup — about $7–9/year at average US rates. That’s cheap insurance.

For datastore sizing: assume 2.5× the sum of all your VM/LXC disk sizes for 30 days of daily backups with PBS deduplication. A homelab with 1TB of total VM disk content typically uses 600GB–1.2TB of PBS datastore space for a month of retention.

Running Proxmox? The LXC vs VM guide covers when to use each for your workloads. For ZFS datastores under PBS, the ZFS on Proxmox guide covers pool setup, ARC sizing, and Sanoid snapshot schedules that complement PBS retention. For the off-site B2 restic copy in detail, see Automated Off-Site Backups with restic. The Power & Cost Calculator shows what your PBS node adds to your monthly electricity bill.