Architecture and operating model
Object Lock or WORM policy prevents a protected object version from being deleted or overwritten before retention expires. It does not prove that a backup job succeeded, that data is application-consistent or that the account remains uncompromised. Pair an immutable target with independent identity, versioning, restore tests and catalogue protection.
Amazon S3 Object Lock offers governance and compliance retention plus legal holds for versioned objects. Google Cloud Bucket Lock irreversibly enforces a bucket retention policy once locked. Azure immutable blob storage provides time-based retention and legal holds. Similar names do not imply identical scope, locking steps, extension rules, account-deletion boundaries or supported object types.
Governance-style modes may allow an authorized bypass; stronger compliance or locked policies can create cost and regulatory risk when configured incorrectly. Start with a short-lived pilot bucket or container and test data. Validate production retention against the backup product's synthetic full, merge, prune and catalogue behavior.
- 1Backup job
- 2Versioned object
- 3Retention or legal hold
- 4Independent restore validation
Design parameters
- Retention unit
- Determine whether policy applies to bucket/container or object version and how new versions behave.
- Separation of duties
- Separate backup writers from retention administrators and account owners.
- Lifecycle
- Include delayed tiering or deletion of locked objects in the cost model.
- Recovery path
- Test that catalogue, encryption keys and restore identity do not share the same administrative failure domain.
Worked example
At 2 TB of daily change and 30 days of lock, 60 TB is created before reduction. A measured 40% reduction suggests about 36 TB, but full copies, version overhead, API calls and failed immutable jobs also matter. Do not freeze a budget around an untested ratio.
Write pilot data with seven-day retention. Attempt deletion as the normal writer, a privileged administrator and through lifecycle rules, then perform a real restore to an isolated account. A lock icon in the console is not an acceptance test.
Example commands: replace lab values and confirm permissions and software versions before use.
# AWS example; replace account, bucket and dates in a pilot.
aws s3api get-object-lock-configuration --bucket doz-backup-pilot
aws s3api head-object --bucket doz-backup-pilot --key sample.bin
# Capture equivalent retention state through the official GCS/Azure CLI.Troubleshooting
| Observation | Likely cause / distinction | Verification |
|---|---|---|
| Prune repeatedly fails | Backup software may be deleting a locked version before expiry. | Compare object version and retain-until values in job logs; do not try to shorten retention retroactively. |
| Cost grows faster than expected | Locked old versions and failed-job remnants may resist lifecycle deletion. | Inventory bytes by age, version and retention state. |
| Locked data cannot be restored after account loss | Keys, catalogue or restore role may share the production account. | Run recovery without the production administration identity. |
Acceptance checks
- Show that versioning and retention apply to newly written objects.
- Record unprivileged and privileged deletion attempts.
- Test retention extension and attempted shortening.
- Run backup prune and merge operations in the pilot.
- Restore a sample with independent identity and keys.
- Alert on locked bytes and forecast cost.
Related concepts
Immutability and deletion authority
Immutable retention restricts modification or deletion for a defined period. An application promise, storage-enforced protection and physical isolation are different controls. Review lock duration, clock handling, administrative privileges and deletion paths together. Whether data is automatically deleted after expiry depends on the product policy. On a controlled test copy, attempt deletion using ordinary and privileged accounts, then verify recovery from the protected copy. Protection against deletion does not replace a readability or restore test.
Retention and capacity
Retention defines which recovery points are kept and for how long. Daily, weekly and monthly points do not represent identical change patterns; full-copy creation and chain dependencies affect physical capacity. Retention decisions combine business requirements, applicable obligations and technical capacity. Longer retention does not automatically provide better recovery: the right point must be discoverable and readable. When changing a policy, test whether existing points are deleted immediately or handled differently by the product.
Durability and power loss
Survival of committed data depends on write guarantees across the database, OS, filesystem, controller and disks. Do not disable safety settings for speed without understanding caches and flush behaviour. Power-loss-protected storage helps but does not prove correctness of the entire chain. Run failure and recovery tests in a controlled lab, not production. Validate application records and supported consistency checks rather than merely opening a sample file.
File permissions and service identities
File access combines users/groups, permission bits, ACLs and security policies. Running an application as root can hide permission problems; prefer a justified, restricted service identity in production. Directory traversal permission differs from file-read permission. Sharing permissions do not necessarily override filesystem restrictions. Identify the actual runtime user, directory chain and ACLs when troubleshooting. Test narrowly required access rather than opening permissions globally.
Cost boundaries
Cost includes more than purchase price or a monthly resource bill. Licensing scope, storage, egress, backup, support, operating effort and disruption impact are separate items. Compare equal service levels, capacity and time periods; a cheaper option may exclude an obligation. Compare forecast and actual spending by resource or business unit. Assess underuse risk for commitments and uncontrolled growth for flexible models. Verify pricing and licensing conditions against official documents at decision time.
RPO and the actual loss window
RPO is the acceptable duration of data loss after an incident. A backup schedule alone does not prove it: failed jobs or delayed replication to another site can enlarge the window. Compare the incident time with the latest usable, consistent recovery point. If an incident occurs at 14:00 and the verified copy is from 13:20, the observed loss window is 40 minutes. Set targets per application; a file archive and a database receiving continuous orders may have different requirements.
Primary documentation
Prepared by the Doz Teknoloji technical team using the primary references below. Calculations and lab scenarios state their assumptions; validate the applicable product version before rollout.