NewBuckets: S3-compatible object storage, hosted in Germany from €6/TB/mo
remote-backups.comremote-backups.com
Contact illustration
Sign In
Forgot password ?
Don't have an account ?Sign Up

Immutable Backups

A read-only copy of your Proxmox backups that nobody can modify or delete. Not you, not a rogue script, not ransomware. Protected by credential separation and controlled sync jobs.

Enable Immutable BackupsHow It Works

Three Threats, One Solution

Immutable backups create a separate datastore that syncs automatically from your primary. Deletions don't propagate. Credentials are isolated. Your data survives.

Ransomware

An attacker who compromises your PBS credentials can delete snapshots through the API. Your immutable copy is controlled by a separate sync job with separate credentials that you don't hold. Even a full credential compromise leaves the immutable data untouched.

Human Error

A misconfigured prune job set to keep 3 instead of 30 snapshots. A bulk delete on the wrong datastore. A script pointed at production instead of staging. Immutable backups maintain their own retention, independent from your primary.

Compliance

SOC 2, ISO 27001, and GDPR frameworks expect backup copies that can't be altered by the same credentials used for daily operations. Immutable backups provide exactly this: a separation of control where the backup copy is beyond the reach of normal operational access.

How Immutable Backups Work

The mechanism is straightforward: a sync job copies your backups to a second datastore with remove-vanished set to false. Deletions on your primary don't propagate.

1

Enable in your datastore settings

Set your change timeout (1-90 days), choose your retention policy, and click Enable. The change timeout locks in how long any future modification must wait before taking effect.

2

We create a dedicated immutable datastore

A second PBS datastore is created on the same server. A sync job copies your backups with remove-vanished disabled.

3

First sync runs immediately

Your existing backups are copied to the immutable datastore right away. Subsequent syncs run on your chosen schedule.

4

You receive a read-only restore token

A dedicated API token with DatastoreReader permissions. You can browse snapshots and restore, but not modify or delete.

Data Flow

Your Proxmox
Backup source
Primary Datastore
Your credentials
Immutable Datastore
Read-only for you · Sync job writes only

The sync job runs under admin credentials you don't have access to. Your restore token is DatastoreReader only.

What Makes It Immutable

Deletions Don't Propagate

The sync job uses remove-vanished: false. When you delete a snapshot from your primary datastore, it survives in the immutable copy.

Credential Separation

You hold a DatastoreReader token. All writes happen through a sync job running under admin credentials you don't have access to.

Independent Retention

The immutable datastore has its own prune schedule. Keep 7 daily on your primary but 30 daily and 12 monthly on the immutable copy.

Read-Only Access

Your restore token lets you browse and restore. You cannot write, modify, or delete anything on the immutable datastore.

Now Available

Geo-Redundant Immutable Backups

Your immutable copy can now live in a different datacenter from your primary. Enable geo-replication on your immutable datastore to get a second read-only copy on a physically separate server.

The immutable copy handles logical threats: credential compromise, accidental deletion, a rogue prune job. The geo-replicated copy handles physical ones - if the datacenter goes offline entirely, you still have a read-only copy somewhere else.

How geo-replication works →
Data Flow
Primary Datastore
Primary datacenter
Immutable Datastore
Primary datacenter
Geo-Immutable Copy
Second datacenter

Both copies are read-only for you. The geo-replicated one lives on a different physical server in a separate datacenter.

Restoring from Immutable Backups

Same tools, same workflow. The only difference is the repository string.

proxmox-backup-client restore <snapshot> <target> \
    --repository user-<id>@pbs!restore@<host>:<datastore>-imm

Your dashboard shows the full connection details with copy buttons for each field: host, datastore name, token name, and token secret.

Your restore token can:
  • Browse snapshots
  • Download and restore data
  • List datastore contents
Your restore token cannot:
  • Delete snapshots
  • Modify any data
  • Change retention or prune settings

Usage-Based Pricing

€3 per TB per month*, billed per GB per hour. You pay for the bytes your immutable snapshots actually consume, not your primary datastore's allocated size.

€3*

Per TB/Month

Based on actual usage
Per GB

Billing Granularity

Not per 100GB increments
Hourly

Billing Interval

Pay only for what you use

Cost Examples

Primary DatastoreImmutable UsageMonthly Cost
500 GB~400 GB~€1.20*
2 TB~1.5 TB~€4.50*
5 TB~4 TB~€12*

