If you are specifying backup storage and the requirement says “immutable”, this is what that word actually buys and where it stops. Immutable storage will not let data be changed or deleted for a defined period, no matter who asks. Its value for backup is narrow and specific: it takes the administrator, and anyone holding stolen administrator credentials, off the list of people who can destroy a recovery point.
Immutability and WORM are not the same thing
The two terms get used interchangeably and they are related, but they come from different places.
WORM, write once read many, is the older concept and it started in hardware. Optical media and specialised tape were physically incapable of being rewritten. The guarantee came from the medium itself, which is about as strong as a guarantee gets, and about as inflexible.
Immutability as it is used now is a software control applied to storage that is perfectly capable of being rewritten. A policy, not a physical property. That makes it far more practical, because you can apply it selectively and let it expire, and slightly weaker in principle, because a policy is enforced by software that has to be correct.
| WORM | Immutability | |
|---|---|---|
| Enforced by | The medium itself | Storage software policy |
| Applied | To the whole medium | Per snapshot or volume |
| Expires | Never | On a retention period you set |
| Changed after the fact | Impossible | Possible, under controls |
For backup work the distinction that matters is the third row: immutability is configured per snapshot with a retention period attached, which is what makes it usable day to day. We went deeper on the comparison in WORM vs. immutability.
How deletion locks work in practice
The mechanism in Catalogic vStor is a deletion lock applied to a snapshot or a volume. The lock holds until it expires, and there are two kinds:
- A fixed lock cannot be removed by an administrator at all. It releases when its retention period ends and not before.
- A flexible lock can be removed, which suits data whose retention requirements change.
Removing either kind requires multi-factor authentication through a one-time password. That detail is doing more work than it looks: the common ransomware pattern is not breaking encryption, it is acquiring credentials and then using the backup console the way an administrator would. An MFA requirement on lock removal breaks that path.
Locks can also be applied automatically to replicated data as it arrives on the target, which matters for the reason below.
What immutability protects against
Ransomware that hunts backups first. Attackers understand that a working backup turns a ransom demand into an inconvenience. Modern ransomware spends time looking for backup infrastructure and deleting or encrypting what it finds before it touches production. A recovery point that cannot be deleted is the difference between an incident and a catastrophe.
Administrator error. Less dramatic and considerably more common. Somebody prunes the wrong retention policy or deletes the wrong volume. A lock catches this the same way it catches an attacker.
A second copy that turns out to be as deletable as the first. Replication moves recovery points somewhere else, which is valuable, but replication on its own is not protection. If whatever reached the source can reach the target, or if replicated snapshots can be removed easily, the second copy provides less assurance than the architecture diagram suggests. Protection has to be applied on the target, not just assumed from the distance.
What it does not protect against
Immutability preserves a recovery point. It says nothing about whether that recovery point is any good.
If ransomware sat dormant in an environment for six weeks before triggering, the backups from those six weeks are immutable and infected in equal measure. You have preserved the problem. This is why immutability belongs next to detection and verification rather than instead of them: GuardMode scanning for suspicious activity and encrypted files, and backup verification confirming a recovery point is actually readable, are what tell you which of your protected snapshots is worth restoring.
Nor does it help if nobody can find the right recovery point under pressure, or if the restore takes four days when the business allows four hours. Protected but unusable is its own failure mode.
The questions auditors and insurers now ask
Cyber insurers and auditors have become noticeably more specific about backup resilience, and “our backups are secure” no longer clears the bar. The questions that come up are concrete: how are recovery points protected, what controls retention, does deletion require stronger authentication than a password, and can recovery be completed inside the tolerance the business has stated.
Those are answerable with the mechanism rather than with adjectives. Deletion locks with retention periods, MFA on lock removal, protection applied to replicated snapshots on the target, and a documented restore path with a measured duration make a better answer than a purchase order for an appliance.
Where immutability fits
Immutability is a property you apply to backup storage, not a product in itself. If the question is where that storage should live and what it should cost, immutable storage without appliance lock-in covers the economics. If you already know you need it and want to work out what to keep local versus replicated, planning immutable storage covers that.
For how Catalogic implements it, see immutable storage for backups or request a demo.
Pawel Staniec
CTO
Pawel is CTO at Catalogic Software, where he owns DPX product architecture and technology direction and works with our developers, alliance partners and customers across EMEA to keep what we build aligned with how our data protection products are actually deployed. He writes about the engineering behind our releases, including NDMP backup management, Proxmox VE protection, and where hypervisor-native backup tooling stops being enough.
