Not All immutable storage is created equal; here is an honest opinion on how they compare and where they might be used.

Immutability used to be a word nobody heard of, and most people could not even spell.

But today it is imperative in the fight against cybercrime. According to Veeam’s 2025 Ransomware trends report a staggering 69% of organisations have had an attack in the last year.  their backup repositories were targeted in 89% of those cases.

And only 32% had immutability in place.

Those are some scary numbers when we think back to how we used to build backup solutions only a few short years ago. Immutability is a requirement now, not a nice to have.  However immutable storage is a very broad term, and a lot can fall into that. Leading to organisations thinking they are covered when they are not.

We will talk technology here not brand names. (although you might be able to spot a brand device here and there based on how it works)

Immutable storage comes in a few different guises from vendor created dedicated appliances, Cloud S3 or blob storage to the Linux hardened repositories found in Veeam’s ISO along with bespoke partner MSP, or in house developed and hardened repositories.

They all have a place so long and you understand where they fit into your organisation and how they protect your data.

What does Immutable storage actually mean?

Immutability means that once backup data is written to the storage it cannot be modified, deleted or encrypted until a defined period of time or retention passes.

Not even the root admin should be able to effect change in the data.

Implementation of this immutability can be achieved in a few different ways;

1. XFS immutable tag; used by Linux handed repositories and many vendor appliances. The Linux kernel itself enforces immutability at the filesystem level independent of any application layer that may be compromised.
2. S3 object lock; Common is AWS and on prem object storage appliances. The S3 API call enforces a governance or compliance lock on each object until it is free to be deleted or purged from the system.
3. ISV-Controlled immutability; ISV-DI is used by vendor appliances utilising the Catalyst store model. Dual authentication is required to modify any data.
4. Retention time lock; Used by vendor appliances that protect data by moving it to another internal layer of storage away from a primary landing pad. These time locked and delayed delete objects are then protected from modification.

Each mechanism works, the difference is in how transparent they are to the Veeam console along with how testable they are.

In my opinion I will list these in order of how I would rate them for a standard company ranging in data footprint from 100TB to 800TB. This would cover the vast majority of companies. Especially in Ireland where medium size business is predominant.

However, this order can be changed around based on requirements.

For example, if you had a requirement in the Petabytes, then object based S3 clusters currently rule the roost. But come at a cost, both financially and in terms of complexity.

For the majority of companies, the gold standard currently is a Linux hardened repository.

What is a Linux Hardened Repository?

A Veeam Linux Hardened Repository is a Linux server — mostly physical but on occasion can be virtual, deployed on hardware of your choice — configured specifically to act as an immutable Veeam backup target. Veeam provides a Hardened Linux ISO (based on Rocky Linux) that deploys a pre-hardened operating environment. From v13, the Veeam Software Appliance builds on this same foundation. One can also create a custom Linux repository if they have the skill set or a good partner to provide the appliance and support skills.

In either case the XFS filesystem’s built-in immutability flag (chattr +i) is used to lock backup files at the Linux kernel level. This is not a software-layer lock — it is enforced by the Linux kernel itself, independently of Veeam, independently of any user credentials, and independently of any API.

• Single use credentials or certificate based connection facilitated the repository connection to Veeam this is a onetime thing, credentials or the cert are not stored in a reusable for anywhere so an attacker cannot exploit them by replaying them.
• Veeam only connects to the repository during active sessions. There is no standing management connection that an attacker could leverage.
• No root access to the repository via Veeam. As Veeam does not have any root admin privileges or admin account Veeam cannot be leveraged to delete or modify data. Veeam connects as a least privilege backup user using a helper with restricted sudo permission only for the specific operations required to backup data and prune retention once the immutable tag has expired.
• SSH is disabled once deployment is complete. Remote management is only possible via out of band channels. iLO, iDRAC etc.

Why a custom or bespoke Linux repository?

               The most important advantage of the bespoke Linux Hardened Repository over every proprietary appliance is that it is a standard Linux server. You have complete control. You can install your required packages. You can configure and integrate with your tools or your service providers tools for full visibility.

 This is where the monitoring and telemetry argument becomes decisive.

Full OS and hardware telemetry to send usage and warnings to your service provider or helpdesk. And one can send Linux kernel filesystem info directly to your SEIM.

