Proxmox Backup Server 4.1 Setup Guide (2026)

Your containers are running services you care about. Pi-hole, Caddy, Uptime Kuma, Jellyfin — whatever you've built. If you accidentally delete a container, botch an upgrade, or corrupt a config, can you get back to a working state?

Proxmox Backup Server (PBS) is the official backup solution for Proxmox VE. It deduplicates and compresses backups so they take a fraction of the raw storage. Three containers sharing the same Debian 13 base? PBS stores the shared packages once. And restoring is a few clicks in the PVE web UI.

In this guide, we'll install PBS 4.1 as a VM on your Proxmox host, connect it to PVE, run a backup, and prove the restore works by destroying a container and bringing it back. We'll also set up automated maintenance and a retention strategy so the whole thing runs itself.

Prerequisites

• A Proxmox VE 9.x host with at least one container or VM running
• SSH access to your Proxmox host
• Hardware virtualization enabled in BIOS (SVM Mode for AMD, VT-x for Intel)
• A web browser for the PBS and PVE web interfaces

Step 1: Download the PBS ISO

SSH into your Proxmox host and download the PBS 4.1 ISO directly to local storage. This is faster than downloading to your laptop and uploading through the web UI.

wget -P /var/lib/vz/template/iso/ https://enterprise.proxmox.com/iso/proxmox-backup-server_4.1-1.iso

The ISO is about 1.5 GB. Despite being on the "enterprise" URL, it's freely downloadable — no subscription required.

Always verify the checksum. You're trusting this system with your backups.

echo "670f0a71ee25e00cc7839bebb3f399594f5257e49a224a91ce517460e7ab171e  /var/lib/vz/template/iso/proxmox-backup-server_4.1-1.iso" | sha256sum -c

You should see OK. The checksum is from the Proxmox downloads page — check there if the version has been updated since this guide was written.

Step 2: Create the VM

One command creates the entire VM. Each flag is explained below.

qm create 200 \
  --name pbs \
  --cores 2 \
  --memory 4096 \
  --net0 virtio,bridge=vmbr0 \
  --scsihw virtio-scsi-single \
  --scsi0 local-lvm:32 \
  --cdrom local:iso/proxmox-backup-server_4.1-1.iso \
  --boot order=ide2 \
  --ostype l26

Step 3: Install PBS

Start the VM and open the console from the PVE web UI. The PBS installer boots to a welcome screen.

Select Install Proxmox Backup Server (Graphical) and accept the EULA.

Target disk — select the 32 GB VirtIO disk. Leave the filesystem as ext4 (LVM), which is the default.

Location and timezone — select your country and timezone.

Password and email — set a root password and enter an email address for notifications.

Network configuration — this is the most important screen. Set a static IP on your network.

Summary — review everything and click Install.

The installation takes 2-3 minutes. When it finishes, you'll see a success screen with the PBS web UI URL.

Click Reboot, then shut the VM down immediately — it will try to boot the installer ISO again. Back on your Proxmox host, remove the ISO and set the boot order to disk:

qm set 200 --cdrom none

qm set 200 --boot order=scsi0

qm set 200 --onboot 1

The first command removes the ISO. The second sets the VM to boot from disk instead of CD-ROM. The third enables autostart so PBS comes back after a host reboot.

Now start the VM:

qm start 200

Step 4: Post-Install Configuration

Run the Community Post-Install Script

Just like Proxmox VE, PBS ships with an enterprise repository that requires a paid subscription. The community post-install script fixes the repositories, disables the subscription nag, and updates the system.

This script comes from the Proxmox VE Helper-Scripts project — an open-source collection of automation scripts maintained by the community. The project was originally created by tteck, who passed away in November 2024. It's now maintained by volunteers at the community-scripts GitHub organization.

SSH into your PBS VM (or use the console):

bash -c "$(curl -fsSL https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/tools/pve/post-pbs-install.sh)"

The script presents interactive menus. Select Yes for each:

