Immutable Snapshots vs Immutable Backup: Layer Comparison

Ransomware Defence in 2026: Why Layer Placement Matters

The security debate over immutable snapshots versus immutable backups centres on blast radius and administrative isolation. Modern cyber attacks routinely bypass traditional perimeter defences, actively hunting down secondary storage, management consoles, and scheduled protection routines. Understanding what immutable backups are requires recognising that immutability is not a monolithic feature; it is an enforcement policy applied at a specific layer in the data path.

When an infrastructure architect locks a snapshot at the primary storage array or block tier, the protection policy resides inside the primary environment. When an architect enforces Write Once, Read Many (WORM) storage inside a secondary backup repository, the protection policy lives downstream, decoupled from production file systems and hypervisors. Neither approach is inherently superior across all recovery metrics, but deploying one while misunderstanding its failure boundaries creates critical vulnerabilities.

ServNet UK guidance directly aligns immutable backup strategies with National Cyber Security Centre (NCSC) ransomware guidance, which advises UK organisations that immutable or air-gapped backups form an essential baseline for operational survival. The architectural challenge in 2026 is determining whether array-side locking, backup repository locking, or a coordinated implementation provides the required resilience within a firm's operational expenditure limits.

Immutable Snapshots: Array-Layer Mechanics and Rollback Speed

Primary array snapshots, such as NetApp Snapshot copies, capture point-in-time states directly on the active storage system. These snapshots use pointer-based tracking, allowing administrators to restore multi-terabyte volumes almost instantaneously. When immutability controls are enabled on snapshots—such as Amazon EBS Snapshot Lock—the storage operating system prevents deletion or modification of those snapshots until the configured lock duration or expiry date is reached.

Amazon EBS Snapshot Lock demonstrates the dual-mode enforcement model common to snapshot locking: governance mode and compliance mode. Under governance mode, users with appropriate elevated permissions can adjust snapshot lock settings or delete snapshots in line with organisational policies, subject to IAM controls. In compliance mode, AWS blocks deletion of locked snapshots by any identity, including the AWS account root user, once any configured cooling‑off period has passed and until the lock duration expires.

The clear benefit of storage-layer snapshot immutability is the recovery time objective (RTO). If an active operational volume is hit by script-based file corruption, an administrator can roll back the entire logical unit number (LUN) or volume in seconds. However, snapshot locking remains bound to the primary storage system. If the physical array hardware fails, if the cloud tenant is wiped, or if the underlying storage fabric is compromised, the locked snapshots are lost alongside the active data.

Immutable Backups: Repository WORM and Failure Isolation

Immutable backups solve the blast-radius dilemma by ensuring the protected data payload is copied completely off the production system before immutability is enforced. Dell PowerProtect DD documentation illustrates this repository-tier control through retention lock, which prevents deletion or modification of protected backup sets directly on the secondary backup appliance. Understanding the differences between backup, replication, and snapshots is essential: an immutable snapshot is an anchored point on production storage, whereas an immutable backup is an independent, relocatable data set written to a segregated target.

In cloud and software-defined architectures, repository immutability is predominantly powered by Amazon S3 Object Lock or equivalent S3 API-compatible implementations. Cloudian notes that S3 Object Lock enforces WORM storage on a per-object version basis. This granular enforcement ensures that incoming backup blocks cannot overwrite or delete locked versions; any attempted change merely writes a separate, newer version while the locked original remains untouchable for the configured duration or indefinitely.

Backup orchestration engines leverage this repository‑level isolation to protect application state alongside system configuration. For instance, Veeam uses AWS S3 Object Lock to make backup repositories temporarily immutable and, through its AWS plug‑in, protects EC2, RDS, and VPC configuration data against deletion. This guarantees that infrastructure topology can be reconstituted even if production cloud networks are deleted.

Technical Comparison: Storage Layer vs Repository Immutability

Deciding where immutability should live requires examining how each layer handles data isolation, restore throughput, and configuration dependencies. Snapshot immutability is built for recovery speed within an intact environment, whereas backup immutability is engineered to reconstruct an estate after total environmental loss.

The following matrix outlines the technical separation across both approaches, contrasting their operational characteristics: | Architectural Dimension | Immutable Snapshots (Array-Layer) | Immutable Backups (Repository WORM) | | :--- | :--- | :--- | | **Recovery Time (RTO)** | Sub-minute local rollback via pointer updates | Hours to days (constrained by network throughput) | | **Recovery Point (RPO)** | High frequency (minutes to hourly snapshots) | Periodic scheduled intervals (e.g., hourly to daily) | | **Blast Radius** | Production storage array, SAN fabric, or cloud tenant | Decoupled; isolated from production failures | | **Control-Plane Dependency** | High (tied to array OS or hypervisor/cloud IAM) | Low (segregated backup server or independent WORM target) | | **Cost Tier** | Premium Tier-1 NVMe/block flash storage | Economical secondary object storage / S3 / deduplication appliance | | **Retention Mechanism** | Storage OS lock / EBS Snapshot Lock (compliance mode) | S3 Object Lock (compliance/governance) / DD Retention Lock |

