An immutable backup retention control prevents a recovery point from being changed or deleted during a defined period, including by a compromised privileged account when the storage system enforces that rule. It protects availability of the copy; it does not prove the copy is recent, decryptable, application-consistent, or free of corrupted data. Some retention modes cannot be shortened after a lock becomes final.
Make this comfortable
Immutable backup retention: protect recovery copies from deletion
Operational decision
A ledger service retains daily recovery points for forty-seven days in a separate backup account. Set minimum and maximum retention under a reviewed policy, allow the provider's cooling period to elapse only after testing lifecycle behavior in a disposable vault, and keep write access separate from delete administration. The text block is a control record, not a provider configuration file. Attempt a denied delete with a test identity and restore a recent recovery point into isolated infrastructure. Verify the schema, decryption key, row counts, and one synthetic transaction. Keep a catalog of recovery points with their expiration and restore location. If a backup is infected or logically corrupt, immutability preserves that bad state too; retain older known-good points and test recovery from more than the newest copy. Never enable indefinite retention accidentally, because a permanent lock can create an unavoidable cost.
Ledger recovery-copy policy
Daily recovery point; retention: 47 days
Storage account: separate from application writers
Deletion test: privileged test identity denied
Restore test: isolated database and synthetic ledger query
Key check: decrypt oldest retained point
Review: expiry inventory and monthly restore resultCost and verification
Protected copies consume storage for the entire enforced period, and long retention multiplies cost as data grows. Cross-account and cross-region copies add transfer and operational overhead. A shorter period reduces cost but may leave no clean copy after a slow-moving corruption. Set the period from the business recovery and investigation window, then verify it with an actual restore. Monitor failed backup jobs and the age of the newest verified recovery point, not only the existence of a locked vault.
Common Mistakes
- Do not treat a locked vault as evidence that its contents restore correctly.
- Do not set permanent retention without a deliberate long-term cost decision.
- Do not keep all recovery copies under the same credentials as the production writer.
Connected lessons
- DevOps: delivery, infrastructure, and reliable operations
- Backups and disaster recovery: prove the restore path
- Volume snapshots: test application-consistent restore
- Cloud cost and capacity: assign an owner to each recurring resource
- Credential incident response: revoke access before rebuilding trust
Practice and check
Advanced follow-up
Advanced follow-up
Object storage follow-up
devops
operations