Immutable Proxmox backups: protect your PBS against ransomware in 2026

According to the Sophos State of Ransomware 2024 report, 94 % of ransomware attacks now attempt to compromise backups before encrypting production, and 57 % of those attempts succeed in destroying or encrypting at least part of the backup repository. For an IT team that relies on Proxmox Backup Server, the conclusion is straightforward: a backup that can be erased by an attacker holding an administrative account is no longer a backup in 2026, it is just another file.

This article describes what an immutable backup actually means in a Proxmox context, the primitives PBS exposes to deliver it, how Cloud-PBS turns those primitives into a per-datastore immutability guarantee for its customers, and the upcoming move to an air-gapped LTO tape tier opening first to French customers in the third quarter of 2026.

Why ransomware targets backups first

The attack pattern has changed dramatically between 2018 and 2025. Back then, a typical ransomware encrypted whatever files it found on the infected workstation and tried to spread laterally. The ransom was negotiated against the encrypted data itself. Today, a serious ransomware crew (LockBit 4, Akira, Play, BlackBasta) follows a much more disciplined playbook: initial access through phishing or an external vulnerability, escalation to a Domain Admin account within 24 to 72 hours, hunt for the backup server, destruction or encryption of the backup repository, exfiltration of data for double extortion, and only then encryption of production.

Why this order? Because the negotiation value for the attacker is exactly proportional to your inability to restore. If your backups are accessible, working, and recent, you pay €0. If your backups are gone, you pay whatever it takes to avoid bankruptcy. The math is brutal.

The most common mistake we see when customers call us for incident response is the following: a Proxmox Backup Server installed on the same admin network as the Proxmox VE nodes it protects, accessible with the same Domain Admin as the rest of the Active Directory or LDAP domain. Once that admin account is compromised, the attacker simply SSHes into the PBS, runs an aggressive proxmox-backup-manager prune across all datastores, deletes the VM templates, and reboots the box. The backup is gone. Production will be encrypted that same evening.

An immutable backup breaks this attack chain at one specific moment: when the attacker tries to delete or modify the backup snapshots with the privileges they have obtained.

What an immutable backup actually is

The word “immutable” has been hollowed out by marketing. Technically, a backup is immutable if it satisfies two properties: it cannot be modified after being written (Write Once Read Many, WORM), and it cannot be erased before the expiration of a retention period defined outside the perimeter the attacker can compromise. The second condition is what separates real immutability from fake immutability.

Three layers can deliver this property:

1. Application-level immutability, enforced by the backup tool itself through permissions that prevent the writing account from deleting what it just wrote. This is the layer PBS exposes natively, through its per-datastore ownership model and privilege split.
2. Storage-level immutability, provided by the infrastructure layer: ZFS with immutable snapshots and ACL-locked destruction, S3 Object Lock in Compliance mode, hardened Linux repositories à la Veeam Hardened Repository, or dedicated WORM volumes.
3. Offline immutability, the ultimate tier: data lives most of the time on a physically disconnected medium, typically LTO tape in a vault, or an electrically air-gapped datastore. No network attack can reach it by construction.

The 3-2-1-1-0 rule promoted by the French ANSSI, the British NCSC, and the American CISA consolidates these layers: three copies of the data, on two different media, with one off-site copy, one offline or immutable copy, and zero verification errors. The “1” added to the historical 3-2-1 rule is precisely the immutable tier. The obligations of article 21 of the NIS2 directive, transposed into French law in 2025, point in the same direction: backups capable of resisting an internal compromise, documented restoration tests, retention within the European Union.

Immutability primitives in Proxmox Backup Server

Proxmox Backup Server is not a proprietary product with a single “immutability mode” toggle like you find in Veeam or Rubrik. It is an open-source backup engine that exposes several primitives, and it is the combination of those primitives that produces real immutability.

The ownership model and the owner-check. Every snapshot written into a PBS datastore is tagged with an owner, the account that created the snapshot. On a write or delete operation, PBS checks that the account requesting the operation is either the owner of the snapshot or holds a higher privilege (Datastore.Modify). This is the check that produces the well-known backup owner check failed error when an account tries to overwrite a snapshot it does not own.

The privilege split. PBS distinguishes six privileges on a datastore: Datastore.Audit (metadata read), Datastore.Backup (snapshot creation), Datastore.Read (download and restore), Datastore.Verify (integrity verification), Datastore.Modify (datastore configuration), Datastore.Prune (deletion). An account holding only Datastore.Backup can create backups but cannot delete them or modify the datastore. This split is the foundation of application-level immutability on PBS.

Client-side AES-256 encryption. Before sending data to the datastore, the proxmox-backup-client binary or the Proxmox VE backup module can encrypt every chunk with a key kept on the client. The key is never transmitted to the server. An attacker who compromises the PBS server without the key only sees encrypted, useless chunks. Activation details are documented in the Cloud-PBS backup encryption guide.

Cryptographic verification. PBS computes a SHA-256 hash of every chunk on write, and the proxmox-backup-manager verify command replays those hashes on a schedule. If a chunk has been altered on disk, verification fails and the affected snapshot is flagged as corrupted. This is the chunk-level integrity guarantee, and it is what allows you to reach the “0” of the 3-2-1-1-0 rule: zero verification errors.

ZFS snapshots of the datastore. When the PBS datastore lives on a ZFS dataset, periodic ZFS snapshots (managed by sanoid or by a simple cron script) add an immutability layer beneath PBS itself. Even if an attacker manages to delete a PBS snapshot, the ZFS snapshot of the datastore preserves it and a rollback can recover it. This layer is not enabled by default in Proxmox, it is an operator convention.

