Immutable Backups & Restore Verification Against Ransomware

Immutable Backups and Restore Verification

Backups were designed for hardware failures and accidental deletes. Modern attackers know that, and ransomware operators usually go after backups before they encrypt production: they delete snapshots, disable backup jobs, shorten retention, or wait quietly until the clean copies age out. Careless automation does similar damage — a terraform destroy run against the wrong workspace, a cleanup script with the wrong filter, an administrator account that can delete everything.

Two practices answer this. Immutable backups cannot be modified or deleted until their retention period ends, no matter whose credentials are used, and they live under administration separate from production. Restore verification proves that those copies can actually be restored — complete, consistent, fast enough, and free of whatever compromised the original systems. One without the other is not enough: an immutable backup nobody can restore is just expensive storage.

TL;DR

Keep at least one copy immutable (write once, read many) using object locks, vault locks, or offline media.
Separate backup administration: a different account or tenant, different identities, and no production credential that can delete backups.
Protect the encryption keys; a backup encrypted with a destroyed key is destroyed.
Set retention longer than the time an intruder could stay unnoticed, with several restore points to choose from.
Verify restores regularly: integrity, completeness, consistency, speed, and cleanliness — automatically where possible.
Rehearse clean-room recovery: restore into an isolated environment and check it before reconnecting anything.

Quick Example

An Amazon S3 bucket for database backups with Object Lock in compliance mode: every object written is protected for 35 days, and no user — including the account's root user — can delete it or shorten that period.

Put the bucket in a dedicated backup account, write to it with a role that can add objects but not change the lock configuration, and try deleting a locked object in a test — an access-denied error is the result you want. Because compliance retention cannot be undone, test the configuration on non-production data first: you will store, and pay for, every locked object until it expires.

Core Concepts

Threats to Backups

Immutability Mechanisms

Governance-style modes protect against accidents but not against an attacker holding privileged credentials. Use compliance-style locks for at least one copy of critical data.

Separating Backup Administration

Immutability limits what can be done to existing copies; separation limits who can touch the backup system at all:

Store backup copies in a separate account, subscription, or tenant, with its own identities and multi-factor authentication.
Production roles can write backups but cannot delete them, change retention, or alter policies.
Organization-level policies deny deletion of backup vaults and buckets except through a documented break-glass process.
Changes to backup configuration — retention, locks, vault policies — alert a security channel.

Protecting Keys

Encrypted backups are only as recoverable as their keys. Manage backup encryption keys in the backup account, restrict who can schedule key deletion, and alert immediately on deletion attempts; cloud key services typically impose a waiting period of days before a key is destroyed, which is exactly the window an alert gives you. See Encryption.

Choosing Retention

Retention balances recoverability, cost, and legal obligations:

Several tiers: for example, daily copies for five weeks, weekly copies for three months, and monthly copies for a year.
Longer than detection time: intrusions often go unnoticed for days or weeks, so the newest clean copy may be well before the incident was discovered.
Bounded by data obligations: immutable copies cannot be selectively edited. If a person's data must be erased, it stays in locked backups until they expire. Document the backup retention period, keep it as short as recovery needs allow, and re-apply recorded deletions after any restore — see Data Deletion and Retention Enforcement.

Verifying Restores

Levels of Verification

Automate the Routine Checks

For file and object backups, a tool such as restic can re-read stored data and restore it on a schedule:

For databases, restore drills with integrity checks and measured recovery times are covered in Database Restore Drills and Recovery Targets.

Measure Speed at Real Scale

Small test restores hide the physics of large ones. Restoring 20 TB at a sustained 500 MB/s takes about 11 hours before any verification starts. Restore a production-sized backup at least occasionally, and know which systems must come back first.

Clean-Room Recovery

After a compromise, restoring straight into the old environment can restore the intruder with it. A clean-room recovery:

Builds fresh infrastructure from code in an isolated network or account.
Uses new credentials — assume every old secret is known to the attacker.
Restores data from a point before the compromise, then scans it.
Reconnects to users and other systems only after checks pass.

Coordinate this with the security response — see Security Incident Response.

Best Practices

Alert on Configuration Changes, Not Just Failed Jobs

Failed backup jobs are one signal; changes to retention, lock settings, vault policies, and key deletion schedules are another, and often the first sign of an attack. Route both to people who will act.

Test the Lock Itself

Periodically attempt to delete or overwrite a locked object with an administrative role in a controlled test. Immutability is a claim until a denied deletion proves it.

Keep the Recovery Runbook Reachable

If the wiki, password manager, and identity provider are encrypted or unavailable, can responders still find the runbook and the break-glass credentials? Keep an offline copy and test access to it.

Account for the Cost

Immutable retention means paying for every locked copy until it expires, and compliance locks cannot be shortened to save money. Size retention deliberately and review storage growth.

Common Mistakes

One Set of Credentials for Production and Backups

Governance Mode Mistaken for Immutability

Keys in the Blast Radius

Restoring the Compromise

FAQ

What is an immutable backup?

A backup copy that cannot be changed or deleted until its retention period ends, enforced by the storage system rather than by permissions alone. Object locks, vault locks, locked retention policies, and offline media are common ways to achieve it.

What is the difference between governance and compliance mode?

In governance mode, users with a special permission can still remove or shorten protection, which guards against accidents. In compliance mode, nobody — including administrators — can delete the data or shorten its retention until it expires, which also guards against compromised privileged accounts.

Are cloud snapshots immutable?

Not by default. Anyone with the right permissions can delete them. Copy them into a locked vault or bucket, or use the provider's lock features, to make them immutable.

How long should immutable retention be?

Long enough to cover the time an incident might go unnoticed plus the time to respond, typically several weeks for the immutable tier, with longer-retained copies where recovery needs justify them. Balance this against storage cost and data protection obligations.

How do immutable backups fit with the right to erasure?

Locked copies cannot be edited, so erased data remains in them until they expire. Commonly accepted practice is to keep backup retention as short as recovery needs allow, keep backups out of everyday use, document the retention period, and re-apply recorded deletions whenever a backup is restored. Confirm the approach with your privacy counsel.