1. Correct Debian sources — fixes the apt sources for PBS 4.x
2. Disable enterprise repository — removes the paid subscription repo
3. Enable no-subscription repository — allows free updates
4. Disable subscription nag — removes the popup on every login
5. Update PBS — runs apt update && apt dist-upgrade
6. Reboot — apply all changes

Install the QEMU Guest Agent

After the reboot, install the QEMU guest agent. This is standard practice for any VM on Proxmox — it gives PVE better visibility into the guest, enables clean shutdowns, and allows PVE to freeze the filesystem during backup snapshots for consistent backups.

SSH back into the PBS VM:

apt-get install -y qemu-guest-agent

systemctl enable --now qemu-guest-agent

Then enable the agent in PVE from your Proxmox host:

qm set 200 --agent enabled=1

Reboot the VM for the agent to connect:

qm reboot 200

After the reboot, PBS is ready to use — no subscription warnings, guest agent active, and PVE has full visibility into the VM.

Step 5: Create a Datastore

A datastore is where PBS stores your backup data. Before creating one in the web UI, make the directory on disk.

mkdir -p /mnt/datastore/backups

This creates the directory on the PBS VM's root filesystem. In production, you'd want the datastore on a separate disk or ZFS pool to keep backup data isolated from the OS. For this tutorial, the root filesystem is fine.

Now open the PBS web UI at https://<your-pbs-ip>:8007 and log in as root with the password you set during installation.

In the left sidebar, click Add Datastore.

• Name: backups
• Backing Path: /mnt/datastore/backups
• Leave the GC and Prune schedules as defaults for now — we'll configure retention properly in Step 9

Click Add. The datastore appears in the left sidebar.

Step 6: Connect PVE to PBS

To connect Proxmox VE to your new backup server, you need three things: an API token, the token's permissions, and the PBS certificate fingerprint.

Create an API Token

In the PBS web UI, navigate to Configuration > Access Control and click the API Token tab.

Click Add and configure:

• User: root@pam
• Token Name: pve

Click Add. A dialog shows the token secret — copy it immediately. It's only shown once.

Grant Token Permissions

PBS 4.1 always creates tokens with privilege separation — the token has no permissions by default. Without this step, PVE will fail with a misleading "Cannot find datastore" error that makes you think the datastore doesn't exist.

SSH into your PBS VM and grant the token access to the datastore:

proxmox-backup-manager acl update /datastore/backups DatastoreAdmin --auth-id 'root@pam!pve'

This gives the token full datastore permissions: backup, restore, prune, and verify.

Verify it worked:

proxmox-backup-manager user permissions 'root@pam!pve'

You should see six permissions listed under /datastore/backups.

Get the Fingerprint

