Immutable Backups with Proxmox Backup Server: Ransomware Protection Explained

Modern ransomware doesn't just encrypt your production systems. The playbook has evolved: operators spend days or weeks inside your network, mapping infrastructure, identifying backup systems, and destroying them before triggering encryption. Veeam repositories get wiped. NAS snapshots get deleted. Backup admin credentials get harvested from memory.

Having backups isn't enough anymore. If your attacker can reach your Proxmox Backup Server with the same credentials that run your backup jobs, your recovery strategy is one rm -rf away from worthless.

This is where immutable backups enter the conversation, and where Proxmox Backup Server takes an approach that's frequently misunderstood.

The Myth of the "Immutable Flag"

Solutions like AWS S3 Object Lock or purpose-built WORM (Write Once, Read Many) storage offer explicit immutability: you write data, set a retention lock, and nothing, not even an administrator, can delete that data until the lock expires. It's a hard guarantee enforced at the storage layer.

PBS does not have this. There's no "immutable" checkbox. No retention lock API. No WORM compliance certification.

If you're coming from an enterprise backup background, this might seem like a gap. But Proxmox Backup Server achieves meaningful ransomware protection through a different mechanism: its storage architecture makes overwriting previous backups structurally impossible during normal backup operations.

This isn't the same thing as true WORM immutability, and we'll be honest about where the gaps are. But understanding how it works reveals why PBS is more resilient than it first appears.

How PBS Chunk-Based Storage Provides Protection

Content-Addressed Deduplication

Proxmox Backup Server doesn't store backups as monolithic files. When you back up a VM, PBS breaks the data into variable-length chunks, computes a SHA-256 hash of each chunk, and stores the chunk using that hash as its identifier. A backup "snapshot" is essentially a manifest: a list of chunk hashes that, together, reconstruct your VM's disk.

This is content-addressed storage: the chunk's identity is its content. Two identical blocks of data, from any VM, at any time, produce the same hash and share the same chunk on disk. That's how deduplication works in PBS and why it's so space-efficient.

But here's the property that matters for ransomware protection:

Corrupted Data Creates New Chunks

If ransomware encrypts your VM's disk, the data changes completely. Every encrypted block produces a different SHA-256 hash. When PBS backs up the now-encrypted VM, it generates an entirely new set of chunks. The backup job doesn't touch, modify, or overwrite the chunks from your previous clean backup. It can't. Those chunks have different hashes, so they're different objects in the datastore.

Walk Through a Ransomware Scenario

Here's the timeline:

Day 1 (Sunday): Scheduled backup runs. PBS creates snapshot vm/105/2026-02-08T02:00:00Z. The datastore now contains chunks representing your clean VM disk. The snapshot manifest references chunks {a1, a2, a3, ..., a500}.

Day 3 (Tuesday evening): Ransomware detonates. Your VM's disk is fully encrypted. Every file is scrambled.

Day 4 (Wednesday): The next scheduled backup runs. PBS reads the now-encrypted disk. Every chunk is different. PBS creates snapshot vm/105/2026-02-11T02:00:00Z referencing chunks {x1, x2, x3, ..., x500}. Zero overlap with the Sunday chunks. The backup completes normally. Proxmox Backup Server doesn't know or care that the data is ransomware garbage.

Day 4 (Wednesday morning): You discover the attack. You open the PBS web UI, select vm/105, pick the Sunday snapshot, and restore. The Sunday chunks are intact. Your VM comes back clean.

Configuring Proxmox Backup Server for Maximum Resilience

The architecture gives you a foundation, but configuration determines whether that foundation actually holds under attack. If you're still setting up your PBS instance, get the basics right first, then come back to harden it.

Retention Policies: Buy Yourself Time

Your retention policy defines how long old snapshots survive. If your retention is "keep last 1," a single post-ransomware backup replaces your only recovery point when the next prune runs.

A practical retention policy for ransomware resilience:

keep-daily: 7
keep-weekly: 4
keep-monthly: 6

This gives you 7 days of daily granularity to catch an attack, 4 weeks to handle slower-burning compromises, and 6 months of monthly checkpoints for worst-case scenarios. With this configuration, an attacker would need to maintain access and keep triggering backups for over 6 months before your oldest monthly snapshot gets pruned.

