Immutable storage protects backup data against changes or deletion. Its scope depends on the data covered, retention settings and permissions for early removal. These settings determine which recovery points remain protected and for how long.
How WORM Relates to Immutability
WORM means Write Once, Read Many. It describes a storage model that prevents protected data from being overwritten or erased. Immutability describes the protected state of the data; WORM is one way to achieve it.
Both tape-drive controls and storage software can implement WORM. Cloud object locks can protect individual versions for a retention period or under a legal hold. Protection modes differ in their scope and in whether an authorized user can remove protection early. The WORM versus immutability comparison gives examples of these controls.
Snapshots and versioning preserve earlier data and need configured protection against deletion. A snapshot on the original repository depends on that repository’s availability. Independent copies support recovery when that repository is unavailable.
How vStor Protection Controls Work
Catalogic vStor provides snapshot locks, volume deletion protection and file immutability. These controls have different scopes, as explained in the vStor immutability documentation.
| Snapshot lock | How it is managed |
|---|---|
| Fixed Protection | Cannot be changed or disabled before the configured retention period expires |
| Flexible Protection | Can be adjusted or removed by an authorized user using MFA |
MFA must be enabled to configure deletion locks. It does not allow early removal of a fixed snapshot lock. A volume deletion lock is a separate control that prevents deletion of the volume and can be disabled using MFA; it does not freeze the contents of every active file. File immutability has its own apply and remove operations, with MFA required for removal.
Protection can also be applied to replicated snapshots when configured on the replication relationship. Changing that setting does not remove existing locks from snapshots already uploaded to the target.
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.
A protected backup can retain compromised data from an infected system. GuardMode helps assess ransomware indicators, while GuardMode Scan in vStor checks supported mounted filesystems for suspicious files and signs of encryption. Review the findings and test a restore to validate the recovered workload. A scan result does not certify that every file is clean.
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.
