What is an immutable backup

What is immutable backup?

Immutable means incapable of change. Immutable backups ensure that data is locked in its original state: it cannot be encrypted by ransomware, deleted by a malicious insider, or accidentally overwritten by an administrator error.

The key part of any immutable backup definition is who enforces the lock. With a standard data backup, anyone with the right permissions can change or delete the copy. With an immutable backup, the storage system itself blocks those changes. Having an immutable copy of your data is critical to ensuring a recovery point is always available — whether th

Why are immutable backups important?

Cybersecurity Ventures predicts that by 2031, ransomware will attack a business, consumer, or device every 2 seconds. The costs of a ransomware attack are enormous, whether you pay the ransom or not. Ransomware recovery can take months, revenue is lost, and reputational damage lingers long after systems are restored.

What makes the modern threat landscape uniquely dangerous is that cybercriminals no longer just encrypt production data. They specifically target backup infrastructure first — deleting or encrypting backup snapshots to eliminate the organization's ability to recover without paying.

Immutable backup systems are architected to remove this leverage entirely. Because the backup data cannot be altered, ransomware actors gain nothing by targeting it. The clean recovery point remains unchanged and available

How does immutable backup work?

Immutable backup systems enforce data integrity through a combination of storage policies, access controls, and architectural design:

• Storage-level enforcement: The lock is enforced by the storage layer itself, separate from the user permissions an attacker could change with stolen credentials.
• Write-Once, Read-Many (WORM) storage: Once data is written, the storage layer prevents any modification or deletion until the retention period expires. Each locked copy carries a retain-until date, and the storage rejects any delete request made before that date.
• Read-only snapshot locking: Backup snapshots become immutable snapshots the moment they’re written. Any incremental updates write to a zero-cost clone, not to the original snapshot.
• Trusted API access only: Writes to internal backup views are permitted only via authenticated, trusted internal services — external applications and users cannot modify backup data.
• Encryption at rest and in transit: Data is encrypted independently of immutability, ensuring confidentiality alongside integrity.
• Air-gap and cyber vault options: For maximum protection, immutable backups can be isolated in an air-gapped vault, physically or logically separated from the main network.

Types of immutable backup storage

Immutable backup storage falls into five main types, based on where the lock is enforced. That location determines who, if anyone, can release a lock before its retention period ends.

Amazon S3 Object Lock lets teams choose how strict each lock is. In governance mode, users granted a bypass permission can shorten or remove a lock. In compliance mode, no user can delete the data or shorten the lock before the retention period ends, including the account’s root user. Since attackers often work from stolen admin credentials, compliance mode is the safer setting for the restore points a business would need after a ransomware attack.

Benefits of immutable backups

An immutable backup protects data from far more than ransomware. Because the locked copy can’t be changed during its retention period, it also covers everyday mistakes and insider misuse.

Data is essential to your business. Imagine a healthcare provider suddenly losing access to all its patient files due to a ransomware attack. A university as the victim of targeted attacks that take away its ability to process student financial aid data.

Attacks like these happen every day. Having an immutable backup and recovery system ensures that there is an untouched—and untouchable—version of that data always recoverable and safe from any kind of disaster.

• Protection from accidental deletion: A storage admin decommissions the wrong volume, or a sync job copies a deletion across shared folders. Human error like this never reaches the locked copy, so the lost data is one restore away.
• Defense against insider threats: With compliance-level locking or quorum approval in place, the retention policy sits outside any one person’s control. A disgruntled admin or an attacker using a stolen login has no way to shorten the lock or purge the copy.
• Audit-ready records: Auditors look for evidence that records haven’t been edited after the fact. Locked copies hold historical data in its original form for the full retention period, and the regulatory compliance section below covers the specific requirements.
• Business continuity after any disaster: A flooded data center or a failed storage array can take production offline without warning. Stored apart from production, the locked copy gives teams an unaltered restore point to recover from and anchors the organization’s data resilience plan.

Mutable vs. immutable backup: key differences

The key difference between mutable and immutable backup is whether data can be tampered with after it is written:

Mutable backups can be encrypted, altered, or deleted — which is exactly what ransomware does. Immutable backups eliminate that attack surface entirely.

Can ransomware infect or delete backups?