Tune these values to your risk tolerance and storage capacity, but the principle is clear: more history equals more resilience. We cover retention in more detail in our SMB backup best practices guide.

Verification Jobs: Detect Corruption Early

Proxmox Backup Server can verify backup integrity by re-reading chunks and confirming their hashes match. Schedule verification jobs to run regularly, weekly at minimum.

Why this matters: if chunks are corrupted on disk (hardware failure, bitrot, or even targeted tampering), you want to know now, not when you're trying to restore during an incident. A verification job that fails is an early warning. Pair this with proper monitoring and alerting so failures don't go unnoticed.

In the PBS web UI, navigate to your datastore, go to the Verify Jobs tab, and create a schedule. Verify your most recent snapshots frequently (daily for critical VMs) and run a full datastore verification weekly or monthly.

User Permissions: Principle of Least Privilege

This is where many PBS deployments leave the door wide open. If the API token or user account that your Proxmox host uses for backups also has permission to prune and delete snapshots, then an attacker who compromises that host can destroy your backups through the PBS API.

Create a dedicated backup user with only the permissions it needs:

• DatastoreBackup role: allows creating backups and listing snapshots
• Do not assign DatastoreAdmin or DatastorePowerUser, which include prune and delete rights

In the PBS shell:

# Create backup-only user
proxmox-backup-manager user create backup-agent@pbs --password <password>

# Grant backup-only access to the datastore
proxmox-backup-manager acl update / --user backup-agent@pbs --role DatastoreBackup

Pruning should be handled by a scheduled prune job on the PBS server itself, not triggered by the backup client. This way, even if every Proxmox host in your environment is compromised, the attacker can't delete or prune snapshots through the backup credentials.

Network Segmentation

The PBS server should not be accessible from the same network segment as general user workstations. Ideally, only your Proxmox hypervisors can reach it on port 8007, and administrative access is gated behind a VPN or jump host.

The Gap: Pruning and the Need for Offsite Backup

Here's where honesty matters. PBS's chunk architecture protects you from overwrite, but it doesn't protect you from deletion.

A scheduled prune job, running on the PBS server itself, will eventually remove old snapshots and garbage-collect their chunks. That's by design; you can't keep everything forever. But it means your protection has a time window defined by your retention policy.

If an attacker maintains persistent access to your network for longer than your retention window, or if they gain root access to the PBS server itself, your backups are at risk. A compromised PBS host means the attacker can:

• Modify prune schedules to aggressively delete history
• Directly delete chunk files from the filesystem
• Destroy the entire datastore

The fix is straightforward: offsite replication to a location the attacker can't reach.

Sync to an Offsite PBS Target

PBS supports syncing datastores to a remote Proxmox Backup Server instance. If you sync your backups offsite before your local prune window expires, you have a copy that survives even a total compromise of your primary PBS server.

The key requirements:

1. Geographic separation. The offsite target must be on a different network, with different credentials, inaccessible from your production environment.
2. Sync before prune. Your sync schedule must run before retention policies remove snapshots locally.
3. Independent retention. The offsite target should have its own (ideally longer) retention policy.

That's what completes the protection model. Local PBS gives you fast, architecturally-protected backups for operational recovery. Offsite sync gives you the geographic and credential separation that survives a full-environment compromise. This is the 3-2-1 backup strategy in practice.

Comparison: PBS vs. True WORM Storage

Proxmox Backup Server is not a drop-in replacement for WORM storage in compliance-driven environments. But for homelabs and SMBs running Proxmox, its architectural properties, combined with proper configuration and offsite sync, provide strong, practical ransomware protection.

Hardening Checklist

Frequently Asked Questions

Close the Loop with Offsite Sync

PBS gives you strong local protection by default. Backups can't be overwritten by a subsequent corrupted backup job. But local-only protection has limits.

At remote-backups.com, we provide managed offsite PBS storage purpose-built for this use case. Your Proxmox Backup Server syncs directly to our infrastructure over an encrypted connection, with geo-replicated storage across multiple locations. Your offsite copy lives on separate infrastructure, with separate credentials, in a separate geography. That's the isolation that closes the gap between PBS's architectural protection and full ransomware resilience.