Cloud-PBS immutable datastore architecture

Last updated: May 12, 2026

Introduction

The Cloud-PBS immutable datastore offering rests on a simple principle: a second PBS datastore, dedicated to the immutable copy, stays unmounted from the filesystem most of the time. It only mounts during the synchronisation window when it pulls data from the production datastore, and unmounts again as soon as the sync completes.

This architecture breaks several attack vectors without requiring specialised hardware (LTO, WORM, S3 Object Lock). It is available on plans that include an immutable copy.

Architecture

[Datastore A]  --- pull (PBS sync job, scheduled) --->  [Datastore B]
   mounted                                                unmounted most of the time,
   accessible                                             mounted only during sync

Two PBS datastores coexist within your Cloud-PBS tenant:

  • Datastore A is the production target. Your Proxmox VE backup jobs write into it. It is mounted permanently and reachable through your API token.
  • Datastore B is the immutable copy. It lives on a separate volume, unmounted from the PBS server filesystem most of the time. It is neither listed in the PBS GUI nor reachable through your API token while it is unmounted.

On a defined frequency (typically once a day, configurable), a PBS sync job in pull mode runs on the B side:

  1. The volume hosting B is mounted by our orchestration layer.
  2. PBS runs the pull-mode sync job, copying new chunks from A to B and applying B’s own retention policy.
  3. Once the sync completes and integrity verification finishes, the volume is unmounted.

Between cycles, B exists but stays inaccessible from the software layer: it is impossible to list snapshots, write, modify or delete its content without going through our orchestration layer that controls the mount.

Threat model covered

This architecture protects against the following attack vectors:

  • Compromise of the customer API account. The token issued to the customer only sees datastore A. It has no visibility on B and cannot read, write or delete its content. A token leak does not expose the immutable copy.
  • Compromise of Proxmox VE. An attacker who takes over your PVE and uses your credentials can damage A, but B sits in another perimeter that your PVE has no knowledge of.
  • Accidental deletion or operator mistake. A human error on A (wrong prune, wrong command, wrong retention) does not affect B before the next sync cycle, and even then the sync is unidirectional and preserves historic snapshots according to B’s own retention.
  • Ransomware targeting PBS files. A ransomware that gained shell access to the PBS server hosting A does not find B’s filesystem mounted. B’s chunks live on a volume that is not exposed to the filesystem scan at attack time.

Stated limits

The architecture is honest about what it does not cover:

  • Root compromise of the host that hosts B. An attacker holding root on the PBS server can technically remount the B volume. The protection comes from the fact that this host is hardened and operated separately from the customer perimeter, but it is not a cryptographic guarantee like S3 Object Lock.
  • Synchronisation window. During the few minutes when B is mounted, its filesystem is technically reachable from the host. A precisely timed attack could theoretically exploit it. The risk window sits between 0.1 and 1 % of total time depending on sync frequency.
  • Not a true physical air-gap. Disks stay connected and powered. Filesystem unmount is a software air-gap, not an electrical one. For a real air-gap (LTO tape in a vault), the upcoming Cloud-PBS Offline Backup Copy tier in the third quarter of 2026 targets that need.

Integrity verification

On each sync cycle, after unmount, a proxmox-backup-manager verify job can be scheduled on B’s content (this requires a temporary read-only re-mount). The result is reported in the regular operations report sent to the customer. If a verification error appears, the incident is treated as high priority by our support.

How to subscribe

The immutable datastore option is available on Dedicated plans and on some Shared plans on request. To enable this option on your existing Cloud-PBS account or to include it in a new subscription, contact us with “immutable datastore” as the subject and the desired sync frequency (daily by default).

For an overview of the ransomware context and the other immutability layers available on Proxmox, see the article Immutable Proxmox backups 2026.