Unlike proprietary appliances where alerting is limited to what the vendor exposes through their management interface, a bespoke repository lets you build exactly the alerting logic your organisation needs, for example:

• Alert if the immutability flag is removed from any backup file outside of an authorised retention expiry window.
• Alert if any process other than the Veeam backup user writes to the backup volume.
• Alert if disk health degrades below a defined threshold before it causes a backup failure.
• Alert if backup job throughput drops below baseline — which can indicate a performance problem or network anomaly.
• Alert if SSH is re-enabled on the server when it should be disabled.
• Alert if any new user account is created on the system.

Hardware independence.

This is key, the ability to use any commodity hardware to fulfil your needs provides freedom to develop a solution that fits you. deploying a Veeam Hardened Repository on existing or new commodity hardware is significantly more cost-effective than purchasing a proprietary appliance at equivalent capacity. Vendor appliances can and do offer a lot of the benefits already mentioned but at a significantly higher cost.

Service provider support.

A lot of service providers can source and configure a Linux repository for you. They can also then provide the Linux support, which is where the majority of organizations slide into a vendor appliance. Because they have no in house Linux skills or their current provider cannot handle Linux either. 

So, find a Backup service provider that can source and deploy/configure/support a hardened Linux repository with telemetry and out of band management.  This is the best of all worlds.  Secure/Cost effective/supported.

What is On-Prem Object storage?

On Prem object storage solutions are usually based on the S3 filesystem and use Object lock to make each object immutable for a period of time. Then Veeam periodically checks this lock and moves it forward if the data is set to be retained for a further period of time.

Veeam connects to this storage via access and security keys that allow varying level of permissions. but none of them allow for deletion or changing of immutability. So does provide absolute immutability.

These storage solutions tend to work on the larger clustered side of the requirements so are more suited to very large companies or service providers. However, Veeam have recently purchased object first founded by the original Veeam founders — Ratmir Timashev and Andrei Baronov. This provides smaller dedicated Veeam only repository appliances prebuilt. At a cost of course.

Object storage generally would have constraints on minimum size and can only normally be expanded in predefined chunks of storage. If it does not have a high minimum, it is therefore not clustered so offers limited redundancy. Object storage generally runs only on Vendor provided hardware. Although some do offer virtual appliance that can use VMware storage. These are limited though.

Offerings from Vendors in the all-flash space are very performant and surprisingly cost effective at scale. One does need the scale though for this to be a viable choice. But for those in the petabyte world they are a definite recommendation.

Object storage monitoring is generally done though the Vendor dashboard or web-based management portal and while some might offer log export very few support integrations with arbitrary SEIM platforms. Organisation with deep level telemetry requirements will need to add a layer of tooling.

What are duplication hardware appliances?

The large Storage and server vendors all have a deduplication appliance that can now also do immutability. Think Data Domain, StoreOnce etc.

While these appliances have great deduplication, the data has to be ingested into the appliance in a non-Veeam compressed type of way, so that one is effectively inflating the normal Veeam backup footprint data to deduplicate it and shrink it again. Block cloning on XFs provides large native space savings that makes the cost of dedicated deduplication appliances very hard to look at today.  The primary reasons not to use these would be the issue of being locked into a specific Vendor and high cost. 

There is no independence of hardware here. And expanding these devices is the worst of the forklift upgrades you will see. With complete lift and replace with data migration.

Immutability is often via a dual admin setup that can be used to delete data if both accounts are known. They are often over sized to allow for poor performance because it is based on slow spinning disk on a Vendors own OS.

The Verdict:  What is best for me?

Well in typical “only you can answer that” fashion.

The answer is, it’s down to your requirements. 

But I would say start with a bespoke Hardened Linux repository and see if that fits your requirements. and if you have a partner or in house skills to manage and support the Linux OS.  If you can and it works for your scale, Stop there you have hit the jackpot.

If not move down the list to a Veeam ISO Linux repo or Object storage if your scale suits.

And only get to Vendor locked deduplication devices if you are practically getting them for free as part of a larger deployment of if you have a unique use case that deduplication wins out on cost.

But remember what ever you choose you will need to produce any compliance report your auditors require and:

Immutability keeps attackers out. Monitoring and telemetry tell you when they tried to get in.