Enable immutable backups in Proxmox Backup Server.

What immutability means in PBS — honestly

Proxmox Backup Server does not have a WORM mode or an equivalent of S3 Object Lock, where even the storage administrator cannot delete data until a clock expires. What it has instead is a set of layered controls that, combined, achieve the outcome that matters: no credential present on your production systems can destroy your backup history. That's the actual threat model for ransomware — an attacker with your Proxmox VE root or your backup credentials trying to delete or encrypt your snapshots before triggering the payload.

The three layers are the protected flag on snapshots, permission separation via API tokens, and pull-based sync to a second PBS the source can't write to. Use all three; each covers a gap in the others.

Layer 1: the protected flag

Since PBS 2.1, any snapshot can be marked protected. A protected snapshot cannot be pruned, cannot be removed by forget, and cannot be deleted through the UI until the flag is cleared. In the PBS web interface: Datastore → Content → select a snapshot → Change Protection. From the command line:

# mark a snapshot protected
proxmox-backup-client snapshot protected update vm/101/2026-07-01T02:00:12Z true --repository backup@pbs!prod@pbs.example.com:datastore1

# confirm
proxmox-backup-client snapshot protected show vm/101/2026-07-01T02:00:12Z --repository ...
true

A common pattern is protecting the first snapshot of each month while normal prune rules handle everything else — monthly anchors survive even if a bad prune configuration or a hostile actor with prune rights sweeps through. Note the honest caveat: an attacker with full Datastore.Modify rights can unprotect and then delete. The flag protects against automation mistakes and limited credentials, which is why layer 2 matters.

Layer 2: credentials that can write but not destroy

The credential your Proxmox VE cluster uses for backups should be an API token whose role allows creating backups and reading its own data — and nothing else. In PBS: Configuration → Access Control → API Token, then assign the DatastoreBackup role on the datastore path. That role permits new backups and restores of the token's own backups, but not pruning, not deleting other groups, and not modifying datastore settings.

# on the PBS host: create token and scope it
proxmox-backup-manager user generate-token backup@pbs prod-cluster
proxmox-backup-manager acl update /datastore/datastore1 DatastoreBackup --auth-id 'backup@pbs!prod-cluster'

With this in place, a fully compromised PVE node can add garbage backups (annoying, recoverable) but cannot erase your history (fatal, unrecoverable). Prune rights belong to a separate admin identity used from a management workstation — never stored on the hypervisors. Our securing PBS access guide covers the full permission model.

Layer 3: pull-based offsite sync

The strongest control is a second PBS that pulls from the first. The offsite server holds credentials to read the primary; the primary holds no credentials for the offsite at all. There is nothing to steal on the production side that touches the offsite copy — even a full compromise of your site cannot reach it. Combine pull sync with its own prune policy and protected monthly anchors on the offsite server, and you have a genuinely ransomware-resilient chain.

Setup details are in our remote sync how-to and the deeper DR architecture guide. On our hosted plans, this is the recommended topology: your on-prem PBS for fast restores, a hosted instance pulling from it for offsite protection — Dedicated customers configure the sync themselves in the WebUI, and on Shared we set up the pull for you.

Don't skip verification

Immutability protects snapshots from deletion, not from bit rot or a corrupted chunk written months ago. A protected, unverifiable backup is a false sense of security. Schedule verification jobs so every snapshot is re-read and re-checksummed on a cycle — our monitoring, verify, and prune guide covers a sane schedule. On our hosted platform, ZFS checksumming underneath PBS adds a second integrity layer independent of PBS's own.