Actual immutable usage depends on your retention settings and deduplication ratio. If your primary is 2 TB but only 800 GB of unique data syncs, you pay for 800 GB.

What Immutable Backups Don't Replace

Knowing the boundaries matters as much as knowing the features.

Not WORM Storage

There's no filesystem-level write-once enforcement with compliance-grade retention locks. Immutability comes from access control: you have read-only access, writes happen through a controlled sync job.

Not Real-Time

The immutable datastore syncs on a schedule, not continuously. If a snapshot exists on your primary but hasn't synced yet, it's not in the immutable store yet. How often you sync determines how current your immutable copy is.

See the 3-2-1-1-0 strategy →

Configurable Change Timeout

When you enable immutable backups, you set a change timeout (1 to 90 days, default 1). Every security-sensitive change, whether it's updating retention settings or disabling immutability entirely, is queued and only applied after that period expires.

Set it to 7 days and an attacker who compromises your dashboard on Friday can't weaken your retention or remove immutability before you notice on Monday. You receive an email for every change, and you can cancel pending changes at any time.

  • 1-90 day delay
    You choose the waiting period when enabling immutability
  • Email on every change
    Notified when changes are queued and when they're applied
  • Cancel anytime
    Stop a pending disable before the timeout expires
  • Locked after enable
    The timeout itself cannot be shortened once set
  • Deletion protection
    Datastore cannot be deleted while immutability is active

Build a Complete Protection Stack

Each layer addresses a different threat. Together, they cover ransomware, human error, and regional disasters.

Primary Datastore

Your working backup target with daily prune jobs.

Included

Immutable Backups

Read-only copy that survives deletion and credential compromise.

€3/TB/month*

Geo-Replication

Geographic separation that survives physical disasters.

€4/TB/copy*

Edge Locations

Up to 13x faster backups over high-latency links.

Included
Learn more about the 3-2-1-1-0 backup strategy →

Enable in Under a Minute

Immutable backups are available now for all datastores.

  1. Open your datastore in the dashboard
  2. Go to Settings > Immutable Backups
  3. Set your change timeout (1-90 days) and retention policy
  4. Click Enable

Your first sync starts immediately. The dashboard shows your immutable backup status, last sync time, storage usage, and restore credentials.

Frequently Asked Questions

WORM storage (like S3 Object Lock) enforces immutability at the filesystem level with retention locks that even administrators can't override. Our immutable backups achieve practical immutability through access control: you have read-only access, and all writes happen through a controlled sync job with separate credentials. For most use cases this provides the same outcome, but it's not the same thing as compliance-grade WORM.

By default, the immutable datastore lives on the same server as your primary, protecting against logical deletion and credential compromise. With geo-replicated immutable backups enabled, a second copy is created at a physically separate datacenter, adding regional protection on top of the logical immutability. You can enable this from your datastore's immutable backup settings.

Nothing happens to the immutable copy. The sync job uses remove-vanished: false, so deletions on your primary datastore don't propagate. Your immutable snapshots remain intact with their own independent retention policy.

Yes. The immutable datastore has its own retention policy (keep-last, keep-daily, keep-weekly, keep-monthly, keep-yearly), completely independent from your primary. You configure this when enabling immutable backups.

Immutable backups are billed at €3/TB/month based on actual storage usage on the immutable datastore, measured per GB per hour. This is different from standard storage pricing (which uses 100GB increments). If deduplication means only 800GB of unique data syncs from a 2TB primary, you pay for 800GB.

Even if someone gains access to your dashboard account, disabling immutable backups triggers a waiting period equal to your configured change timeout (1-90 days). You receive an email notification immediately and can cancel the disable at any time. The same delay applies to retention setting changes, so an attacker can't weaken your prune schedule either.

Yes. The sync job copies encrypted chunks as-is. The immutable datastore contains the same encrypted data. You use the same encryption key to restore from either datastore.

Use the standard proxmox-backup-client restore command with the immutable datastore name and your read-only restore token. The dashboard shows all connection details with copy buttons.

Protect Your Proxmox Backups from Deletion

Read-only backup copies that survive ransomware, accidental deletion, and credential compromise. Optionally geo-replicated to a second datacenter. From €3/TB/month*.

Enable Immutable BackupsView All Plans

* = VAT may apply