Commvault AirGap immutability raises the bar for backup resilience

At a glance

What this is: This is a vendor-authored argument that AirGap backups are immutable and WORM-capable, with the central finding that resilience should be measured by tested recovery and full lifecycle cost, not storage price alone.

Why it matters: For IAM and security teams, immutable backup controls only matter if they survive attack conditions, fit regulatory requirements, and avoid hidden operational dependencies that weaken recovery assurance.

Context

Commvault frames the problem as a resilience gap, not a storage feature gap. The article argues that immutable backups and WORM lock are already present in AirGap, but that the real issue is whether organisations have actually validated recovery behaviour under hostile conditions.

For identity and security practitioners, the governance question is whether backup protection is operationally real when ransomware, insider tampering, or misconfiguration are in play. The article also pushes buyers to think beyond capacity pricing and evaluate compute, infrastructure, and operating overhead as part of backup resilience.

The article is written as a rebuttal to competitor claims, but its broader message is vendor-neutral: resilience claims should be proved in testing, not assumed from a feature checklist.

Key questions

Q: How should teams validate immutable backups in practice?

A: Teams should test restore behaviour in realistic failure scenarios, not just confirm that immutability settings exist. The key question is whether protected data can still be recovered when an attack, misconfiguration, or operational failure removes normal recovery paths. If the restore fails, the control has not delivered resilience.

Q: Why do WORM-enabled backups still create cost pressure?

A: WORM preserves data by preventing modification, which reduces the system’s ability to optimise or reorganise storage over time. That creates overhead in capacity management, compute, and operations. Practitioners should compare full lifecycle cost, not storage price alone, when assessing long-term resilience economics.

Q: What breaks when backup resilience is judged only by vendor claims?

A: The control can look complete on paper while real recovery remains unproven. Without environment-specific testing, teams may discover too late that retention settings, restore orchestration, or infrastructure dependencies prevent a clean recovery after an incident.

Q: When should organisations prioritise recovery testing over feature comparisons?

A: They should prioritise testing whenever backup protection is tied to business continuity, regulatory retention, or ransomware recovery. A feature comparison tells you what the platform says it can do. Testing tells you whether the organisation can actually restore what it needs, when it needs it.

Technical breakdown

How immutable backup storage works with WORM lock

Immutable backup storage prevents written data from being modified or deleted for a defined protection period. WORM, or write once, read many, adds storage-level retention rules that stop post-write changes even when administrative access exists. In the cloud, that usually maps to object-lock or immutability-policy features on the underlying storage target. The practical distinction is between data that can be rewritten by a backup system and data that is retained at the storage layer after write completion. In resilience terms, immutability is only meaningful if the protected copy remains recoverable under the same conditions that would destroy ordinary backups.

Practical implication: Validate that your backup tier enforces immutability at the storage layer, not just in the application workflow.

Why backup TCO is more than storage capacity

The article’s cost argument is that WORM-enabled storage introduces overhead across the industry because protected objects cannot be rewritten, compacted, or reorganised as freely as mutable data. That means capacity is only one part of the cost equation. Infrastructure, compute, orchestration, and operational effort all influence the real total cost of ownership. Cloud-native architectures may reduce persistent appliance dependence, but the buyer still has to account for how retention, retrieval, and recovery behave at scale. For practitioners, this is less a procurement debate than an operating-model question: the cheapest storage tier can still be the most expensive recovery path.

Practical implication: Evaluate backup platforms on full recovery economics, not just per-terabyte storage pricing.

Why real-world recovery testing matters more than feature claims

A backup control is only proven when a restore succeeds after the conditions it was meant to survive. Simulated cyberattack scenarios, recovery exercises, and restore tests reveal whether immutability, WORM lock, and deployment design actually hold under pressure. This is especially important where vendor claims describe resilience but do not show how recovery behaves when primary systems, orchestration layers, or retention settings are stressed. The article’s central governance point is that a resilience program needs evidence, not marketing language. In practice, backup assurance should be treated as an exercised control, not a declared capability.