Yes — ransomware can and does target traditional (mutable) backups. Modern attacks routinely delete or encrypt backup repositories before triggering the main payload. Immutable backups are specifically architected to prevent this.

In the past, a backup and recovery solution was sufficient insurance against cyberattacks. Recognizing that organizations with backups would simply refuse to pay ransoms, attackers evolved their tactics to target backup data and administrator functions first.

In numerous documented incidents, attackers deleted or encrypted backup repositories and snapshots before activating the primary ransomware payload — leaving organizations with no recovery option other than paying.

An immutable backup eliminates this scenario. Because the backup cannot be modified, encrypted, or deleted, even by a compromised administrator account, the attacker’s primary goal of cutting off recovery fails. The organization keeps an unaltered recovery point to start ransomware data recovery from, with no ransom required.

Why immutable backup is the last line of defense against ransomware

When a ransomware attack is detected, the organization's immediate priority is restoring operations from a known-good state. Immutable backups make this possible because:

• The backup data is unaltered, exactly as it was written.
• Recovery time is predictable; there is no need to check whether attackers tampered with the backups themselves.
• Ransom payment becomes unnecessary — with an intact immutable backup, organizations can recover without engaging attackers.

By deploying an immutable backup solution, your organization retains an unaltered copy of data that can restore business operations and removes the leverage ransomware attackers rely on. Even after ransomware reaches production, teams can bring systems back to their last healthy state, minimizing downtime and returning to normal operations sooner.

What to look for in an immutable backup solution

When evaluating immutable backup providers, prioritize solutions that offer these key features:

1. WORM-based architecture

A WORM backup should get its write-once, read-many protection from the storage infrastructure itself. That keeps the copy secure even if an attacker takes over an admin account and starts changing policy settings.

2. Read-only snapshot locking

Backup snapshots should be immediately locked in a read-only state upon completion. Incremental backups should write to zero-cost clones, leaving the original snapshot untouched.

3. Authenticated API-only access

Any writes to backup views should be restricted to trusted internal services operating via authenticated APIs. No external application or user should have write access to backup data.

4. Encryption at rest and in transit

Data encryption should be applied independently of immutability to ensure confidentiality. Look for AES-256 encryption and TLS in transit as baseline requirements.

5. Role-based access controls (RBAC)

Granular RBAC ensures that no single user — including administrators — can unilaterally modify or delete backup data. Multi-person authorization (quorum-based approval) adds an additional layer.

6. Air-gap and cyber vault capabilities

For critical workloads, the ability to store immutable backups in a logically or physically isolated environment (cyber vault) provides defense-in-depth against even the most sophisticated attacks.

7. Compliance and regulatory alignment

Immutable backup supports compliance with regulations that require WORM storage or data integrity guarantees, including SEC Rule 17a-4, HIPAA, FINRA, and GDPR. Verify that the solution supports your specific compliance obligations.

Immutable backup best practices

The strength of an immutable backup depends on how well the backup environment around it is secured. These practices apply data security best practices to that environment.

• Follow the 3-2-1-1-0 rule: Keep three copies of the data on two different media types, with one stored off site and one immutable or air-gapped. The final zero stands for zero errors, confirmed through regular recovery tests.
• Match retention to attacker dwell time: Attackers can sit inside a network for days or weeks before they launch ransomware. Set the retention window long enough to reach back to a point before the intrusion likely began.
• Isolate backup admin accounts: Give backup administration its own accounts, separate from everyday admin credentials, and protect them with multi-factor authentication. Require quorum approval before anyone deletes data or changes a retention policy.
• Test restores on a schedule: A lock keeps a copy unchanged. A scheduled test restore confirms that copy can bring systems back and gives teams a realistic read on recovery speed.
• Scan before you restore: Immutability preserves everything written to the copy, including dormant malware. Running ransomware detection on the recovery point before it returns to production keeps teams from reinfecting their own systems.

Immutable backup and regulatory compliance

Many regulatory frameworks explicitly require organizations to maintain data in a tamper-proof, write-once format. Immutable backup satisfies these requirements:

