Immutable Backups: Ransomware Protection with WORM, PBS, and ZFS Snapshots

Ransomware has evolved its approach. Modern attacks deliberately target backup systems before encrypting production data. When backups are compromised along with the original data, no recovery point remains. Immutable backups — write-protected backups that cannot be deleted or encrypted after creation — are the last line of defense.

The Concept: WORM and Immutability

What Does Immutable Mean?

An immutable backup is a backup that cannot be modified after writing — not by an administrator and not by an attacker with root access to the backup system.

WORM stands for Write Once, Read Many: data can be written once and then read any number of times but never overwritten or deleted.

Why Backups Are Vulnerable

A typical ransomware attack on backup infrastructure:

1. Initial compromise (phishing, exploit)
2. Lateral movement across the network
3. Discover backup credentials
4. Compromise backup server
5. Delete or encrypt backups
6. Encrypt production data
7. Ransom demand

Between steps 1 and 6, weeks to months often pass. During this time, the attacker has time to identify and compromise all reachable backup systems.

Three Layers of Defense

Layer	Measure	Protects Against
1. Immutability	WORM backups, immutable snapshots	Backup deletion and encryption
2. Air-Gap	Physical or logical separation	Network-based attacks
3. Credential Separation	Independent authentication	Credential theft

Professional ransomware protection combines all three layers.

Proxmox Backup Server: Immutable Datastores

Proxmox Backup Server (PBS) has offered native support for datastore-based immutability since version 3.0.

Retention-Based Protection

PBS prevents deletion of backups within the configured retention period:

Datastore configuration:
├── Name: production-backups
├── Path: /mnt/datastore/production
├── Retention:
│   ├── Keep Daily:   7
│   ├── Keep Weekly:  4
│   ├── Keep Monthly: 6
│   └── Keep Yearly:  2
└── Verification: Automatic (daily)

Namespace Isolation

PBS supports namespaces that logically separate backup data. Each namespace can have its own permissions:

# Create namespace
proxmox-backup-manager namespace create production-backups/customer-a

# Permissions: Only backup client can write
proxmox-backup-manager acl update /datastore/production-backups/customer-a \
  backup-client@pbs DatastoreBackup

The backup client has the DatastoreBackup role (write and read only) — not DatastoreAdmin (which could delete). Even if the Proxmox VE host is compromised, the attacker cannot delete backups using the backup credentials.

Client-Side Encryption

PBS supports client-side encryption with AES-256-GCM. Backups are encrypted on the Proxmox VE host before being transferred to PBS:

# Create encryption key
proxmox-backup-client key create /etc/pve/priv/backup-encryption-key.json

# Backup with encryption
proxmox-backup-client backup vm/100.img:/dev/vg/vm-100-disk-0 \
  --keyfile /etc/pve/priv/backup-encryption-key.json \
  --repository backup-user@pbs@backup-server:production-backups

Even if an attacker gains access to the PBS server, the backup data is worthless without the encryption key. The key should be stored in a secure, separate location.

Verify Jobs

PBS can automatically verify backups to ensure they are not corrupted:

# Configure verify job (checks integrity of all chunks)
proxmox-backup-manager verify-job create daily-verify \
  --store production-backups \
  --schedule "daily" \
  --outdated-after "7d"

Verify jobs detect bitrot, corrupted chunks, and other integrity issues before they surface during a restore.

TrueNAS ZFS Snapshots as Immutable Backup

ZFS snapshots are inherently read-only: a snapshot cannot be modified after creation. This makes them a natural foundation for immutable backups.

Why ZFS Snapshots Are Not Automatically Secure

An attacker with root access to the TrueNAS system can delete snapshots:

# An attacker with root access can:
zfs destroy tank/data@backup-2026-04-12
# Snapshot deleted — no immutable protection!

ZFS Snapshot Protection via Holds

ZFS offers the hold function that prevents a snapshot from being deleted:

# Set hold on snapshot
zfs hold keep tank/data@backup-2026-04-12

# Now destroy fails:
zfs destroy tank/data@backup-2026-04-12
# cannot destroy 'tank/data@backup-2026-04-12': dataset is busy

# List holds
zfs holds tank/data@backup-2026-04-12

# Remove hold (requires explicit command)
zfs release keep tank/data@backup-2026-04-12

Holds provide some protection but are not truly immutable — an attacker with root access can remove the hold and then delete.

True Immutability: Replication to a Separate System

For true immutability, snapshots must be replicated to a separate system that the attacker cannot access:

# On the source system: configure replication
zfs send -Ri tank/data@snap-001 | ssh backup-nas zfs recv -F backup-pool/data

