Configure an immutable backup window long enough that at least one clean recovery point remains locked when accidental deletion, ransomware, or administrator compromise is finally detected.
Do not choose the window from a vendor default alone. A short lock can expire before a slow incident is discovered; an excessively long lock can trap bad backups, consume capacity, and prevent normal retention. Build the window from detection delay, backup frequency, desired clean history, available storage, and the time required to verify recovery.
Define What “Immutable” Must Protect Against
Immutability means a protected recovery point cannot be modified or deleted for a defined period, even when ordinary backup credentials are compromised. It is different from encryption, versioning, snapshots, offline media, and offsite placement, although those controls can complement one another.
IBM's 2026 overview of cannot be altered or deleted describes the core WORM model: once written, protected data remains read-only through its retention period. Use that definition as the acceptance test for any NAS feature marketed as immutable.
Ask who can shorten retention, delete the dataset, remove the storage pool, rotate credentials, or disable future protection. “Admin-only deletion” is not the same as immutability when ransomware may steal the admin account.
Set the Window Longer Than Realistic Detection Delay
If a compromised laptop starts encrypting files on Monday but the household notices on Friday, a two-day immutable window may preserve only encrypted versions by the time recovery begins. Estimate the longest plausible delay for accidental deletion, silent corruption, credential compromise, and ransomware.
A 2026 retention shorter than dwell time emphasizes that the fixed window must survive the interval during which attackers can remain active and backups continue to run.
Protect multiple recovery points across the window rather than one locked latest copy. A clean daily point from before compromise is more valuable than a single immutable snapshot taken after damage already spread.
Balance Retention Lock Against NAS Capacity
Immutable data cannot participate in ordinary deletion until its protected window expires. If the backup set changes quickly, extending the window can increase space use far faster than expected because old protected versions remain present while new versions accumulate.
A 2026 Object Lock analysis warns that locked data keeps consuming storage because locked objects continue occupying storage even when normal retention would otherwise delete them.
Model daily changed data, backup frequency, deduplication behavior, and minimum free-space reserve before setting the lock. Do not allocate the entire NAS pool to immutable history; maintenance and ordinary backups still need working space.
Separate Backup Writer Rights From Retention Control
A stronger design lets routine backup clients create new recovery points without giving them the power to erase or shorten protected history. Use dedicated backup identities, separate administrator credentials, and storage-side retention where the platform supports it.
A 2026 guide to encryption and immutability differ explains why encryption, versioning, append-only access, and Object Lock protect different failure paths. The principle transfers to other backup tools: deletion authority should not automatically travel with write authority.
The related ZimaSpace ransomware article on protected recovery copies provides the broader NAS control-plane model: snapshots or backups help only if attackers cannot destroy the same recovery path.
Test Expiry, Restore, and Capacity Before Extending the Window
Create a disposable protected backup, attempt an ordinary deletion through the backup account, verify that the platform blocks it, then restore a representative file from the locked point. Also verify what happens when the retention period expires and normal pruning becomes eligible again.
A recent analysis of immutability does not guarantee recovery notes that data immutability does not automatically protect every management component or guarantee recoverability. That is why restore testing remains part of the configuration.
Start with a window that covers the realistic detection period plus recovery margin, monitor how much protected capacity accumulates, and extend only when the NAS can sustain the additional history. Immutability is effective when a clean point survives the incident and remains practically restorable.
Support & Tips
More to Read

How to Match Docker Restart Policies to Databases, Workers, and Web Apps
Match restart policy to service lifecycle and exit semantics. Pair it with health and readiness checks; do not use restart loops to hide dependency...

How to Configure Container User IDs Across Multiple NAS Shares
Map each container's UID/GID to its NAS shares, use shared groups or ACLs where needed, and treat PUID/PGID as image-specific—not universal Docker settings.

How to Set Up Docker Compose Profiles for Optional Home Server Services
Leave required services unprofiled and use profiles for optional tools. Test direct targets and dependencies instead of assuming a profile starts a full stack.

