The practical question keeps popping up: if a Proxmox host or VM gets hit by ransomware, do my backups get “infected” too? With Proxmox Backup Server (PBS), properly configured, the answer is reassuring: previous backups remain intact. That’s not magic, it’s storage architecture: PBS chunks VM/CT data into content-addressed, immutable pieces. When a new backup runs, PBS re-references existing chunks that didn’t change and adds only the new ones; it does not overwrite old chunks.
So if you back up after a VM has been encrypted, that new backup will contain the encrypted state… but the older backup snapshots (their indices and the chunks they reference) are untouched. You can restore the VM to a clean point in time.
From there, it’s important to separate what PBS does well, what it doesn’t, and how to reinforce your setup with ZFS, replication, and ops hygiene so that a “3-second recovery” becomes a repeatable outcome, not a lucky anecdote.
What PBS does that helps against ransomware
- Immutable, content-addressed chunks. Each chunk is stored as a file named by its hash. Unchanged data reuses existing chunks; changed data creates new chunks. A later backup cannot corrupt chunks used by earlier backups.
- Real deduplication. Shared chunks across versions save space and shrink backup windows, which makes it easier to keep longer retention without storage pressure.
- Explicit prune + garbage collection. Chunks are not deleted automatically. You first run a prune (according to retention), then GC to free orphaned chunks. If service accounts don’t have prune/GC permissions, you minimize accidental or malicious deletion.
- Optional client-side encryption. The client (PVE/proxmox-backup-client) can encrypt backups with your key, so PBS cannot read plain data. This limits impact if PBS is breached.
- Scheduled verification. Verify jobs recompute hashes and expose silent corruption or flaky storage before a restore is needed.
Bottom line: if the ransomware impacts only the source VM/host, your historical backups on PBS remain safe and restorable.
What PBS does not do (and why ops still matters)
PBS isn’t a magic vault: if an attacker obtains admin-level credentials to PBS, they can delete backup indices or run aggressive prunes and, after a GC, you can lose history. PBS also won’t prevent an operator mistake. That’s why beyond architecture you need access controls, separation of duties, and ideally out-of-band copies.
Practical hardening
- Least-privilege accounts.
- The API key or user that PVE uses to push backups to PBS should only have “Backup” role (not Admin, not Prune).
- Reserve Prune/GC for a separate account (with MFA) and a controlled process.
- Segmentation & isolation.
- Put PBS on a separate network, not joined to AD/Domain; strict firewall (only from PVE nodes, admin IPs, and sync targets).
- If you run ZFS on PBS, dedicate datasets; do not share writeable exports to the LAN.
- Sane retention & verification.
- Retain beyond the typical ransomware dwell time (30–90 days is common; tune to risk & space).
- Schedule Verify weekly/monthly so restore day isn’t discovery day.
- Pull replication & offline copies.
- Add a secondary PBS (off-site) that pulls backups from the primary. Pull reduces blast radius: the source doesn’t hold credentials to push or delete on the target.
- For high risk, add tape (LTO) with Proxmox Tape Backup or other cold storage you can disconnect. Offline is the only thing truly immune to an online attack.
- Monitoring & alerting.
- Alert on unusual prunes, verify failures, low space, job failures.
- Log logins and ACL changes; enable 2FA for PBS GUI admins.
ZFS, snapshots and “3-second recovery”: what really happened
That video showing “I recovered in 3 seconds” on a Windows VM almost certainly used ZFS snapshots managed via sanoid/syncoid. ZFS snapshots are point-in-time views of a dataset; zfs rollback pool/dataset@snap is instant because it flips pointers.
- Pros: lightning-fast local rollbacks; with syncoid you can replicate snapshots to another ZFS system (great for DR).
- Caveat: a snapshot is not a backup by itself; if the attacker gains root on the ZFS host, they can destroy snapshots. Replicate to another host (prefer pull or restricted receive) to mitigate.
PBS vs. ZFS snapshots is not a duel; they’re complementary layers:
- ZFS snapshots = very low RTO to revert in place (or from replicated snapshots).
- PBS = versioned history, long retention, verify, optional encryption, designed for restoring elsewhere if the primary is gone.
Recovery: turning theory into practice
Restore a VM from PBS (typical path)
- Identify the pre-infection backup in PBS/PVE (by date/verify status).
- Launch Restore (PVE UI or
qmrestore) and pick the target storage. - On fast storage (NVMe) and deduplicated backups, rehydration can be very quick.
- Boot the restored VM isolated from the network, validate integrity (AV, hashes, app tests), then reconnect.
Roll back with ZFS (when applicable)
- Stop the VM or quiesce I/O to the dataset.
zfs rollback pool/VM-dataset@pre_ransom- Boot and validate.
- If using syncoid, pull a good snapshot from the replica if locals were destroyed.
Pro tip: for Windows AD/DC or stateful apps, keep their authoritative restore procedures handy (USN rollback, SQL/Exchange specifics, etc.). Backups restore bits; consistency often needs its own ritual.
Hardening checklist (printable)
- PBS on a segmented network, no end-user access.
- PBS users with minimal roles; PVE with Backup only. MFA for Admin.
- Retention ≥ estimated dwell time.
- Periodic Verify + alerts.
- Pull sync to secondary PBS / offline tape.
- ZFS snapshots and replication (if in use).
- Client-side encryption for sensitive workloads.
- WAF/Firewall in front of PBS; access via VPN/SSO.
- Quarterly restore drills (full VM & file-level).
- Runbooks for restore, accidental deletions, lost creds, full PBS failure.
Quick Q&A
Can ransomware encrypt the PBS repository?
If the attacker only compromises the source VM/host, no: PBS writes new chunks, it doesn’t rewrite old ones. If they obtain admin/write access on PBS, they could delete/prune; hence least privilege, pull replication, and offline copies.
Do I need ZFS to use PBS?
No. PBS works on ext4, xfs or ZFS. ZFS adds snapshots/replication and self-healing (checksums + scrub), which are great for backup targets.
What’s a sensible retention for ransomware?
Depends on your risk and budget. As a baseline: daily 30–60 days + weekly 3–6 months + monthly up to 12 months (adjust as needed).
Why do some claim “3-second recovery”?
That’s usually a ZFS snapshot rollback, not a full rehydration from backup. It’s valid if the snapshot survived and storage wasn’t compromised; thus the emphasis on replication and on keeping independent PBS backups.
Takeaway. PBS gives you immutable history and dependable restores when the source is hit. ZFS gives you speed via snapshots and replication. What saves the day isn’t a product label but design: least privilege, pull/offline copies, verification, and regular drills. With that, the “3-second recovery” becomes a repeatable runbook, not a viral demo.
