Repository navigation
Remove the stale Wedding database catalogue from the shared backup bucket #4481
Description
🤖 Generated by the Agentic Engineer
Evidence
Until the cutover (#3768), the Wedding database archived into the shared backup bucket under cnpg/wedding-db. That catalogue was mirrored into the dedicated bucket and proven equal (#3767), and a restore from the dedicated bucket alone is proven (#3769). #3253 then removes the wedding-db ObjectStore that pointed at the shared copy.
Two things follow from removing that ObjectStore:
- Nothing applies the 30-day retention to the shared copy any more, so it stays in the shared bucket indefinitely.
- Every holder of the shared backup credential (the Umami and Coroot database backups, and Velero) can still read those Wedding base backups and WAL. The isolation Isolate wedding database backups with a dedicated R2 identity #2867 asks for covers new backups only until the old copy is gone.
Deleting it is irreversible and touches production backup data, so it needs a deliberate, evidence-gated step rather than a side effect.
Expected outcome
The shared bucket holds no Wedding database backups, and the removal is shown to have left every other consumer's backups untouched.
Acceptance criteria
- Before anything is deleted, a read-only, dispatch-only proof shows the dedicated catalogue holds every base backup and WAL segment the shared copy holds, or has pruned it by its own retention (feat(backup): prove the dedicated bucket covers the stale shared Wedding catalogue #4488), and a recent dedicated-only restore proof is on record.
- The maintainer removes the shared
cnpg/wedding-dbprefix, and only that prefix, after the proof reports it covered. The scheduled engineer does not author or run the bulk deletion: its permission layer refuses that for cloud storage, by design. - Afterwards the same proof reports the shared prefix empty, and the Umami, Coroot and Velero backup locations still list their objects and complete a fresh backup.
-
docs/dr/velero-cnpg.mdrecords that the shared bucket no longer holds Wedding data.
Blocker: delete the shared cnpg/wedding-db prefix from the shared backup bucket | authority | last-verified 2026-10-14: the old copy is still there (812 objects, read-only proof run 38488804066); the proof now reports NOT COVERED because the dedicated bucket has aged out a September base backup under its 30-day retention; no reply in the ask thread or on the issue, and the scheduled engineer may not run a bulk deletion from cloud storage | asked slack 2026-10-05
Metadata
Metadata
Assignees
Type
Fields
Projects
- Status
Activity
chore: agent-claim #4481 nonce=63bb534d7d043ef1ce7e2c91199e3655
fix(backup): accept a missing shared object only when retention must …
fix(backup): accept pruning only where the oldest dedicated backup pr…
docs(backup): describe the shared Wedding catalogue coverage proof
devantler commentedon Oct 5, 2026
Covered: the dedicated bucket holds everything in the old shared copy.
The read-only proof from #4488 ran on protected
mainatb5fed1ef— run 37246546718, success:cnpg/wedding-dbcopy; all 812 are in the dedicated bucket with matching content. None had to be accepted as pruned by retention.A dedicated-only restore is already on record from #3769. That completes the first acceptance criterion.
What is left is the removal itself, and it is not mine to do. Deleting the shared copy is irreversible, and my permission layer refuses to author or run a bulk deletion from cloud storage — deliberately. So the remaining step is a maintainer action: remove the
cnpg/wedding-dbprefix, and only that prefix, from the shared backup bucket. Afterwards I re-run the same proof, which then reports the prefix empty, check that the Umami, Coroot and Velero backups still complete, and close this.One timing note: the dedicated store starts pruning by retention around 2026-10-13. The proof handles that, but today's result is the cleanest it will be — every object matched one for one.
devantler commentedon Oct 5, 2026
The proof says COVERED. The stale copy can now be removed, and that step is the maintainer's.
mainafter #4488 deployed (run 37246546718, 2026-10-05 00:15Z)20261001T030001; the dedicated store continues to20261004T223944The first acceptance criterion is met and ticked.
What is left
cnpg/wedding-dbprefix, and only that prefix. The scheduled engineer does not write or run a bulk deletion from cloud storage: its permission layer refuses that by design.docs/dr/velero-cnpg.md.Timing. The dedicated store keeps 30 days, so from about 2026-10-13 it starts pruning objects the shared copy still holds. The proof accepts that case, but the comparison is strongest now, while the result is 812 of 812.
#4482 must keep the comparison tool until this issue is closed.
devantler commentedon Oct 14, 2026
Read-back on 14 October: the old copy is still in the shared bucket, and the comparison is no longer exact.
The read-only proof ran on
mainagain (run 38488804066):The first object it reports as missing from the dedicated bucket is the base backup taken on 13 September. That is the dedicated bucket's 30-day retention removing its oldest backup, which the request on 5 October said would start around 13 October. Nothing was written or deleted by this run.
What this means:
No new message was sent; the request from 5 October is the open one.