Immutable Backups Are Now Available

So you have backups. That's great. But what happens when someone (or something) deletes them?

A compromised admin account. A rogue script with too many permissions. Ransomware that goes after your backup infrastructure before encrypting production. Or just a simple mistake during a late-night maintenance window. These things happen, and when they do, your "last line of defense" is gone.

We've been thinking about this for a while, and today we're launching Immutable Backups. The idea is simple: we create a completely read-only copy of your backup data, separate from your primary datastore. You can restore from it, but you can't modify or delete it. Nobody can, except the sync job running under our admin credentials.

What Are Immutable Backups?

When you enable immutable backups, we create a second datastore alongside your primary one. A sync job runs on the schedule you choose (typically once a day) and copies all your backup snapshots to this immutable datastore.

The key property: remove-vanished is set to false. This means that when you delete a snapshot from your primary datastore, whether manually, through a prune job, or because an attacker wiped it, that deletion does not propagate to the immutable copy. The snapshot survives.

You get a read-only API token (DatastoreReader role) that lets you browse and restore from the immutable datastore. You can't write to it, modify it, or delete anything from it. All writes happen through the sync job running under our admin credentials.

That's what makes it immutable from your perspective: no credential you hold can alter the data.

Why This Matters

Ransomware Resilience

We wrote about how PBS protects against ransomware through its chunk-based architecture a few weeks ago. The architectural protection is real: a corrupted backup creates new chunks without touching the clean ones.

But there's a gap. An attacker who gains access to your PBS credentials can still delete snapshots through the API or modify prune schedules to aggressively remove history. Immutable backups close this gap. Even if every credential you manage is compromised, the immutable copy remains untouched because it's controlled by a separate sync job with separate credentials that you don't have access to.

Protection Against Human Error

Not every data loss involves an attacker. A misconfigured prune job that was supposed to keep 30 daily snapshots but was set to keep 3. A bulk delete that targeted the wrong datastore. A script that ran against production instead of staging. We've all been there (or at least close to it).

Immutable backups survive all of these because they maintain their own independent retention policy. Your mistakes on the primary datastore don't cascade to the immutable copy.

Compliance and Audit Requirements

Many regulatory frameworks (SOC 2, ISO 27001, GDPR data protection requirements) expect organizations to maintain 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 It Works

Restore Access

Restoring from your immutable backups uses the same tools you already know. 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 (host, datastore name, token name, and token secret) with copy buttons for each field.

Independent Retention

The immutable datastore has its own prune schedule, completely independent from your primary. You might keep 7 daily snapshots on your primary but 30 daily and 12 monthly on the immutable copy. This way your immutable backups can preserve history far longer than your primary, giving you a much deeper recovery window.

You can configure retention when enabling immutable backups:

• Keep Last: number of most recent snapshots
• Keep Daily: daily snapshots to retain
• Keep Weekly: weekly snapshots to retain
• Keep Monthly: monthly snapshots to retain
• Keep Yearly: yearly snapshots to retain

Pricing

Immutable backups are priced based on actual storage usage on the immutable datastore:

€3 per TB per month, billed per GB per hour.

This is a bit different from how we bill standard storage and geo-replication (which are based on allocated datastore size in 100GB steps). Immutable backup pricing is based on how much data actually lives in the immutable datastore. So you only pay for the bytes your immutable snapshots consume.

Cost Examples

To give you a rough idea:

• 500GB primary, ~400GB immutable usage: ~€1.20/month
• 2TB primary, ~1.5TB immutable usage: ~€4.50/month
• 5TB primary, ~4TB immutable usage: ~€12/month

The actual immutable usage depends on your retention settings and how much deduplication can save across your snapshots.

What Immutable Backups Don't Replace

Let's be honest about the limitations.

This is not geo-replication. Your immutable copy lives on the same server as your primary datastore. It protects against logical deletion and credential compromise, not against physical server failure or a fire in the data center. For geographic protection, combine immutable backups with geo-replication.

This is not WORM storage. We don't offer filesystem-level write-once enforcement with compliance-grade retention locks. The immutability comes from access control: you have read-only access, writes happen through a controlled sync job. For most use cases this provides the same practical outcome, but it's not the same thing as S3 Object Lock.

This does not protect against server-level compromise. If someone gains root access to the physical server, they could theoretically access the immutable datastore. For that level of protection, geo-replication to a separate server is the answer.

Disabling Immutable Backups

We built in a safety net for this. When you request to disable immutable backups, there's a 24-hour grace period before anything gets deleted. You get an email notification immediately, and you can cancel the disable at any time during those 24 hours. After the grace period, the immutable datastore, sync job, restore token, and all associated data are permanently removed.

This prevents accidental (or malicious) disabling. Even if an attacker gains access to your dashboard account, you have 24 hours to notice and cancel.

Building a Complete Protection Stack

If you want maximum resilience, you can layer your protections:

1. Primary datastore - your working backup target with daily prune jobs
2. Immutable backups (€3/TB) - read-only copy that survives deletion and credential compromise
3. Geo-replication (€4/TB/copy) - geographic separation that survives physical disasters

Each layer addresses a different threat. Together, they cover ransomware, human error, and regional disasters, which are pretty much the three scenarios most likely to cause permanent data loss.

Getting Started

Immutable backups are available now. To enable them:

1. Open your datastore in the dashboard
2. Go to Settings > Immutable Backups
3. Choose your sync schedule 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.

If you have questions or want help figuring out the right setup for your use case, reach out to us at support. We're happy to help!