Immutable Backups Are Not Ransomware Recovery

“The backups are immutable, so ransomware cannot hurt us much.”

Let me stop you there, before that goes into an insurance questionnaire.

Immutable backups are not ransomware recovery.

Immutability is a property of a backup object during a retention period.

The object cannot be altered or deleted.

An important property.

Exactly the one that stops a destructive event turning “we have copies” into “we used to have copies.”

But it does not tell you whether the copies contain the required data.

Whether the restore point is clean.

Whether the restore chain finishes in time.

Whether the target environment exists.

Whether your identity plane works.

Whether the business can restart.

It certainly doesn’t un-steal data.

This should not be controversial.

Nobody says “the fire safe is locked, therefore the company has resumed operations.”

Yet attach the word immutable to an object store and suddenly a storage setting is being asked to operate a hospital, a payroll system and an incident command structure.

It can’t.

The durable claim is simple.

A backup is useful only when you can restore the required service and data into a trustworthy operating state.

Ransomware makes that standard less forgiving, because you have to assume your environment around your backup may not be trustworthy when you need it most.

1. “But Attackers Cannot Delete the Backup Vault.”

Good.

That is the point of the vault’s immutable retention.

It means a credential with otherwise destructive authority cannot rewrite history by deleting the retained copy before its lock expires.

In the 3-2-1-1-0 formulation, the extra 1 is an offline or immutable copy.

The final 0 is a target of zero backup errors after verification.

Deliberately different claims.

One is resistance to destruction.

The other is evidence that your backup is usable.

The vault answers a narrow question.

Can this retained backup object be altered or deleted?

It does not answer whether every database, file store, configuration set, secret and application dependency reached it.

It doesn’t answer which point predates the compromise.

It doesn’t answer whether the restore completes.

An immutable copy of an incomplete backup is still incomplete.

An immutable copy taken after the bad state faithfully preserves the bad state.

Storage can be admirably stubborn about retaining the wrong thing.

That isn’t an argument against immutability.

It is an argument against asking one storage-plane control to certify your application, identity, network and business layers above it.

Change Healthcare supplies the timely version.

On 21 February 2024, ransomware took claims-processing and payment systems offline after data had been exfiltrated.

Recovery of core systems took weeks, and disruption extended into April.

A retained backup could address the availability loss.

It could not make the exfiltration disappear.

The criminal pressure was double extortion.

Not merely an inconvenient encryption event.

2. “But We Keep Several Copies.”

Also good.

Keep several copies.

Just know what that sentence means.

The 3-2-1 rule calls for at least three copies of data, on two different types of storage media, with one copy offsite.

The second media type exists because a single failure mode should not take every copy at once.

A ransomware payload reaching network-attached storage and a failed batch of drives are different failure modes.

Pretending every copy shares neither is how a backup diagram becomes decorative art.

3-2-1 is backup architecture.

It is not a declaration that all data sets were selected.

Or that every service dependency was identified.

Or that any particular service can meet its restart target.

The method matters too.

A full backup copies all source data at a point in time, and gives the fastest restore at the highest storage cost.

An incremental backup stores changes since the last backup of any type, and restoration requires the last full backup and every subsequent incremental.

A differential contains changes since the last full backup, so restoration requires at most the full backup and the latest differential.

There is no metaphysical property called “we have backups” making those three restore paths equivalent.

A chain of 30 daily incrementals restores more slowly than one full backup plus one differential, at identical storage cost.

Not a failure of the vault.

That is what your chosen backup method says will happen when somebody needs the bytes back.

Grandfather-father-son rotation adds another dial.

Daily “son” backups cycle out sooner.

Weekly “father” backups live longer.

Monthly “grandfather” backups live longest.

Retention answers how far back a restorable point exists.

It does not answer how quickly it can be recovered.

And it does not answer whether that point is safe to use.

3. “But the RPO Is Low.”

Then your data-loss target is low.

Not the same sentence as “your service recovers quickly.”

RPO is your data loss you can tolerate.

RTO is the time you can tolerate your service being unavailable.

A low RPO can preserve a recent write while an unprovisioned environment, a long incremental chain, an unavailable identity service or a missing secret leaves your application down.

The four-tier example is clear precisely because it doesn’t collapse the two measures.

Tier 0 services, payment gateways, transactional databases.

Target an RTO under 15 minutes and an RPO under 1 minute.

Tier 1 targets 1 to 4 hours and 5 to 15 minutes.

Tier 2 targets 4 to 12 hours and 30 to 60 minutes.