# On the target system (backup-nas):
# - Separate credentials (no shared root password)
# - Separate network segment
# - Only inbound replication allowed (no SSH access from source)

Air-Gap Strategies

Physical Air-Gap

The classic air-gap: the backup medium is physically disconnected from the network.

Day          Action
Monday       Backup to USB HDD "A", then disconnect and store
Tuesday      Backup to USB HDD "B", then disconnect and store
...
Sunday       Weekly full backup to tape/RDX

Advantages: Maximum protection, attacker cannot reach the medium Disadvantages: Manual effort, human error (forgetting to reconnect)

Virtual Air-Gap

A virtual air-gap emulates physical separation through logical measures:

┌─────────────────┐         ┌─────────────────┐
│  Production Net │         │  Backup Net     │
│  10.0.1.0/24    │         │  10.0.99.0/24   │
│                 │         │                 │
│  Proxmox VE    │────X────│  PBS / TrueNAS  │
│  TrueNAS       │         │  (Backup target)│
└─────────────────┘         └─────────────────┘
        │                          │
   ┌────┴────┐                ┌────┴────┐
   │ VLAN 10 │                │ VLAN 99 │
   └─────────┘                └─────────┘

Firewall rules for the virtual air-gap:

# OPNsense Firewall Rules (VLAN 99 - Backup Net):
# ALLOW: Production Net → Backup Net (Port 8007, PBS)
# ALLOW: Production Net → Backup Net (Port 22, SSH for replication)
# DENY:  Backup Net → Production Net (ALL)
# DENY:  Backup Net → Internet (ALL)

The backup network can receive data but cannot communicate outbound. Even if an attacker compromises the production network, they cannot establish a connection to the backup system (no response packets possible).

Time-Scheduled Air-Gap

An elegant variant: the backup system is only reachable at defined times:

# Cron job on the firewall: backup network reachable only at night
# 02:00: Activate firewall rule
0 2 * * * pfctl -a backup_window -f /etc/pf-backup-allow.conf

# 04:00: Deactivate firewall rule
0 4 * * * pfctl -a backup_window -F rules

Outside the backup window, the backup system is completely isolated — even for an attacker who controls the production server.

Credential Separation

Separate Accounts

The backup system must use its own, independent credentials:

Component	Username	Password/Key	Note
Proxmox VE	root@pam	Password A	Hypervisor admin
PBS	backup-admin@pbs	Password B	PBS admin (separate!)
PBS API	backup-client@pbs	API token	Backup rights only
TrueNAS (Backup)	admin	Password C	Separate system

Never use the same root password or SSH key for production and backup systems.

No Domain Join for Backup Systems

The backup system should not join the Active Directory domain. An attacker who becomes Domain Admin would otherwise automatically gain access to all domain-joined systems — including backups.

Practical Example: 3-2-1 Strategy with Immutability

Backup Tier 1: Proxmox PBS (local, SSD)
├── Retention: 7 daily, 4 weekly, 6 monthly
├── Encryption: Client-side (AES-256-GCM)
├── Verify jobs: Daily
└── Credentials: Only backup-client@pbs (no admin access from PVE)

Backup Tier 2: TrueNAS (VLAN 99, virtual air-gap)
├── ZFS replication from PBS (pull mode)
├── Snapshots with holds
├── Separate admin account
└── Firewall: Only inbound replication allowed

Backup Tier 3: Offsite (cloud or physical)
├── PBS remote sync or ZFS send
├── Encrypted (keys stored offline)
├── Physically or geographically separated
└── Monthly restore tests

Testing and Validation

Immutable backups are worthless if they cannot be restored. Regular testing is mandatory:

# PBS: Verify backup integrity
proxmox-backup-client verify --repository backup-user@pbs@server:store

# TrueNAS: Check snapshot integrity
zfs list -t snapshot -o name,used,refer tank/data | tail -10

# Restore test: Restore VM from backup (on test host)
qmrestore /mnt/pbs/dump/vzdump-qemu-100-2026_04_12.vma 999 --storage local-lvm

At least once per quarter, a full restore test should be performed — from backup integrity verification to successful VM boot check.

Conclusion

Immutable backups are no longer an optional add-on — they are a necessity in every IT environment. Proxmox PBS provides a solid foundation with namespace isolation, client-side encryption, and verify jobs. TrueNAS with ZFS snapshots and replication adds a second layer. A virtual air-gap with a dedicated VLAN and restrictive firewall rules makes the backup system unreachable even for an attacker inside the production network. The combination of all three measures — immutability, air-gap, and credential separation — provides the best possible protection against ransomware.