- The Production Compromise Threat Model: Modern ransomware groups do not simply encrypt production virtual machines; they actively compromise hypervisor credentials (Proxmox VE root access) and wipe out attached backup datastores before deploying payloads.
- Pull-Based Replication Architecture: Production Proxmox VE hosts must never have administrative credentials on the Proxmox Backup Server (PBS). Instead, PBS should execute Pull-Based Sync Jobs, logging into PVE as an unprivileged reader to pull VM state rather than allowing PVE to push writes.
- Append-Only Access Control & Token Hardening: Configure PVE API tokens with strict
Datastore.Backuppermissions only—explicitly strippingDatastore.PruneandDatastore.Modifyrights. A compromised hypervisor can create new backups, but cannot delete or encrypt historical snapshots. - Host Hardening Links: Cross-link with our Proxmox VE host hardening and ZFS encryption guide and our self-hosted secrets management (Vault vs. Infisical) review.
In modern enterprise cybersecurity, the backup infrastructure is the primary target of sophisticated ransomware actors. Threat operators dwell inside compromised networks for an average of 14 to 28 days prior to encryption, mapping network storage mounts, compromising domain credentials, and systematically purging backup repositories.
For organizations and advanced homelabs running Proxmox VE, Proxmox Backup Server (PBS) provides unmatched deduplication, client-side encryption, and incremental backup performance. However, deploying PBS with default administrator permissions leaves your organization vulnerable to total data loss if a production node is compromised. Engineering a ransomware-immutable architecture is mandatory.
How Do You Make Proxmox Backup Server Immutable?
Ransomware immutability in PBS is achieved by restricting hypervisor API tokens strictly to append-only permissions (Datastore.Backup only), removing pruning and deletion privileges from production nodes, and utilizing secondary pull-based offsite replication on isolated ZFS datastores with automated snapshot holds.
Hardening PBS requires enforcing zero-trust boundaries between hypervisors and storage nodes.
PBS Hardening & Permission Isolation Matrix
The following engineering table outlines the access control layers and protection mechanisms required to prevent ransomware tampering:
| Security Layer | Default / Vulnerable Configuration | Hardened Ransomware-Resistant Topology |
|---|---|---|
| PVE Node API Token | DatastoreAdmin (Full prune/delete rights) |
Datastore.Backup ONLY (Append-only mode) |
| Snapshot Pruning Governance | Scheduled from PVE web interface | Executed strictly by local PBS system crons |
| Replication Direction | Push (Production connects to remote PBS) | Pull (Remote offsite PBS connects to local PBS) |
| Underlying ZFS Datastore | Standard writable ZFS pool | Automated ZFS snapshots with zfs hold immutability |
| Client-Side Encryption | Optional unencrypted backups | Mandatory AES-256-GCM master key encryption |
Configuring the Append-Only API Token in PBS
To implement append-only backups, create an unprivileged user and token within PBS:
- Navigate to Access Control ➔ User Management and create a dedicated user:
pve-backup@pbs. - Under API Tokens, add a token:
pve-backup@pbs!pve-token. - Navigate to Access Control ➔ Permissions and assign the role
DatastoreBackupon path/datastore/backup-pool. - Crucially, verify that
Datastore.Prune,Datastore.Modify, andPermissions.Modifyare strictly omitted.
When this token is configured in Proxmox VE (/etc/pve/storage.cfg), hypervisors can stream new chunk data and create new backup manifests, but any programmatic attempt to delete or overwrite past snapshots returns HTTP 403 Forbidden.
The Air-Gapped Offsite Pull Replica
True ransomware resilience requires an offsite secondary instance. An offsite PBS server deployed in a separate physical location or cloud colocation should be configured with a Pull-Sync Job.
The offsite server initiates a TLS connection into the primary PBS server using read-only credentials, downloading changed chunks. The primary server has zero network access into the offsite server. Even if an attacker physically compromises every machine in your primary datacenter, they have no network route or credentials to reach the offsite replica.
Never allow production hypervisors to hold administrative or pruning privileges on your backup datastores. Restrict Proxmox VE tokens to Datastore.Backup only, schedule pruning strictly on the PBS server itself, and establish an isolated offsite PBS instance executing pull-based synchronization over WireGuard. This guarantees that even a catastrophic root-level compromise of your hypervisors cannot destroy your recovery path.