The Control Plane Vulnerability and Lock Configuration

A critical vulnerability in enterprise resilience is the storage control plane. If an attacker acquires administrative credentials to the management console that controls snapshot policies, immutability can be bypassed unless strict architectural boundaries are implemented. Cloud block storage addresses this through non-overridable compliance locking, but software-defined backup solutions introduce other configuration dependencies.

MongoDB Ops Manager documentation highlights the operational nuances of immutable S3 snapshots: Object Lock must be configured during initial S3 bucket creation and cannot be applied retroactively. If an administrator creates a standard bucket and attempts to apply immutable policies later, pre-existing snapshot objects remain unprotected. Furthermore, MongoDB Ops Manager mandates that snapshot data and restore metadata must be stored together inside the immutable S3 bucket rather than relying solely on the Ops Manager application database. This co-location ensures that if the Ops Manager database is encrypted or wiped, the recovery engine can still parse and reconstruct snapshots using the self-contained metadata within the locked repository.

Similar rigor applies in hyperscale public cloud environments. Microsoft Azure exposes immutable blob storage through time‑based retention policies and legal holds. Time‑based retention prevents deletion or modification of protected blob versions for the configured duration, while legal holds separately block changes for as long as the hold remains in place. A legal hold prevents tampering or deletion during audits or active investigations, functioning alongside automated time-based retention to prevent premature purging by administrative accounts.

Cost and Compliance Realities for UK Infrastructure

UK infrastructure budgets face severe scrutiny, requiring IT leaders to evaluate total cost of ownership against recovery requirements. On the UK Government Digital Marketplace (G‑Cloud 14), catalogued Immutable Back‑up & Replication service pricing spans from £0.02 to £27 per gigabyte per month—a 1,350x spread. This vast pricing delta reflects the service tier: the £0.02/GB baseline represents unmanaged, commodity-tier cloud object storage targets where the customer configures and manages WORM policies, whereas the £27/GB premium tier covers fully managed, air-gapped cyber recovery vaults featuring 24/7 ransomware remediation, compliance auditing, and isolated clean-room restoration.

By contrast, secondary commodity cloud storage providers in the UK market demonstrate the lower boundary for raw repository capacity. For example, SSHost UK advertises backup storage at £11 per terabyte per month including VAT, which converts to approximately £0.011 per gigabyte per month—closely validating the £0.02/GB low end of the G-Cloud framework. Organisations must weigh these low-cost repositories against the administrative overhead and software licensing required to bolt on enterprise-grade WORM locking.

Regarding retention windows, ServNet UK recommends that cloud backup immutability typically keep recovery data locked for 60 to 90 days, with around 30 days as a practical minimum baseline. For many UK mid‑market enterprises, locking snapshots on high‑performance primary array flash for 90 days is likely to be significantly more expensive than using lower‑cost immutable backup repositories, given typical tier‑one storage costs. Applying the 3‑2‑1‑1‑0 backup rule, which includes maintaining at least one immutable copy, commonly leads organisations to keep relatively short‑term array snapshots and pair them with longer‑term repository‑level object locks.

The Decision Framework: Choosing the Right Immutability Tier

For UK infrastructure leaders who cannot fund both layers simultaneously, the priority order is clear: deploy repository-level immutable backups first. An immutable backup repository provides existential insurance; it ensures that even if primary SANs, hypervisors, and domain controllers are systematically destroyed, a pristine copy survives off-site to rebuild operations.

Once repository-level WORM is secured, organisations should implement array-level snapshot locking as a secondary phase. This secondary investment targets operational resilience, collapsing restore windows from days to minutes for high-value transactional systems. By decoupling fast local rollback from disaster recovery isolation, IT teams protect production data against zero-day administrative takeover without exceeding capital budgets.

Sources

Every figure in this article traces to the sources below.

• •N2WS — AWS EBS Snapshot Lock modes and root user protection
• •MongoDB — Ops Manager immutable S3 snapshot requirements and metadata co-location
• •Veeam — AWS backup repository S3 Object Lock and VPC configuration protection
• •Cloudian — Enterprise immutable storage architectures and S3 Object Lock WORM models
• •Amazon Web Services — S3 Object Lock compliance and governance mode documentation
• •NetApp — ONTAP Snapshot technology overview and local recovery architecture
• •Dell — PowerProtect DD retention lock documentation and repository immutability
• •Microsoft — Azure Blob Storage immutable controls: time-based retention and legal holds
• •UK Government Digital Marketplace — G-Cloud 14 Immutable Back-up & Replication pricing
• •SSHost UK — Cloud backup repository pricing