Immutable backup review

How to use

Quarterly, with the storage owner present, and not as a documentation review. Four of the items below are settled only by attempting a deletion against a protected version and recording what the storage returned — once with the credentials a production host holds, once with the most privileged credential in the estate.

Attempt it against a purpose-written rbdr- prefixed object placed in the same bucket under the same policy, never against the newest known-clean recovery point. The attempt is not a formality: if the refusal does not hold, that object is gone, which is the whole reason to choose a disposable target.

Work the items in order: the first three decide whether the rest has a subject, since an entry naming no mechanism and no mode is a claim, not a control.

Where the numbers come from

Every exit status here comes from an attempt, never from a console screenshot or a policy document. The three below were captured on 2026-08-28 against MinIO RELEASE.2025-09-07T16-13-09Z with mc RELEASE.2025-08-13T08-35-41Z.

$ mc retention set --default COMPLIANCE 7d lab/rbdr-plain

  mc: <ERROR> Unable to apply bucket lock configuration. Object Lock configuration cannot be enabled on existing buckets.
>>> exit code: 1

Locking is fixed at bucket creation on this implementation, so a bucket already holding a year of backups produces a migration project rather than a configuration change. Verify the same on your own platform.

$ mc rm --versions --version-id 133fd99f-1f98-41c0-9d08-95e6e2944157 prod/rbdr-immutable/backup-0900.tar

  mc: <ERROR> Failed to remove `prod/rbdr-immutable/backup-0900.tar`. Object, 'backup-0900.tar (Version ID=133fd99f-1f98-41c0-9d08-95e6e2944157)' is WORM protected and cannot be overwritten
>>> exit code: 1

--- can the FULL ADMIN force it? ---
mc: <ERROR> Failed to remove `lab/rbdr-immutable/backup-0900.tar`. Object, 'backup-0900.tar (Version ID=133fd99f-1f98-41c0-9d08-95e6e2944157)' is WORM protected and cannot be overwritten
>>> exit code: 1

Two refusals, exit 1 each, for two different identities. That pair is the evidence; the architecture diagram is not.

$ mc rm --bypass --version-id 1425b7eb-5124-4607-a19f-1ced4c55527c lab/rbdr-governance/backup-0900.tar

  Removed `lab/rbdr-governance/backup-0900.tar` (versionId=1425b7eb-5124-4607-a19f-1ced4c55527c).
>>> exit code: 0

Same tool, same window, different mode, and the version is gone. Record which mode each bucket carries and who holds that right.

The window itself comes from the object rather than the bucket: the capture read X-Amz-Object-Lock-Retain-Until-Date and X-Amz-Object-Lock-Mode off the version, and a bucket default only governs writes that follow it.

The cost figure is bytes written per day multiplied by the retention days, because nothing under retention can be released early to reclaim capacity. Count the markers too: the capture shows a 0B STANDARD v2 DEL entry above a 38 B version that is still stored underneath it.

Access this needs

Read access to each bucket’s versioning state, its default retention configuration, its lifecycle rules, and the policies attached to every identity that can reach it.

The credentials the backup job runs with, or a copy scoped identically, because the question is what those credentials can do and not what a policy summary says they can.

The platform’s most privileged credential, used once and under supervision. Nobody needs the bypass right to complete this review; a reviewer who needs it to finish an item has found the finding.

What the review produces

A dated record, per bucket, naming the enforcement mechanism, the mode, the window in days, the exit status of each deletion attempt and the identity that made it, the retained-until date read off a real version, the modelled bytes at the end of the window, and every lifecycle rule touching non-current versions with its scope and threshold.

The headline is one sentence: who in this estate can still destroy the newest known-clean recovery point, and by which route. Where the answer is that nobody tested could, name the identities tested; that is the honest form of the claim.

Nothing here entitles anyone to write the word “immutable” unqualified. The record says which mechanism, under which mode, for how many days, refusing which identities — and if it cannot say all four, the review has failed rather than passed.

Sign-off

• Reviewer: ____________ Date: ____________
• Storage owner: ____________ Date: ____________
• Security owner: ____________ Date: ____________

Every critical item must pass. A failing critical item is a blocker, not a note for the next quarter: record its disposition and the name of whoever accepted the residual risk.