PBS is built precisely for this threat model.

If Proxmox Backup Server (PBS) itself remains uncompromised, it provides a strong line of defence against ransomware. Here’s why, and what to do to make it even more robust.

🛡️ Why PBS is Inherently Resilient to Ransomware

✔️ 1. Immutable backups

•   PBS stores backups as chunked, append-only objects in a deduplicated store.
•   Once a backup is written, it cannot be modified or deleted through the normal file system.
•   Deletes and pruning are only possible via PBS API calls, which require valid authentication.

✔️ 2. No writable filesystem

•   The PBS datastore isn’t exposed as a mountable filesystem to other systems — no Samba/NFS shares or iSCSI-style targets that a compromised VM could reach.
•   So malware on our Windows VM cannot reach the backup chunks.

✔️ 3. Access control is strict

•   All access (backup, restore, prune) goes through the PBS API, which is authenticated and role-restricted.
•   Without explicit credentials and permissions, nothing can be pruned or altered.

🚫 What Ransomware Cannot Do (Unless PBS is Hacked)

If only our Windows VMs or Proxmox VE host are compromised:

•   They cannot reach into PBS backup chunks directly
•   They cannot delete or encrypt the datastore
•   They cannot modify existing backups

Unless the attacker:

•   Gains PBS root access
•   Obtains valid backup prune credentials
•   Executes an API-based deletion

🔐 Additional Measures to Harden PBS

To make this near bulletproof:

✅ 1. Use strict PBS ACLs

•   For each VM’s backup group, assign:
•   Backup only: Datastore.Backup
•   Restore: Datastore.Read
•   Prune: only to trusted admin accounts

🔒 VMs themselves should never have permissions to prune or delete their own backups.

✅ 2. Use a separate PBS node (physical or VM)

•   Hosted on different hardware or virtualised host
•   Not managed from the same Proxmox cluster (if possible)
•   Isolated via firewall or VLAN if needed

✅ 3. Enable backup verification (integrity scans)

PBS can verify backups via:

proxmox-backup-client verify …

Or scheduled via the UI.

This ensures no silent corruption has occurred.

⸻

✅ 4. Replicate backups externally

As you’re planning: store long-term retention on external disks or remote PBS.

•   Disconnected or write-restricted storage
•   Air-gapped USB or cold storage rotation
•   Read-only remote PBS (via sync + strict roles)

⸻

✅ Summary

Scenario	Backups safe?
Windows VM infected with ransomware	✅ Yes
Proxmox VE host infected (not root)	✅ Yes
PBS API credentials leaked	⚠️ Maybe
PBS root access compromised	❌ No

So:

As long as PBS is isolated, authenticated, and unbreached, our backups are ransomware-resilient.

•   A checklist of ACL settings
•   Auto-verification schedules
•   Remote PBS sync setup guide

More details

📦 Proxmox Backup Server (PBS) — Ransomware Resilience Summary

This further document outlines the resilience of Proxmox Backup Server (PBS) against ransomware attacks under various threat scenarios. It assumes that PBS is properly configured and that basic access controls are enforced.

✅ Ransomware Protection Summary

Scenario	Backups safe?	Explanation
Windows VM infected with ransomware	✅ Yes	Backup storage is not exposed to the guest VM and cannot be accessed or modified from inside it.
Proxmox VE host infected (not root)	✅ Yes	Without root or backup privileges, the VE host cannot tamper with PBS storage or APIs.
PBS API credentials leaked	⚠️ Maybe	If the leaked credentials include prune/delete rights, backups may be deleted via the API. Use strict role separation.
PBS root access compromised	❌ No	If the PBS host is fully compromised, an attacker can delete or destroy all backup data. External replication is strongly recommended.

🔐 Best Practice Recommendations

1. Apply Role-Based Access Control (RBAC)

• Use PBS roles such as:
• Datastore.Backup — allow backing up only
• Datastore.Read — allow restores but no deletion
• Datastore.Admin — only for trusted administrators
• Do not assign prune or delete permissions to users or automation that does not require it.

2. Isolate the PBS Host

• Run PBS as a separate VM or physical host not part of the same cluster (if possible).
• Use VLANs or firewall rules to restrict access to PBS ports and APIs.
• Avoid managing PBS from the same place as Proxmox VE.

3. Use External or Offsite Replication

• Add an external disk or remote PBS node for long-term backup retention.
• Use PBS sync jobs to replicate selected snapshots offsite or to cold storage.
• Rotate removable drives to air-gapped storage if needed.

4. Enable Scheduled Backup Verification

• Use PBS’s built-in verification features to validate backup integrity.
• Schedule checks via:
• PBS GUI → Verify Task
• Or CLI: proxmox-backup-client verify ...

5. Monitor Logs and Retention Policies

• Regularly check logs for unexpected deletions or prune events.
• Use retention policies to automate pruning but limit damage from accidental or malicious deletions.

🧠 Remember

Proxmox Backup Server provides immutable, append-only backup storage that is inherently safe from malware running on client machines. As long as PBS itself remains uncompromised, backups are highly resilient.

🔐 Defend PBS like our crown jewels — because once it’s breached, all protection collapses.

📎 Additional Resources

• Proxmox Backup Server Documentation
• https://pbs.proxmox.com/docs/
• ZFS Snapshots & Resilience
• https://openzfs.github.io/openzfs-docs/
• PBS Sync & Prune Documentation
• https://pbs.proxmox.com/docs/sync-jobs.html

July 15, 2025

---

Previous post

Major Differences — Structured Comparison Clause ——————————————————————– | | 1. Definitions | Basic legal party definitions; “Working Day” not explicitly defined | Expanded definitions;

Next post

📚 Key Frameworks & Documentation on AI Transparency and Classification Provides best practices for documenting AI systems in a comparable, legible, actionable, and robust manner. Supports user understanding of design