Ransomware-resistant backup:
Proxmox Backup Server

Why a local snapshot is not enough

A snapshot on the same storage as the guest dies with the cluster. Ransomware that reaches the hypervisor or an NFS share encrypts disks and copies in one move. Proxmox Backup Server sits beside them: a separate host, datastore and API account. The PBS guide calls this ransomware protection outright: fine-grained access control, integrity verification and an off-site copy via remote sync or tape.

What PBS ships with

PBS is a client–server product (AGPLv3) tuned for Proxmox VE. The client built into PVE backs up VMs and containers; proxmox-backup-client also covers physical hosts. The stack is Rust. Namespaces split clusters and environments on one datastore without mixing ACLs. Official features:

A PBS subscription (Basic / Standard / Premium) opens the Enterprise repository and the customer portal. The server itself runs without a subscription — the same model as Proxmox VE.

The 3-2-1 model on PBS

The PBS guide cites the 3-2-1 rule: three copies, two media types, one off-site. On a Proxmox stack that looks like this:

• Copy 1 — production: VM disks on ZFS, LVM-thin, NFS or Ceph. That is not a backup.
• Copy 2 — local PBS: a datastore on a separate server (or another rack). Prune and garbage collection only on PBS, not from the cluster token.
• Copy 3 — second site or tape: a sync job to a remote PBS or a tape job. Sync can be set not to remove snapshots that vanished on the source — an attacker on the source cannot wipe the target.

If ransomware hits the source, sync usually fails and fires a notification. Tape (including WORM) is a second medium and can leave the building or sit in a vault.

Permissions: backup without delete

The Datastore.Backup privilege can create backups but not delete or alter existing ones. Practices from the guide:

• A separate API token per host or PVE cluster.
• One privilege, a narrow ACL path — e.g. /datastore/tank/pve-abc-cluster (a namespace).
• Prune only via jobs on PBS, not from the client.
• Do not give a sync token delete rights — same pattern as backup.

Detection and restore testing

If ransomware encrypts a PBS datastore, SHA-256 checksums no longer match the record — restore fails. Verify jobs check this on a schedule and start failing. The guide warns: advanced ransomware can circumvent that, so verification is an extra layer, not a sufficient one.

A stronger test: restore onto a new guest, not over production. With many VMs, automate it; if not, restore random samples weekly or monthly. Long retention matters: some ransomware sleeps for days or weeks before encrypting. Datastore verify and a restore onto an isolated guest are two different tests: the first catches a broken chunk, the second catches that the copy boots and the application answers.

What we deploy in a business

This is a service landing, not only a how-to. The package:

• Design: local PBS + a second site (sync) or tape, a namespace per cluster, 2FA on the PBS realm.
• Write-only tokens, prune and GC on the server, verify jobs, notifications (SMTP / webhook).
• PVE backup schedule, client-side encryption, VM and CT restore procedures.
• A sample restore test and a ransomware-incident runbook.

The Veeam comparison is in Veeam vs PBS. Datastore choice for backups is in storage selection.

Encryption keys and recovery

Client-side AES-256-GCM means the PBS server holds ciphertext. The guide provides a backup encryption key and a separate master key to recover keys — without the master key, losing the client password is data loss, not “reset the portal password”. We keep keys off the production cluster and off PBS itself (a safe, a separate secret store), in two copies.

Encryption does not replace ACLs. A compromised token with Datastore.Backup can still append new snapshots. It cannot rewrite old blocks — but it can fill the datastore with junk if there are no quotas and fill alerts.

Ransomware incident runbook

• Detach production from PBS: disable cluster backup jobs, leave sync without removing snapshots that vanished on the source.
• Do not log into PBS with the token that sat on the compromised cluster. Console from a separate jump host, a read / restore-only account.
• Verify the datastore (SHA-256) on a sample of groups, then restore onto a new guest on an isolated network — not onto the original VMID.
• Do not restore “in place” onto encrypted production, and do not start prune/GC “to make space” during the incident.

This is the service, not a GUI checkbox. We rehearse the runbook on a sample before anyone encrypts the cluster — otherwise the first drill is under pressure. Comparison with Veeam: Veeam vs PBS.

Prune, GC and retention

The PBS guide splits prune from garbage collection. Prune removes snapshot metadata per policy (keep-last, keep-hourly, keep-daily, keep-weekly, keep-monthly, keep-yearly). Chunks stay until GC takes them — and only after a grace period, so an accidental prune does not eat data another snapshot still holds.

We set prune policy as jobs on PBS, not from the cluster token. Sync to the second site can be told not to remove snapshots that vanished on the source: an attacker on production cannot wipe the target. Tape (including WORM) is a second medium; the same guide covers libraries and media pools, not a separate product.