Learn Proxmox Backup Server - Repository Security & Anti-ransomware

#Introduction

The firewall in episode 13 closes entry points from the network — but the biggest threat to modern backups actually comes from within: ransomware attacking hosts, PVE, even the backup server itself. Successful ransomware will try to encrypt everything it can reach, including your backups. Episode 14 builds repository security & anti-ransomware.

Imagine it like a safe with a double lock and copies in two cities: the double lock (client-side encryption) means a thief cannot read the contents; a safe cabinet that can be permanently locked (immutable) prevents a thief from overwriting the contents; and copies in another city (off-site) ensure an untouched version exists.

#Protection: The Anti-ransomware Layers

#Layer 1: Client-side Encryption

The foundation from episode 7 applies here: data is encrypted on the client, so even a compromised server stores no readable data. Ransomware that successfully gets into PBS only finds ciphertext that is useless to it — and for the victim, the key remains safely stored out of reach.

#Layer 2: Immutable Datastore (Read-only ZFS Snapshot)

Encryption protects confidentiality, but integrity and availability need another layer: an immutable datastore snapshot — one that cannot be modified or deleted, even by a process with root access.

If the datastore is on ZFS, take pool snapshots periodically and make them read-only:

zfs snapshot rpool/data@pbs-2026-08-13
zfs set readonly=on rpool/data@pbs-2026-08-13

readonly=on makes the snapshot unmodifiable. Any process — including a malicious script running as root — cannot write to it. This is a form of append-only/immutable storage: old data can always be read, never overwritten.

Schedule this snapshot (e.g. zfs-auto-snapshot or cron) before/alongside the backup job, then monitor via zfs list -t snapshot.

#Layer 3: Off-site Backup

Even immutable snapshots are not immune to location destruction. Patient ransomware can delete old snapshots from within (with root access) before attacking. Off-site backup from episode 10 closes this: a copy on a remote PBS that is network-separated and (ideally) isolated from admin access — if the primary location is cleaned by an attack, the remote remains intact.

#Layered Access Practices

• Primary PBS admins and off-site admins should ideally be different people/accounts (separate roles).
• Never put the keyfile in the same datastore (episode 7).
• Restrict access via minimal ACLs (episode 12) — the fewer people who can delete snapshots, the smaller the chance of abuse.

#Best Practices

#Key Rotation

Keys are not forever. Rotate keys periodically and on specific events:

• Routine: e.g. annually, or following the organization's security policy.
• Incident: when there are signs of leakage, or when key-holding personnel leave.
• Expansion: when opening access to a new team that holds keys.

Rotation practice in PBS: create a new key (proxmox-backup-client key generate --keyfile), use it for the next backups, and keep the old key as long as old snapshots exist — snapshots encrypted with the old key can only be opened with the old key. Plan a transition window before destroying the old key.

proxmox-backup-client key generate --keyfile /etc/proxmox-backup/enc-v2.key

#Auditing Task Logs

Ransomware rarely works silently — its traces are visible in logs if you look for them. Make auditing a habit:

• Review the task log periodically (proxmox-backup-manager task list) for suspicious activity: backups/restores/deletes at odd hours.
• Enable and check PBS system logs (journalctl -u proxmox-backup) and firewall logs.
• Make sure web UI access records logins; use 2FA for admins (episode 12).

proxmox-backup-manager task list --since '3 days ago'

#Closing

Key takeaways:

• Client-side encryption means a compromised server has no readable data.
• A readonly=on ZFS snapshot makes the datastore immutable — not even root can overwrite it.
• Off-site backup is a copy that survives an attack breaking through the primary location.
• Rotate keys: create a new key, keep the old key until its old snapshots expire.
• Periodic task log audits detect suspicious activity earlier.
• Simulate an attack and measure recovery time — that is real readiness.

In the next episode, episode 15, we will choose and optimize the storage medium: backup storage ZFS, ext4 & SMB/NFS — ZFS compression and checksums, the recordsize 1M best practice for backups, ext4 + LVM scenarios, and the performance trade-offs when using NFS/SMB, complete with capacity calculation. The right storage makes PBS dance!