Immutable backups: what the lock protects and why restoration matters

A successful backup job does not answer whether someone can delete the backup prematurely. Immutability restricts changes to or removal of protected data according to the storage system's rules. Its practical value becomes especially clear when an attacker or an incorrect operation reaches backup administration.

For a company, this is not about buying a “ransomware-proof” label. It needs to know which copies are protected, until when, who can change the setting and whether an application can be restored. The following comparison explains principles using Amazon S3 and Azure Backup; their settings are not interchangeable.

What the lock should protect against

WORM means write once, read many: write data and read it repeatedly, while the protected version cannot normally be overwritten or removed during its protection period. Specific exceptions and privileges depend on the product and mode. Immutability is not synonymous with encryption, network isolation or verified recoverability.

We suggest starting with the problem the company wants to solve. Administrator error, a compromised backup account and loss of an entire location are different scenarios. One setting may not solve them all. The design should therefore also separate access and independently verify availability of required keys.

On S3, both the mode and object version matter

Amazon S3 Object Lock protects object versions and requires versioning. Governance mode allows protection to be bypassed with a special permission; during retention, compliance mode does not permit shortening protection or deleting the protected version through ordinary user operations, even for the account's root user.

This is not a claim of absolute indestructibility. It describes the boundary of a specific mechanism. In an audit, ask not just whether a bucket is “locked”, but which mode and retention date apply to the actual backup object version. A new version with the same name is not automatically the same protected copy.

S3 operational considerations need assessment alongside object lifecycle and the backup tool being used. Compatibility is not established merely because a storage system supports a similar API.

In Azure, enabling differs from locking

For an Azure Backup immutable vault, enabling immutability alone is reversible. The enabled and locked state cannot be disabled. Before locking, verify the impact on data retention and planned operational tasks.

Support also depends on vault type, workload and regional WORM availability. Vault immutability does not cover all operational backups. Do not infer that every copy produced by any Azure service automatically receives identical protection.

The separate soft delete mechanism postpones permanent deletion and allows recovery within the applicable protection period. It should not be confused with an immutability lock. Ask for the exact protection type rather than just a green status in an overview.

A model test using one non-production backup

Imagine a company wanting to retain a selected test copy for 30 days. This is an illustrative requirement, not a recommended legal or universal period. In an isolated test environment, create a backup without personal data and record its identifier, timestamp and protection expiry.

The administrator then verifies the setting on the actual stored copy and restores it to a separate destination. Only a planned test with clearly defined permissions should establish whether the product rejects unauthorised premature removal. Do not attempt this on the only production backup or without the data owner's consent.

Success has two parts: protection behaves according to the selected mode, and the restored content is usable. The second part includes opening the data or testing the application, not merely finding a file in a directory. If either part fails, the lock alone does not resolve the problem.

What may become costly or remain unprotected

Longer retention means protected copies cannot be treated like temporary files. Before permanent locking, the company needs to understand volume, expected growth and storage funding. This article provides no price: it depends on the service, region and usage.

The operational agreement should also assign responsibility for recovery and access to keys. Locked but unreadable content is of little use. Protecting an old copy likewise does not replace checking that new backups are being created. Monitoring should distinguish failed backups, missing protection and failed restore tests.

The decision before an irreversible step

Before approval, ask to see a specific protected copy, its mode, retention expiry and restore result. Then agree on permissions and operational consequences. This is our practical decision framework, not a universal vendor procedure for every product.

Through cloud and backup services, Yenwa can examine existing copy protection and prepare an isolated restore test. Start with one important application and ask who can delete or change its backup.