Proxmox Backup Server: setup, prune, restore

A backup that lives on the machine it protects is a spare key hidden under the doormat of the house it is meant to rescue. This guide puts Proxmox Backup Server on a box of its own and ends with the only test that counts: a restore.

The short answer

How do you set up Proxmox Backup Server so that it actually saves you? Install it from the ISO on a separate machine, put the datastore on its own disk, give Proxmox VE a token that may back up but not delete, schedule prune, garbage collection and verify jobs, keep the encryption key (if you use one) away from both machines, and restore a test VM under a new ID. As of 25 Oct 2026 the current release is 4.2, published on 29 Apr 2026 [17][18]. Deduplication means every data chunk is stored once, however many snapshots refer to it [4]. How much space that saves depends entirely on your data, so we promise no number.

How it works

1. A machine of its own. The Proxmox documentation says that installing the backup server directly on the hypervisor is not recommended: a separate physical server keeps the backups reachable if the hypervisor fails [2]. The Proxmox VE manual also recommends a dedicated host for Proxmox Backup Server [14], and a Proxmox staff FAQ calls a VM, an LXC container or an installation alongside Proxmox VE possible but expert-only [20]. Our assessment: a PBS virtual machine on the host it backs up is fine for a throwaway test and wrong as your only copy. If the host dies, the backups die with it. Even a small second machine fixes that.
2. What that machine needs. For production the documentation recommends a modern 64-bit CPU with at least 4 cores, at least 4 GiB of RAM for the system plus another 1 GiB per TiB of backup storage, 32 GiB or more for the system disk, and redundant multi-gigabit network cards [2]. For the backup disk it prefers fast local storage with high IOPS for random I/O, enterprise SSDs for best results, and for hard disks a metadata cache such as a ZFS special device mirror [2]. The evaluation minimum (2 cores, 2 GB RAM, more than 8 GB disk) is explicitly not for production [2]. We cite no prices; check them on the day you buy.
3. A NAS as datastore? The documentation asks for fast local storage and does not name NFS or SMB in the requirements list we read [2]. In a 2024 discussion on the Proxmox developer list, one developer proposed adding a warning against NFS and SMB, and another Proxmox staff member objected to a blanket recommendation and suggested a small fast local datastore that is synced to a larger, slower remote one [22]. We have not measured this ourselves. Our assessment: a datastore on a network share is a compromise you should benchmark before you trust it; a local disk is the safe default.
4. Install from the ISO. Download the installer image from proxmox.com. Release 4.2-1 is 1.48 GB and dated 29 Apr 2026 [18]. Copy it to a USB stick of at least 2 GB with dd bs=1M conv=fdatasync if=./proxmox-backup-server_*.iso of=/dev/XYZ (check the device name twice, the stick is erased), or with Etcher, or Rufus in DD mode, and do not use UNetbootin [2]. The installer asks for the target disk (everything on it is erased), the file system (ext4 by default, with LVM; XFS and ZFS are options), your location, a root password of at least 8 characters (the documentation advises 12 or more) plus an email address, and the network settings [2]. ZFS on top of a hardware RAID controller is not supported and can lose data [2]. During installation you can enter either an IPv4 or an IPv6 address, not both; add the second one later [2].
5. First login and updates. Open https://<address>:8007, log in as root with the realm Linux PAM, then check IP configuration, hostname and time zone [2]. The time zone matters: all schedules use the time zone of the server [10]. The enterprise repository is enabled by default and needs a subscription; without one, switch to the no-subscription repository, which the documentation calls fine for testing and non-production use but not recommended for production servers [2]. Proxmox's press release of 29 Apr 2026 says subscriptions start at EUR 560 per server per year, with unlimited storage and clients; check proxmox.com for current terms [17]. Updates use apt update and apt full-upgrade; the FAQ warns that a plain apt upgrade can leave a rolling-release system half-upgraded [7]. The FAQ's support table lists Proxmox Backup 4 (Debian 13) with no end date announced and Proxmox Backup 3 with end of support in August 2026 [7]. That date has already passed. Both facts are as of 25 Oct 2026.
6. The datastore. A datastore is a directory on a normal Linux file system: ext4, XFS or ZFS [1]. The file system must allow at least 65,538 sub-directories per directory, because PBS pre-creates 65,536 chunk directories; FAT is not supported [1]. The documentation's own example creates a file system on a spare disk and a datastore on top in one go [1]. Take the data disk separately from the system disk.
7. Deduplication, in plain words. PBS cuts backup data into chunks and names each chunk by its SHA-256 checksum, so identical content gets the same name and is stored once [4]. Virtual disks are cut into fixed-size chunks, typically 4 MiB; file backups use dynamically sized chunks found with a rolling hash, so a changed file does not shift every later chunk [4]. A client uploads only chunks the server does not have yet, but each snapshot references all chunks and counts as a full backup [4][7]. Proxmox VE can additionally track changed blocks of a running VM with dirty bitmaps [4]. Data is compressed with Zstandard [8]. For a sense of scale, the documentation's own garbage collection example reports 327,160,886,391 bytes of original data and 52,767,414,743 bytes on disk (16 %) [5]. That is one example from the manual, not a forecast. The manual's garbage collection output ends with exactly these lines, so your own ratio should appear in your own garbage collection task log; we have not checked this on our own hardware. Two caveats: chunks encrypted with different keys do not deduplicate against each other, so Proxmox suggests separate datastores per key [13], and encrypted backups hash the plain text together with the key [4].
8. A user and a token that cannot delete. Create a user in the PBS realm, for example backup@pbs, in the web interface (Configuration, Access Control, User Management) or with proxmox-backup-manager user create [6]. Then generate an API token for each Proxmox VE host or cluster; its secret is shown only once [6]. New tokens have no permissions; you assign the role DatastoreBackup, which can back up and restore owned backups, on the narrow path of one datastore or namespace [6]. A token can never do more than its user, so the user needs the permission too [6]. The documentation recommends exactly this pattern against ransomware: separate tokens per host, minimal rights, no delete permission, and pruning done on the backup server itself with prune jobs [1].
9. Connect Proxmox VE. Add the server under Datacenter, Storage, or with pvesm add pbs [12]. You need server address, datastore, user name, password and, for a self-signed certificate, the fingerprint from proxmox-backup-manager cert info [12][13]. The PBS documentation describes an API token as an identifier of the form user@realm!tokenname plus a secret that you give a client in place of user ID and password [6]. The Proxmox VE storage page lists plain users in its examples, so we could not confirm the token form there from the manuals alone; test it before you rely on it. Backup jobs then run in the usual Proxmox VE dialogs. Snapshot mode gives the lowest downtime at a small consistency risk, and the guest agent helps with file system freezing [14].
10. Prune: decide what to keep. Prune removes snapshots by a keep policy: keep-last, keep-hourly, keep-daily, keep-weekly, keep-monthly, keep-yearly. They are applied in this order, and each option only looks at snapshots older than those already kept; weeks run Monday to Sunday [3]. Try values in the built-in prune simulator before you commit [3]. The documentation's long-term example keeps 3 last, 13 daily, 8 weekly, 11 monthly and 9 yearly snapshots and advises generous retention, because you can reduce it later but cannot recreate old snapshots [3]. Prune only deletes metadata; the data chunks stay until garbage collection [3]. Sensitive data in old chunks therefore survives pruning until the next garbage collection [3].
11. Garbage collection: free the space. Garbage collection runs in two phases per datastore. Phase one marks every chunk referenced by an index by updating its access time; phase two sweeps chunks that were not touched since a cutoff of the oldest running backup or 24 hours and 5 minutes before the start [3]. Chunks inside that grace period are reported as pending removals, which is why space does not come back at once [3]. The documentation recommends a schedule and says a weekly run is a good start [3]. Schedules use a systemd-like calendar format such as sat 04:30 or mon..fri 02:00 [10].
12. Verify: read it back. A verify job reads chunks and checks them against the SHA-256 checksums in each snapshot's manifest [3][7]. The documentation recommends re-verifying everything at least monthly, because drives degrade quietly, and suggests a frequent job for new and outdated snapshots plus a rarer job for everything [3]. For encrypted chunks the server holds only the checksum of the plain text and cannot recompute it without the key, so it checks only the CRC-32 [4]. A passing verify says the data on the disk is intact. It does not say you can restore a working system, which is what step 14 is for.
13. Keys and secrets. Client-side encryption uses AES-256 in GCM mode and is off by default [5][7]. Proxmox's own advice for a server on a trusted local network is to skip encryption, because unencrypted backups are easier to recover [13]. Encrypt when the target is less trusted, for example an offsite copy. Without the key, an encrypted backup cannot be read, and a key stored only on the machine you are rescuing is lost together with it [5]. The documentation recommends storing the key in a password manager, on a USB drive in a secure place and as a paper copy made with the paperkey subcommand [5][13]. The Proxmox VE storage accepts only keys without a password (--kdf none) [13]. A master key pair stores an RSA-encrypted copy of the key next to every backup [5]. Since 4.2, push sync jobs can also encrypt snapshots on the way to a less trusted remote [17][19].
14. The restore test. In Proxmox VE, open the storage, pick a backup and choose Restore, and give it a new VM ID so it cannot overwrite the original [21]. On the command line, list the backups with pvesm list <storage> --content backup and restore with qmrestore <volume-id> <new-vmid> [15][16][21]. The option --unique assigns a new random MAC address [15]; --start is off by default [15]. The File Restore button opens a file browser inside a backup of a VM or container on PBS [14]. For big VMs, live restore starts the VM at once and copies data in the background, with slower reads meanwhile and an undefined state if it fails [14][15]. If the server itself is gone, proxmox-backup-debug recover index can rebuild an image from index and chunk files, plus the key file for encrypted backups [4]. The documentation says outright: do periodic recovery tests [5].
15. Second copy, offsite. One PBS is one copy. A remote and a sync job pull a datastore from another PBS; you need its host, a user and its certificate fingerprint [9]. The remove-vanished option deletes snapshots locally that disappeared on the source. Proxmox points out that leaving it off keeps an attacker who controls the source from deleting your offsite copies [1][9]. Since 4.2, S3-compatible object storage is officially supported as a datastore backend; the documentation warns that providers may charge for storage, requests and traffic [1][17]. Our guide on offsite backups for the homelab covers the third copy.