Tier 3 permits 12 to 24 hours of RTO and an RPO of 4 to 24 hours.

Tiered targets.

Not universal truths, and not a compliance bingo card.

Their point is that a payment system and a file archive do not deserve the same recovery architecture merely because both contain data.

Replication sharpens it further.

Synchronous replication waits for the secondary before acknowledging the write.

RPO of zero, and write latency tied to round-trip distance.

Asynchronous replication acknowledges locally and accepts a non-zero RPO for writes in flight.

Aurora global database replication is asynchronous, with typical lag under one second, and AWS says operators should monitor the lag at each secondary, rather than treat the target as a promise that runs itself.

Low RPO is recent data.

It isn’t usable service, safe service, or a tested operating sequence.

A timestamp isn’t a restart plan.

4. “But Production Can Be Rebuilt From Infrastructure as Code.”

Infrastructure as code is useful.

It is also only infrastructure as code.

AWS describes backup-and-restore as the pattern where data is replicated and everything else is redeployed from IaC at failover time.

A legitimate point on the readiness spectrum.

Not warm standby, where a scaled-down but fully functional copy runs continuously.

And not multi-site active/active, where production traffic runs from more than one region.

The distinction has a cost, because readiness has a cost.

Backup-and-restore runs roughly 5% to 10% of production infrastructure cost.

Pilot light 10% to 15%.

Warm standby 40% to 60%.

Multi-site active/active 100% to 200%.

You get to choose your tier.

You do not get to buy the first and claim the fourth during an outage.

IaC can provision resources.

It does not manufacture current application data.

It does not supply production secrets, restore a directory service, reopen a third-party integration, repopulate a certificate chain, or decide which service starts before the one that consumes it.

An IaC repository is not a spare production environment, any more than a building plan is an occupied building.

Which is where data plane and control plane become unpleasantly relevant.

Your data plane serves already-configured traffic.

The control plane reconfigures the environment.

Data-plane operations have materially higher availability design goals, which is why a resilient failover design favours a pre-built switch on a data-plane API over reconfiguring DNS weights live.

If recovery requires a control-plane operation nobody has tested under incident conditions, your immutable vault has preserved the bytes while you discover which permission, API, quota or dependency you forgot to restore.

Not an exotic ransomware problem.

The ordinary meaning of “everything else is redeployed.”

5. “But the Insurance Policy Covers the Rest.”

Insurance can transfer some financial loss.

It cannot restore a service.

It cannot prove a decryptor works.

Or prove stolen data was deleted.

Or decide which applications restart first.

Or supply a clean identity plane, validate a recovered database, or make your control plane available during failover.

A financial and contractual layer.

Not a recovery layer.

The dated evidence is brutally specific.

UnitedHealth paid approximately $22 million in Bitcoin on 1 March 2024 for a decryption key, and a promise that stolen Change Healthcare data would be deleted.

On 3 March, the BlackCat affiliate alleged the operator had taken the money and withheld the affiliate’s share.

On 7 and 8 April, RansomHub demanded payment again, after the affiliate retained your data.

One intrusion.

Two extortion demands.

No second breach.

Which is why “we can pay” is not an availability objective, and “the policy covers it” is not a data-governance answer.

Payment buys a promise from a criminal party.

It does not create evidence that retained copies of exfiltrated data are gone.

Change Healthcare was eventually assessed as affecting an estimated 190 million Americans.

A restored claims platform and a resolved confidentiality incident are related conditions.

They are not interchangeable ones.

There are legal clocks too.

HIPAA’s Breach Notification Rule can require notice no later than 60 calendar days after discovery.

SEC rules require a Form 8-K within four business days of determining an incident is material.

Those requirements do not wait for a vault restore, an insurance carrier, or a negotiation transcript to feel more cooperative.

Immutable backups remain essential here.

They reduce the operational leverage created by destroyed data.

They do not replace incident response, legal decision-making, communications, or the obligations triggered by exfiltration.

6. “But Restoring in a Test Environment Is Not Production.”

Correct.

Which is why a test restore is useful evidence rather than a graduation certificate.

An isolated restore can prove a selected backup set can be read, a particular application version starts, and validation checks pass in a clean environment.

Worth doing.

Also not the same as proving your actual recovery target has the right capacity, access paths, identities, secrets, certificates, integrations, monitoring and business readiness to resume production.

NIST SP 800-34 calls the technical phase reconstitution.

Test and validate that the recovered system functions correctly.