PVE needs the PBS certificate fingerprint to verify the connection (since we're using a self-signed cert). You can grab it from the PBS web UI by clicking Show Connection Information on the datastore dashboard, or via CLI:

proxmox-backup-manager cert info 2>/dev/null | grep Fingerprint

Copy the fingerprint — you'll paste it in the next step.

Add PBS Storage in PVE

Switch to the PVE web UI. Navigate to Datacenter > Storage and click Add > Proxmox Backup Server.

Fill in the connection details:

• ID: pbs
• Server: your PBS VM's IP address
• Username: root@pam!pve
• Password: the token secret you saved earlier
• Datastore: backups
• Fingerprint: the fingerprint from the previous step

Click Add. The pbs storage appears in the left sidebar.

Step 7: Create a Backup Job

Now the fun part — backing up your containers. In the PVE web UI, navigate to Datacenter > Backup and click Add.

Configure the job:

• Node: your Proxmox host
• Storage: pbs
• Schedule: pick a time (e.g., daily at 21:00)
• Selection mode: Include selected VMs/CTs
• Select the containers and VMs you want to back up
• Mode: Snapshot — backs up containers while they're running, no downtime
• Compression: ZSTD — best balance of speed and compression

On the Retention tab, leave it set to Keep all backups. Retention is managed on the PBS side — not here. We'll configure that in Step 9.

Click Create, then select the job and click Run Now to run the first backup immediately.

Step 8: Verify Backups in PBS

After the backup completes, switch to the PBS web UI and click the backups datastore. The Content tab shows your backed-up containers.

Check the Summary tab for dedup statistics. If your containers share the same OS base (which they likely do), PBS stores the shared packages once — the actual storage used will be significantly less than the raw data.

Step 9: Configure Retention

Retention controls how long backups are kept before being pruned. We're configuring this on the PBS datastore — the single source of truth for how long backups live.

In the PBS web UI, go to the backups datastore and click Prune & GC Jobs. Click Add to create a prune job.

Set the schedule to daily and configure these retention settings:

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

This is a sensible starting point. Here's what it means in practice after a few weeks of daily backups:

After a month of daily backups, you'll have roughly 10-12 total snapshots at any time — not 30+ copies eating your storage. Snapshots can satisfy multiple rules, and they only get pruned when they don't satisfy any rule.

Retention Strategies

The settings above are a good starting point, but you should adjust based on your needs. Here are common strategies from the community:

Storage-conscious homelab:

• keep-daily: 7, keep-weekly: 4

Simple and minimal. One week of daily granularity, one month of weekly. Good when storage is tight.

GFS (Grandfather-Father-Son) — most recommended:

• keep-daily: 14, keep-weekly: 8, keep-monthly: 12

Two weeks of daily, two months of weekly, a full year of monthly snapshots. This is the most battle-tested backup retention pattern. The storage cost of adding keep-monthly is almost zero thanks to deduplication — monthly snapshots share most chunks with adjacent backups.

Production-adjacent:

• keep-daily: 7, keep-weekly: 4, keep-monthly: 12, keep-yearly: 1

Adds a year of monthly granularity and one year-end snapshot. The yearly snapshot costs nothing to store (dedup) but can save you if you need to reference something from last year.

Things to Know About Retention

"Days" means days with backups, not calendar days. If you only back up on weekdays, keep-daily: 30 spans about 6 calendar weeks, not 4. This catches people off guard.

Keep Last protects ad-hoc backups. If you run a manual backup before a risky upgrade, keep-last: 3 ensures that snapshot survives even if keep-daily would otherwise prune it as a duplicate for that day.

Deduplication makes longer retention cheap. One user reported a 6x dedup ratio after a month — meaning 6 full backup snapshots consumed roughly the space of one. Don't be afraid to add keep-monthly: 12. The marginal storage cost is negligible.

Step 10: How to Restore a Backup

To demonstrate how restores work, we set up a test container with a simple nginx web page, backed it up, destroyed it completely, and restored it from PBS. Here's the restore workflow so you know what to do when you need it.

Restoring a Container

In the PVE web UI, click the pbs storage in the left sidebar, then the Content tab. This lists every backup PBS has stored.

Find the backup you want to restore — backups are listed by container/VM ID and timestamp. Select it and click Restore.

• CT ID: use the same ID as the original to replace it, or a different ID to restore alongside it
• Storage: select where the container's rootfs should go (e.g., local-lvm)
• Start after restore: check this if you want the container running immediately

Click Restore. The task log shows the progress — extracting the backup data, recreating the filesystem, and restoring the configuration.

Once complete, the container is back with the exact same state as when the backup was taken — same IP, same hostname, same config, same data.

When Would You Actually Restore?

A few common scenarios:

• Botched upgrade — you updated a service and it broke. Restore to the pre-upgrade snapshot.
• Accidental deletion — you ran pct destroy on the wrong container. Restore from the last backup.
• Corrupted config — you edited a config file and the service won't start. Restore to a known-good state.
• Migration — you want to move a container to a different storage pool. Restore the backup to the new storage with the same CT ID.

Step 11: Automate Maintenance

Your backups and pruning run on a schedule, but PBS also needs housekeeping. Here's the full picture.

Garbage Collection

When pruning removes old snapshots, it only deletes the snapshot metadata — the index that says "this snapshot contains these chunks." The actual data chunks stay on disk because other snapshots might still reference them (that's how deduplication works).

Garbage collection (GC) scans the datastore for orphaned chunks — data that no remaining snapshot references — and deletes them. This is what actually frees disk space.

GC is set to run daily by default when you created the datastore. You can verify this in the PBS web UI under the backups datastore settings.

Verify Jobs

Verify jobs check that your backup data is still readable — they read every chunk and confirm checksums match. This catches bit rot, silent disk corruption, and storage issues before you need to restore.

In the PBS web UI, go to the backups datastore and click the Verify Jobs tab.

Click Add and set:

• Schedule: weekly (e.g., Sat 02:00)
• Re-verify After: 30 days

This checks new backups weekly and re-verifies everything monthly.

Your Automated Setup

Here's what's running without any manual intervention:

PVE pushes backups. PBS manages everything else — retention, cleanup, and verification. Set it and forget it.

Step 12: Add Monitoring

If you have Uptime Kuma running, add an HTTP(s) monitor for the PBS web UI so you know if it goes down.

• Monitor type: HTTP(s)
• URL: https://<your-pbs-ip>:8007
• Ignore TLS/SSL errors: yes (PBS uses a self-signed cert)
• Interval: 60 seconds

PBS runs as a VM, so it's more susceptible to going offline than a container — a host reboot, resource contention, or a failed update could take it down. A monitor gives you visibility into its availability.

Troubleshooting

"KVM virtualisation configured, but not available"

Hardware virtualization isn't enabled in BIOS. Reboot your host, enter BIOS, and enable SVM Mode (AMD) or VT-x (Intel). On Gigabyte motherboards, it's usually under Advanced CPU Core Settings.

"Cannot find datastore" when adding PBS storage to PVE

This is almost always a permissions issue, not a missing datastore. PBS 4.1 creates API tokens with privilege separation — the token has no permissions by default. Run this on your PBS VM:

proxmox-backup-manager acl update /datastore/backups DatastoreAdmin --auth-id 'root@pam!pve'

Make sure the datastore name in the ACL path (/datastore/backups) matches the name you gave the datastore when you created it. If you named it something different, adjust the path accordingly.

The ! character breaks bash commands

Any command containing root@pam!pve must use single quotes in bash. The ! character triggers history expansion — without quotes, bash tries to interpret it as a previous command reference. Always use 'root@pam!pve' in CLI commands. The PVE and PBS web UIs handle ! correctly without quoting.

Lost the API token secret

Delete the token in PBS (Configuration > Access Control > API Token) and create a new one. You'll also need to update the PVE storage config with the new secret.

First backup is slow

Expected. The first backup has no existing data to deduplicate against, so PBS stores everything from scratch. Subsequent backups are dramatically faster because PBS only transfers changed chunks.

Storage doesn't support container directories

If pct create fails with "storage 'local' does not support container directories," use local-lvm instead. The local storage only holds ISOs and templates — container rootfs and VM disks go on local-lvm.

Summary

You now have automated backups for your Proxmox containers with:

• Proxmox Backup Server 4.1 running as a VM on your host
• QEMU guest agent for clean shutdowns and consistent backup snapshots
• Daily backups with snapshot mode (no downtime)
• Smart retention managed on PBS — daily, weekly, and monthly granularity
• Automated maintenance — pruning, garbage collection, and integrity verification all run on schedule
• Monitoring via Uptime Kuma to alert you if PBS goes offline
• Proven restores — we destroyed a container and brought it back

This setup protects against accidental deletion, bad upgrades, and corrupted configs. What it doesn't protect against is hardware failure — if the physical drive dies, the backups die with it. In a follow-up guide, we'll cover adding a second disk, external USB drives, and offsite backups via S3 to complete the 3-2-1 backup strategy.