A homelab example

This is an example, not a report on our systems. We make no statement about which backup software Bytearium runs or about its backup state. Assume a Proxmox VE host pve1 and a second machine pbs1 with a system SSD and a data disk sdb. The addresses are placeholders.

On pbs1, if you have no subscription, add the no-subscription repository in /etc/apt/sources.list.d/proxmox.sources and set Enabled: false in the stanza of /etc/apt/sources.list.d/pbs-enterprise.sources [2]:

Types: deb
URIs: http://download.proxmox.com/debian/pbs
Suites: trixie
Components: pbs-no-subscription
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg

Run apt update and apt full-upgrade, then create the datastore:

proxmox-backup-manager disk list
proxmox-backup-manager disk initialize sdb
proxmox-backup-manager disk fs create store1 --disk sdb --filesystem ext4 --add-datastore true

That creates the datastore under /mnt/datastore/store1 [1]. Now the user, the token and the permissions, for user and token alike [6]:

proxmox-backup-manager user create backup@pbs
proxmox-backup-manager user generate-token backup@pbs pve1
proxmox-backup-manager acl update /datastore/store1 DatastoreBackup --auth-id 'backup@pbs'
proxmox-backup-manager acl update /datastore/store1 DatastoreBackup --auth-id 'backup@pbs!pve1'

