The Indestructible Vault: How Veeam, Rubrik, and Cohesity Architect Immutable Backups

Introduction: The Day Your Backups Betrayed You

It is the nightmare scenario every IT leader fears. You get the ransom note. Your primary servers are encrypted. You calmly turn to your backup console, ready to initiate a restore and be the hero.

But the console is empty. Or the backup files are corrupted.

Modern ransomware doesn’t just target production data; sophisticated attackers spend weeks reconnoitering your network specifically to locate, compromise, and delete your backups before triggering the encryption event. If your backups are delete-able, they are not backups; they are just delayed victims.

Enter Immutable Backups.

This is not just a marketing buzzword; it is the fundamental architectural shift required to survive the current threat landscape. In this deep dive, we will move past the sales brochures and examine the “nuts and bolts” of how the three market leaders—Veeam, Rubrik, and Cohesity—actually implement immutability.

We will explore their differing philosophies, their technical execution, and what those differences mean for your infrastructure architecture.

The 101: What is True Immutability?

Before comparing vendors, we must define the standard.

In the context of data protection, immutability means that once data is written to the backup target, it cannot be modified, deleted, or encrypted for a specified retention period.

Crucially, this “cannot” must apply to everyone:

• It cannot be deleted by the backup software itself.
• It cannot be deleted by a compromised Domain Administrator account.
• It cannot be deleted by root access to the storage subsystem.

True immutability creates a “Write-Once-Read-Many” (WORM) state. It transforms your backup repository from a readable/writable storage volume into a sealed digital vault.

1. Veeam: The “DIY Hardened” Approach

Veeam’s philosophy has always been about software-defined flexibility—letting you choose your own hardware. Historically, Veeam relied on storage partners (like HPE StoreOnce or ExaGrid) to provide WORM capabilities via hardware integration.

While those integration still exist, Veeam’s modern answer to native immutability is the Hardened Linux Repository (HLR).

The Mechanism: Hardened Linux Repository & Object Lock

Veeam’s primary on-prem method doesn’t rely on a proprietary file system. Instead, it cleverly leverages standard Linux operating system capabilities.

1. The Setup: You deploy a standard Linux server (Ubuntu/RHEL) with local storage.
2. The “Magic”: Veeam leverages the Linux chattr +i (change attribute immutable) command. When Veeam writes a backup file chain (VBK/VIB files) to this repository, the Veeam transport service on the Linux box immediately sets the immutable flag on those files based on the retention policy you defined in the backup job.
3. The Security: Veeam utilizes single-use credentials to connect to the repository to deploy its services. Once deployed, the repository does not require SSH enabled, and the credentials are not stored. Even if someone gets root access to the Linux box, they cannot delete the files until the immutable flag expires without rebooting into single-user mode (which requires physical console access).

For cloud targets, Veeam heavily utilizes S3 Object Lock API calls to ensure immutability on AWS S3, Azure Blob, and compatible object storage providers.

The Architect’s View:

• Pros: Highly flexible. You can use existing hardware. It’s very cost-effective as it uses standard Linux capabilities rather than requiring a proprietary appliance.
• Cons: It is a “some assembly required” approach. You are responsible for securing the underlying Linux OS, managing updates, and ensuring physical security of the server. The security boundary is the OS kernel.

2. Rubrik: The “Intrinsic” Appliance Approach

Rubrik entered the market with a fundamental goal: to simplify backup by collapsing the traditional multi-tier architecture (backup software server + media server + storage target) into a single, hyperconverged appliance.

Their approach to immutability is radically different from Veeam’s. It is not a feature turned on via a checkbox; it is inherent to how their file system is built.

The Mechanism: The Atlas File System

Rubrik’s immutability is baked into their proprietary distributed file system, called Atlas.