Return operations to normal condition.

Re-prepare the contingency capability for the next event.

Deliberately separate from your incident-response question of return to secure operation, which asks whether the threat has actually been eradicated before normal activity resumes.

Different tests.

A restored service can function beautifully while a compromised administrator account, a poisoned deployment path or an unsafe integration remains.

Conversely, a contained incident does not turn a cold site into a hot one.

NIST’s alternate-site vocabulary is refreshingly literal.

A cold site has space and infrastructure and no system hardware installed.

A warm site has some hardware, software or telecommunications in place.

A hot site is fully sized and configured with supporting infrastructure and personnel ready to run immediately.

A mirrored site adds fully redundant facilities and automated real-time data mirroring.

None of those labels means “your backup object has a retention lock.”

So your recovery exercise has to prove a sequence.

Restore into an isolated clean environment.

Validate data and identity dependencies.

Establish that your incident is eradicated before production return.

Execute the actual restart order.

Test communications with the people who operate and depend on your service.

Production is a system of dependencies.

Not the place where your test environment receives a better name badge.

7. No, This Does Not Mean Immutable Backups Are a Minor Control.

They aren’t.

Immutable backups are central to ransomware recovery, because a payload reaching network-attached storage can take out every copy sharing that failure mode.

A lock preventing deletion during the retention window preserves a recoverable option when the surrounding environment is hostile.

Not minor.

It is the part that keeps the recovery conversation from beginning with “which criminal party should we trust today?”

But a central control can still be a bounded control.

Immutability does not supply coverage.

It does not make one account’s permissions sensible.

It does not choose a retention period outlasting attacker dwell time.

It does not ensure your rotation leaves a clean point available.

It does not restore a long incremental chain at the pace a Tier 0 service needs.

It also does not determine your recovery target.

A cold site, warm site, hot site, pilot light, warm standby and active/active design make different promises about how much has already been prepared.

The immutable backup helps each of them differently.

It does not flatten them into the same architecture because somebody put “Object Lock” in a control statement.

Use your control.

Give it a retention window selected against expected dwell time and storage budget.

Put it in a separately administered boundary.

Protect backup identities with separate MFA and least privilege.

Then test whether the saved object can become the required service.

The lock is not less valuable because it has limits.

The opposite.

Its value becomes operational only when those limits are designed around.

8. What You Should Actually Do

Inventory what recovery actually needs. Applications, databases, object data, configurations, secrets, identities, certificates, network dependencies, integrations, and the people who can authorize and execute the restart.

“The database has a backup policy” is not that inventory.

It is one row in it.

Maintain versioned immutable backups in a separately administered boundary. Apply 3-2-1-1-0.

Select full, incremental and differential schedules against the RTO each criticality tier must meet.

Treat retention, RPO and RTO as three different parameters, because they are.

Protect backup identities with separate MFA and least privilege. Record which credentials, authorization paths and break-glass arrangements the recovery procedure needs.

If an exercise assumes the ordinary identity service is healthy, say so.

If it cannot be assumed, test the alternative.

A recovery process needing the compromised administrative plane to rescue itself has a fairly ambitious faith-based component.

Rehearse isolated restores to a clean environment. Validate not just file readability, but application function, data integrity, identity dependencies, secrets, certificates, integrations, monitoring, and the point at which the restored environment is safe to connect to production paths.

Then rehearse the actual failover and restart sequence for the target tier, including data-plane switching and the control-plane steps it cannot avoid.

Document business restart order and communications. A Tier 0 payment service, a Tier 1 CRM, a Tier 2 reporting dashboard and a Tier 3 archive should not receive the same restoration sequence merely because their backups are all encrypted and locked.

The tier determines the recovery target.

The exercise supplies evidence that the target is real.

9. The Model Is Not Complicated.

Immutability protects a backup object from alteration or deletion.

Backup architecture determines what copies and restore points exist.

Recovery engineering determines whether data, applications, identities, dependencies and people can return a required service.

Incident response determines whether it is safe to return.

An immutable backup is a preserved option. Ransomware recovery is the exercised ability to use that option to restore a trustworthy operating state.

Use immutable backups.

Use offsite copies.

Use 3-2-1-1-0.

Set RPO and RTO by criticality tier.

Choose a recovery-site readiness level honestly.

Separate backup administration from production administration.

Restore in isolation.

Validate your service.

Prove the threat is gone.

Rehearse the business restart.

Those aren’t duplicate controls.

They are the load path from a retained object to an operating organization.