How Cloud-PBS delivers immutability per datastore

The Cloud-PBS architecture builds on these PBS primitives and assembles them into a managed service. Four design choices produce the application-level immutability that customers can observe from their side.

Per-tenant isolation. Every Cloud-PBS customer gets their own PBS datastore, in their own tenant. There is no datastore-level multi-tenancy. A customer account has no visibility on the datastores of other tenants. On Dedicated plans, isolation goes all the way to a dedicated PBS instance per customer, operated by our control plane.

The service account cannot delete by default. Customers can create several types of API tokens. In practice, the backup job running on your Proxmox VE writes nightly into the Cloud-PBS datastore, and an attacker who has compromised your PVE and exfiltrated that token cannot use it to delete existing snapshots if you provisioned the token with the Datastore.Backup permission only. The most they can do is add new data, which saturates the quota but does not erase the history.

Retention is driven by Cloud-PBS. The prune and garbage collection policy is enforced by our orchestration layer, by default not by your PVE. It lives in a control plane isolated from the perimeter your attacker can compromise. If you subscribed to a 14-daily + 4-weekly + 6-monthly retention, those snapshots remain available regardless of what happens on your infrastructure during the retention window.

EU regions and client-side encryption. The France and Germany regions are operated exclusively by European providers, under European jurisdiction. Combined with client-side AES-256 encryption, this means that neither Cloud-PBS, nor a datacenter operator, nor a foreign jurisdiction can access your backups in clear. This is the property required for both GDPR article 32 and NIS2 article 21.

The combined effect of these four choices, observable from the customer side, is application-level immutability that resists the textbook attack scenario described at the start of this article: a Domain Admin compromised on your PVE cannot wipe your Cloud-PBS backups. Period.

Checklist: 10 immutability controls on a Proxmox infrastructure

Adapt to your scope. If you score less than 7 out of 10, your real immutability level is lower than you think it is.

1. The PBS server is not administered with the same Domain Admin as production. Local accounts or a separate domain.
2. The API account used by backup jobs does not hold Datastore.Prune or Datastore.Modify on the target datastore.
3. The API token is stored in the PVE node keyring, not in cleartext in /etc/vzdump.conf.
4. Client-side AES-256 encryption keys are backed up offline, not only on the PVE that encrypts.
5. proxmox-backup-manager verify runs at least weekly, with an alert when a snapshot fails.
6. Retention is defined on the PBS server (Cloud-PBS side for managed customers), not on the PVE client.
7. MFA enabled on the PBS web UI for every human account.
8. A sync job to a second target (another datastore, another site, another operator) materialises the “1 off-site” of 3-2-1-1-0.
9. Documented quarterly restore test, with a test VM fully restored and booted.
10. An immutable or offline copy exists for critical workloads: dedicated ZFS snapshots of the datastore, S3 Object Lock, or air-gapped tier (see next section).

The first nine are reachable on any Proxmox environment, self-hosted or managed. The tenth is where you switch from “application-level immutability” to “physical immutability”, and that is exactly where the next move of Cloud-PBS happens.

Coming soon: Cloud-PBS air-gapped on LTO tape, early access for French customers

Application-level immutability and per-tenant isolation cover the most common external attack scenario. They do not cover two extreme scenarios: a compromised cloud operator (supply chain, malicious insider, foreign legal coercion), and a long-running advanced persistent threat patient enough to wait for the retention window to expire. For these two cases, you need a physical tier: data must live most of the time on a disconnected medium.

Cloud-PBS is preparing for the third quarter of 2026 a long-term archival tier branded Offline Backup Copy, built around LTO tape in a datacenter vault. The principle matches the strict 3-2-1-1-0 rule: the air-gapped copy is written to LTO via a dedicated robot, ejected from the robot after writing, kept in a fire-rated cabinet with traced access, and remounted on demand for ad-hoc restore or recovery testing.

Early access opens to French customers first for two reasons. The first is commercial: NIS2 compliance, transposed into French law, makes an offline copy effectively mandatory for essential and important entities, and demand is highest on this market. The second is logistical: the LTO vault sits in France, and operating a write/eject/reinsert cycle within a timeline compatible with a DR plan requires geographical proximity to the operations team while the service ramps up.

The Germany extension is planned shortly after, on the same model with a partner site in Frankfurt. The United States extension comes later, conditional on EU-side maturity and expressed demand.

In practice, for an existing Cloud-PBS customer, the air-gapped tier will appear as an extra sync job from your managed PBS datastore to the LTO target, with pricing per TB and per archival frequency. To request early access, the contact form accepts an “early access LTO” subject line, and the first installations will start during the third quarter of 2026.

Conclusion: immutability is no longer a comfort, it is a prerequisite

In 2026, a Proxmox backup strategy without a verifiable immutable layer is no longer a defensible strategy against the current threat profile. The Sophos State of Ransomware 2024 figures and the public incident record both confirm it: it is not production that decides the survival of the business after an attack, it is the operational quality of the backups at restoration time.

Proxmox Backup Server provides the technical primitives needed to build that immutable layer, and serious operators assemble them into a managed service. Cloud-PBS today delivers application-level immutability per isolated datastore, NIS2 article 21 aligned, in sovereign EU regions. The next tier up, air-gapped LTO, opens in early access for French customers in the third quarter of 2026.

To assess your current immutability level or discuss opening a Cloud-PBS account with long-term retention, contact us or check the pricing page.