Proxmox Backup Server: 3-2-1 Backup Setup Guide (2026)

By LK Wood IV · 2026-06-01 · ~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. This is the Proxmox implementation of the rule; for the platform-agnostic version — including why RAID and a same-pool snapshot are not backups — see the 3-2-1 backup rule for homelabs.

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 9.x running with at least one VM or LXC container to protect (the steps below work the same on 8.x, but Proxmox’s lifecycle table puts VE 8’s end of support at August 2026, so a new build should start on 9)
• 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 August 2026 the current release is PBS 4.x — the download page serves proxmox-backup-server_4.2-1.iso, and the 4.x line is Debian 13 “Trixie” based. The older 3.4-1 ISO is still published alongside it if you are deliberately staying on that branch.

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. Go 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:

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

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

Configuration → 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 — and the same restore path is how you move a guest to new hardware without building a cluster.

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

# Restore a VM disk to a local path for inspection (restore <snapshot> <archive> <target>):
proxmox-backup-client restore vm/100/2026-04-29T00:30:00Z \
  drive-scsi0.img /mnt/restore-test/drive-scsi0.raw \
  --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

Use the off-site server as the destination. Configure the job there. PBS pull jobs copy from the configured remote into a datastore on the server running the job; configuring that default job on the home server would pull the other way.

1. On the off-site PBS, create or select a destination datastore called offsite. Keep it separate from the home datastore.
2. On that same off-site server, open Configuration → Remotes → Add. Name the remote home-pbs and enter the home PBS endpoint reachable over your private connection, port 8007, credentials and verified certificate fingerprint. The remote account must be able to read the home backup groups you intend to copy.
3. Still on the off-site server, open Datastore → offsite → Sync Jobs → Add. Choose Pull if the interface offers a direction field. Set Remote to home-pbs, Remote Store to pve-backups, and the local destination to offsite. Select the namespace and backup groups you actually need.
4. Schedule it for 06:00, after the home’s overnight backup completes. Leave Remove Vanished disabled so deleting a home snapshot does not also delete its off-site copy. Set a separate retention policy on the off-site datastore after checking its available capacity.
5. Run the job once. Inspect the task’s copied groups and snapshots, then open Content on the off-site offsite datastore and confirm a known home guest and its snapshot timestamp. A successful job that found zero matching groups is not an off-site copy.

Use the off-site copy for an isolated restore test, keeping any client encryption keys separately available. Check that the restored guest boots and its application data is present before counting this as copy three. The direction and fields above follow the PBS documentation; this correction did not perform a two-server restore.

Option B: Backblaze B2 with restic

If you don’t have a second site, Backblaze B2 gives you off-site object storage at $0.00695/GB/month ($6.95/TB). For 100GB of compressed, deduplicated backup data, that’s about $0.70/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 → Configuration → Notifications. PBS will email on backup failure, verify errors, and GC issues.

Uptime Kuma push monitor. Add a push-type monitor in Uptime Kuma. Send the success ping only after the backup command exits successfully; an unconditional final command can hide a failed backup.

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

If Uptime Kuma misses the expected success ping, its monitor can alert you to a late or failed job. That heartbeat does not inspect stored data and cannot detect corruption behind a successful job. Schedule PBS verification jobs and separate restore drills to check those failure modes.

PBS verify jobs. In the PBS web UI, under each datastore, schedule a Verify Job and review its snapshot selection and re-verification settings. Verification checks the integrity of the selected backups; previously verified snapshots may be skipped according to those settings. Investigate any failure in the task log. Verification and a successful heartbeat still need the application restore drill from Step 5.

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.

Sources

• Proxmox Backup Server Installation – official install steps for PBS on bare metal or as a VM.
• PBS Maintenance: Prune, GC, Verify – official reference for pruning retention, garbage collection, and verify jobs.
• PBS Managing Remotes and Sync – official docs for the remote and sync jobs used for off-site replication.
• restic Preparing a Repository – official restic docs for initializing the Backblaze B2 repository used in the off-site copy.