1. No Standard Protocols: Rubrik appliances do not expose their backup storage via standard writable protocols like SMB or NFS. You cannot map a drive to the backup volume from a Windows server.
2. The Append-Only Model: The Atlas file system is fundamentally designed as an append-only system. When data is ingested, it is written, fingerprinted, and locked. The file system itself does not have mechanisms designed to modify existing blocks of data once committed.
3. The Zero Trust Boundary: There is no “root” SSH access available to the end-user (or an attacker) that would allow access to the underlying storage volumes to issue rm commands. The data is only accessible via the Rubrik API authenticated through their RBAC system.

The Architect’s View:

• Pros: Extreme simplicity and very high security by design. It is truly a “black box.” You don’t have to harden an OS; the vendor has done it for you. Immutability is on by default and cannot be turned off.
• Cons: It requires buying into the appliance model (hardware or virtual), which can have a higher initial CAPEX compared to software-only solutions. You are reliant on the vendor’s ecosystem.

3. Cohesity: The “Policy & Governance” Approach

Like Rubrik, Cohesity offers a hyperconverged platform designed to consolidate data silos. Their underlying distributed file system is called SpanFS.

Cohesity’s approach to immutability, branded as DataLock, balances the appliance-like security of Rubrik with rich policy governance features designed to prevent insider threats.

The Mechanism: DataLock and Quorum

Cohesity applies WORM locking at the software layer within SpanFS based on policies.

1. Policy-Based Locking: You apply DataLock policies to Storage Domains (views) or individual Protection Groups. Once data hits that group, the WORM timer starts.
2. Time-Drift Protection: A common attack vector against time-based WORM is to manipulate the server’s NTP (network time protocol) to trick the system into thinking the retention period has passed. Cohesity uses an internal, monotonic clock that is resistant to external NTP manipulation to enforce retention times.
3. The Human Element (Quorum): Cohesity recognized that sometimes the threat is a rogue administrator with valid credentials. They implemented Quorum (Multi-Person Authorization). If someone tries to disable DataLock, change a retention policy, or delete a protected storage view, the system can require approval from two or more designated security officers before the action executes.

The Architect’s View:

• Pros: Excellent balance of integrated platform security and granular control. The Quorum feature is a significant differentiator for large enterprises concerned about insider threats or social engineering attacks on admins.
• Cons: Like Rubrik, it is a platform commitment. While flexible, setting up the governance structures (Quorum) requires careful planning to avoid operational friction.

Summary Comparison: The Architect’s Cheat Sheet

Here is a visual breakdown of the core differences in how these three industry leaders implement immutable backups.

Feature	Veeam	Rubrik	Cohesity
Primary Implementation	Hardened Linux Repository (Software on BYO Hardware)	Atlas File System (Intrinsic to Appliance)	SpanFS DataLock (Policy on Platform)
Immutability Type	OS-Level Attributes (chattr)	Filesystem Design (Append-only)	Software Policy WORM
Hardware Dependency	Low (Any x86 Server)	High (Appliance/Certified Node)	High (Appliance/Certified Node)
Key Strength	Flexibility & Cost to implement	Simplicity & Security by design	Policy Governance & Insider Threat Protection (Quorum)
Ideal For	Teams who want control over hardware and love Linux.	Teams wanting a “set it and forget it” secure black box.	Enterprises needing strict governance and multi-person auth.

Conclusion: It’s Not If, But How

In today’s threat landscape, debating whether you need immutable backups is like debating whether your car needs brakes. It is not an optional feature; it is a mandatory requirement for operational survival.

The choice between Veeam, Rubrik, and Cohesity doesn’t come down to one being “better” at immutability than the others—they all effectively stop ransomware from deleting your data. The choice comes down to your architectural philosophy:

• Do you want the flexibility to build your own hardened bunkers with Veeam?
• Do you want the simplicity of Rubrik’s intrinsic, black-box approach?
• Or do you need the robust governance and quorum controls offered by Cohesity?

The only wrong choice is choosing none of them. Evaluate your team’s skillset, your budget, and your risk tolerance, and lock your data down before the ransom note appears on your screen.

Additional Resources: