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 an offsite copy on a second PBS that your production credentials can't destroy. 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: an offsite copy production can't destroy

The third layer is a second PBS, offsite, holding a copy your production site cannot erase. The way to get one is a push sync job (PBS 3.3+) from your primary to the offsite server — using the same principle as layer 2: the push credential is scoped so it can add snapshots but cannot prune or delete other groups. A compromised primary can then push garbage offsite (annoying, recoverable) but cannot reach back and destroy the history already there. The offsite server enforces its own retention and its own protected monthly anchors, independent of anything your site says. Keep Remove vanished off on the sync job so a mass deletion on the primary never propagates.

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, pushing to a hosted instance for offsite protection — self-service on every plan, syncing minutes after you create the job. If your threat model demands that production hold no offsite credential at all, a pull topology inverts the direction entirely — contact us and we'll set it up with 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.