Save the token secret in your password manager. Then the jobs. Assume the Proxmox VE backup job runs at 01:00; prune at 02:30, verify at 03:30 and garbage collection on Saturday at 04:30 keep the disk busy one thing at a time. The keep values are example values; choose them by how long a damaged file could go unnoticed [3][10][11]:

proxmox-backup-manager prune-job create nightly --store store1 --schedule '02:30' --keep-last 3 --keep-daily 7 --keep-weekly 4 --keep-monthly 6
proxmox-backup-manager verify-job create verify-all --store store1 --schedule '03:30' --ignore-verified true --outdated-after 30
proxmox-backup-manager datastore update store1 --gc-schedule 'sat 04:30'

The verify job with --ignore-verified true and --outdated-after 30 checks new snapshots every night and re-checks older ones once their last verification is 30 days old [11]. Get the fingerprint, then connect pve1:

proxmox-backup-manager cert info | grep Fingerprint
pvesm add pbs pbs1 --server 192.0.2.20 --datastore store1 --username 'backup@pbs!pve1' --password --fingerprint AA:BB:CC:...

Without a value, --password makes the command ask for it [12]. After the first night, run the restore test with a VM that is not important. List the backups, then restore under a new ID, with a new MAC address, and without starting it:

pvesm list pbs1 --content backup
qmrestore pbs1:backup/vm/100/2026-10-26T00:00:07Z 901 --unique

The volume ID is the one pvesm list prints; the date here is invented [16][21]. Before the first start, disconnect the restored VM's network or change its IP address, so two copies of the same machine do not fight over one address. That step is our advice, not from the manual. Then check the things that matter: it boots, the service starts, the database opens, a known file has the expected content. Write down date and result. Finally, after the first Saturday, check the state with proxmox-backup-manager garbage-collection status store1 and read the task log of the finished run for the lines that compare original data and disk usage, as in the manual's example [5][11].

Checklist

• Install Proxmox Backup Server on a machine that is not the host it backs up, and keep the data disk apart from the system disk.
• Check the hardware against the documentation: 4 cores, 4 GiB RAM plus 1 GiB per TiB, and SSDs or a ZFS special device for hard disks.
• Choose the no-subscription repository only for testing and home use, and run apt full-upgrade rather than apt upgrade.
• Verify the time zone on the server before you set schedules.
• Create a token per Proxmox VE host with the role DatastoreBackup on a narrow path, and give the same permission to its user.
• Store the token secret in your password manager when it is shown, because it cannot be shown again.
• Test the keep policy in the prune simulator, then schedule prune jobs on the backup server, not on the clients.
• Schedule garbage collection weekly and expect the space to return after the grace period, not immediately.
• Schedule a verify job that re-checks snapshots at least monthly, and remember that it does not replace a restore test.
• Decide on encryption on purpose: skip it on a trusted LAN, use it for offsite targets, and store the key in three places away from both machines.
• Restore one non-critical VM under a new ID, without its network, every quarter, and write down the date and the result.
• Add a second PBS or an offsite target, and keep remove-vanished off unless you accept deletions to propagate.

Related pages: Proxmox or ESXi for a homelab; 3-2-1 backup and restore testing; Offsite backup for a homelab: the third copy; ZFS: mirror or RAID-Z? Planning your pool; Homelab backups with restic or Borg; Data deduplication (backups); GFS backup retention; LXC container (Proxmox). Our assessment: a ZFS mirror for the data disk is a good fit if you already plan your pool carefully; the ZFS guide covers the trade-offs.