Practical implication: Run restore tests against your own data and environment to verify that protected backups are recoverable when it counts.

NHI Mgmt Group analysis

Immutable backups only reduce risk if recovery is provable, not assumed. The article correctly shifts attention away from whether a feature exists and toward whether it survives real attack conditions. That is the governance distinction practitioners often miss: resilience is not a declaration, it is an exercised property. Teams should treat backup immutability as a control that must be demonstrated, not merely purchased.

Full backup TCO includes operational drag, not just storage spend. WORM protection changes how data is retained, managed, and restored, so cost discussions that stop at storage capacity are incomplete. The article’s strongest point is that appliance overhead, compute dependency, and administrative complexity all shape the actual resilience outcome. Procurement and architecture reviews should therefore compare long-term recovery economics, not headline storage rates.

Protection features move from theory to evidence when they are tied to restore testing. The article’s Get Real Challenge concept reflects a broader market truth: resilience claims are weak unless they are tested against the organisation’s own data, environment, and failure scenarios. That is particularly relevant for backup governance, where assurance often lags behind configuration. Practitioners should build validation into the control itself, because a backup that cannot be restored is only an archive.

Backup resilience is becoming a governance discipline, not a tooling feature. As data protection grows more intertwined with compliance, operational continuity, and incident response, teams need to assess who owns recovery evidence and what conditions count as proof. The implication is straightforward: resilience must be measured, reviewed, and re-tested as part of identity and infrastructure governance, not left to vendor assurances alone.

What this signals

Immutable backup governance is moving from feature selection to evidence collection. Backup teams should assume that retention controls, recovery orchestration, and operational dependencies are part of the control surface, not separate concerns. The practical shift is toward proving that protected copies can still be restored under failure conditions.

WORM protection changes the economics of resilience planning. Once data is write-protected, the costs that matter most are often outside the storage bill, including compute, administration, and dependency management. Practitioners need to assess whether their backup design creates durable recovery or merely durable expense.

For practitioners

• Test restore under hostile conditions Run recovery exercises against your own data set while assuming the primary environment is unavailable and the backup path is the only recovery option.
• Map retention controls to compliance requirements Confirm that WORM lock, immutability policy settings, and retention periods match your regulatory and audit obligations before relying on the backup tier.
• Review backup TCO beyond storage Include compute, orchestration, infrastructure dependencies, and operational effort in the evaluation so the cheapest storage tier does not mask higher recovery cost.
• Separate feature claims from recovery evidence Require proof that immutability survives real restore workflows, including recovery from the storage target you actually use in production.

Key takeaways

• Immutable backup features only matter if the organisation can restore data under hostile conditions.
• The article argues that cost comparisons limited to storage capacity miss the real ownership burden of WORM-protected backups.
• For practitioners, the decisive control is not the claim of immutability but the ability to prove recovery in testing.

Key terms

• Immutable Backup: An immutable backup is a copy that cannot be altered or deleted during its retention period. It protects recovery points from ransomware and accidental deletion, but it only delivers value when the organisation can restore from it successfully during an incident.
• WORM Lock: Write-once, read-many protection that prevents stored data from being overwritten during the retention window. For backup programmes, it is a storage-layer control that strengthens resilience, but it also changes cost, administration, and recovery design assumptions.
• Backup TCO: Backup total cost of ownership includes storage, compute, orchestration, administration, and infrastructure dependencies, not just terabytes consumed. The practical test is whether the design delivers durable recovery at a cost the organisation can sustain over time.
• Recovery Validation: Recovery validation is the process of proving that restored identity services are clean, trusted, and safe to use. In hybrid estates, this goes beyond bringing directories back online because compromised trust paths, credentials, or synchronization links can survive a superficial restore. It is a resilience control, not just a backup task.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.