• SEC Rule 17a-4 (financial services): Since the SEC’s 2022 amendments, broker-dealers can preserve electronic records in a WORM format or through an audit-trail system that can recreate any altered or deleted record. Immutable, WORM-based backup meets the first option directly.
• HIPAA (healthcare): Requires integrity controls that prevent unauthorized alteration of protected health information (PHI). Immutable backups provide a verifiable audit trail that PHI has not been modified.
• FINRA: Rule 4511 holds member firms to the same record format rules as SEC Rule 17a-4, so immutable backup supports FINRA compliance through the WORM option.
• GDPR: While GDPR focuses on deletion rights, organizations must also demonstrate data integrity. Immutable backups support audit and integrity obligations.
• DORA (EU Digital Operational Resilience Act): Mandates robust backup and recovery capabilities for financial entities. Immutable backup is a key component of DORA-compliant resilience strategies.

Organizations subject to these or similar regulations should confirm that their backup provider can produce documentation and audit logs demonstrating the immutability of stored data

Cohesity and immutable backup

Cohesity's AI-powered data security and management platform, which powers its cyber resilience solutions, is built with immutability as a foundational design principle, not an add-on feature. Key capabilities include:

• Immutable backup snapshots: All backup snapshots are stored in a read-only state. Any incremental backup writes to a zero-cost clone, ensuring the original snapshot is never modified.
• WORM retention with DataLock: Cluster administrators can’t modify or delete a snapshot locked with DataLock until its retention period ends. Only users with the Data Security role can add, modify, or remove a lock.
• An immutable file system: SpanFS stores backup data in internal Views that nothing outside the cluster can access. The file system writes new data to empty space, so existing backups stay intact.
• AES-256 encryption at rest and TLS in transit: Data is protected both against unauthorized access and unauthorized modification.
• Role-based access control (RBAC): Granular access policies prevent any single user from modifying backup configurations or data.
• Cyber vaulting with FortKnox: Cohesity FortKnox provides an isolated, cloud-based cyber vault with immutable backup copies, adding air-gap protection for critical workloads.
• Multi-factor authentication and quorum approval: Sensitive operations require multi-person authorization, protecting against compromised credentials.

Experience Cohesity’s immutable backup and recovery free for 30 days.

Frequently asked questions about immutable backup

Is immutable backup the same as air-gap backup?

No, immutable backup and air-gap backup are different safeguards, and they work best together. An air-gap backup sits offline or on an isolated network where attackers can’t reach it, while an immutable backup stays unchanged even when they can. Pairing immutable storage, air-gapped backup copies, and a cyber vault gives organizations the most complete protection.

How long should immutable backups be retained?

Immutable backups are typically retained for 30 to 90 days for operational recovery and one to seven years for compliance. The shorter window covers everyday restores and attacker dwell time, while the longer one follows industry record-keeping rules. Legal, compliance, and IT teams should set the policy together, since many locks can’t be shortened once applied.

Can an administrator delete an immutable backup?

No, an administrator can’t delete an immutable backup before its retention period ends, as long as the storage layer enforces the lock. Quorum approval adds a second safeguard by requiring several people to sign off on sensitive changes. That keeps a single compromised or rogue account from acting alone.

How can you verify an immutable backup can't be deleted?

You can verify that an immutable backup can’t be deleted by checking where the lock lives and then testing it. The lock should be enforced by the storage itself, carry a retention date, and hold when an admin-level account attempts a delete. Running that delete attempt against a non-production copy is the simplest way to catch a lock that’s configured incorrectly.

What is the difference between immutable backup and immutable storage?

Immutable storage refers to the underlying storage technology (e.g., object storage with WORM policies). Immutable backup refers to the broader backup solution that uses immutable storage — along with access controls, encryption, and recovery orchestration — to protect backup data end-to-end.

Does immutable backup work in the cloud?

Yes. Cloud providers including AWS, Azure, and Google Cloud offer object storage services with WORM (write-once, read-many) policies. Cloud-native immutable backup solutions leverage these capabilities to protect backup data stored off-premises, often as part of a 3-2-1 or 3-2-1-1-0 backup strategy.

What are the limitations of immutable backups?

The main limitations of immutable backups are two planning considerations: storage capacity and scanning before restores. Locked copies stay in place until their retention period ends, so capacity plans should account for that growth. A lock also preserves anything written before it, including dormant malware, so scanning each recovery copy before a restore keeps reinfection out of production.