An immutable backup is a copy of data that cannot be changed or deleted for a set period — not by an administrator, not by an attacker who has stolen administrator credentials, not by the backup software itself. The retention period is fixed when the backup is written. Until it expires, the data can be read and restored, but it cannot be altered or erased by anyone.
That one property — a backup even the boss cannot delete — has moved from a specialist feature to the expected design of a serious backup strategy. This page explains the mechanism behind that shift, without the fear pitch. The reasoning is mechanical, and it holds up on its own.
Why Did Ordinary Backups Stop Being Enough?
Ordinary backups stopped being sufficient when attackers began treating the backups as a primary target rather than an obstacle. Modern ransomware operations routinely find and delete or encrypt an organization’s backups before detonating on the live systems, specifically so the victim cannot restore and must consider paying. A backup that the production environment can reach and modify is, to an attacker with stolen credentials, simply more data to destroy.
Walk through the mechanism, because the mechanism is the whole argument:
Step one: the attacker gets credentials. Phishing, a reused password, an exposed remote-access service — the entry varies. What matters is that the attacker ends up operating with legitimate-looking access, often administrator-level, and often for days or weeks before doing anything loud.
Step two: the backups are neutralized. With administrator access, the attacker browses the backup console the same way an employee would. Retention gets shortened. Backup jobs get deleted. Snapshots get wiped. Nothing about this requires sophisticated tooling — it uses the same controls your own team uses, which is exactly why it works.
Step three: detonation. Only once recovery options are gone does the encryption of live systems begin. The victim discovers the intrusion and the absence of backups at the same moment, which is the attacker’s entire business model: remove the alternative to paying.
Every step after the first one depends on the backups being changeable by whoever holds the keys. Immutability breaks the chain at step two. The attacker can hold every credential the organization owns and still cannot delete or alter backup data that was written under a retention lock. The copies sit there, aging out on their original schedule, available for restore.
How Does Immutable Backup Work?
Immutable backup works by enforcing a retention lock at the storage layer: when backup data is written, it is stamped with a retention period, and the storage system refuses modification or deletion until that period expires — regardless of who asks or what credentials they present. Implementations include object-lock features in cloud and object storage, write-once media, and logically or physically air-gapped copies that the production network cannot reach at all.
Three design points do the real work:
The lock lives below the credentials. Because enforcement sits in the storage layer rather than in user permissions, there is no account to compromise that unlocks early deletion. This is the difference between a policy (“admins shouldn’t delete backups”) and a mechanism (“backups cannot be deleted”). Policies bend under attack. Mechanisms do not.
Retention is set to the threat, not the storage bill. Attackers often sit inside a network for an extended period before detonating. Retention must therefore span longer than a plausible dwell time, so that clean copies written before the intrusion still exist after it. Short retention quietly re-opens the hole immutability was meant to close: if every copy was written after the attacker got in, every copy can carry the problem.
Immutability is one layer, not the strategy. The long-standing pattern in backup design — multiple copies, on different media, with at least one copy off-site or offline — still applies. Immutability strengthens the copies you keep; it does not replace geographic separation, and it does not help if the data was already corrupted before it was backed up. Tested restores remain the proof that any of it works. An immutable backup that has never been restored is a promise, not a capability.
What Should a Backup Strategy Actually Specify?
A backup strategy should specify what gets backed up, how often, how long copies are retained, where they live, which copies are immutable or offline, and — most neglected — how restores are performed and tested. The strategy is the document that turns backup from a software purchase into an operational commitment, and it should be written against recovery targets: how much data the business can afford to lose, and how long it can afford to be down.
Operators who have lived through a real restore tend to write this document differently than those who have not. It names an owner. It states the retention lock periods in days, not adjectives. It schedules restore tests and records their results. And it treats the restore — not the backup job’s green checkmark — as the thing being bought. Backup success is a report. Recovery is an event you either survive or do not. Immutability became the default because it protects the copies themselves from the one adversary every other control assumes away: someone holding your own keys.