Verify Scaleway primary recovery and distinguish secondary backup coverage
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
CI Smoke / container-smoke (push) Successful in 1s

Assistant: codex
Assistant-Model: gpt-6-astra
Assistant-Session: 01a06ecb-456a-71c2-b41e-0755d336e883
This commit is contained in:
codex 2026-09-06 00:34:43 +02:00
parent 9269d9d8f4
commit d05c3000c5
10 changed files with 170 additions and 7 deletions

View file

@ -242,3 +242,18 @@ open. The installed generator would reproduce them; exact UUID mapping and
remaining owner requirements are persisted in
`history/2026-09-05-blocked-workplan-closure-review.md`. No duplicate recovery,
monitoring or owner-transfer workplan was created.
## Primary backup coverage — 2026-09-06
Scaleway is the selected primary; Nextcloud is the independent secondary.
Fresh apps-pg recovery from Scaleway passed in 42.64 seconds with expected
consumer databases and limits, production Ready and scratch cleanup complete.
Evidence: `docs/evidence/scaleway-primary-restore-2026-09-06.json`.
T03 now has this fresh physical recovery receipt but still lacks recurring
cadence, the other recovery surfaces and validated evidence adapters.
The source/live coverage inventory `docs/backup-provider-coverage.md` exposes
missing native primary configuration on forgejo-db/net-kingdom-pg/state-hub-db
and no reviewed Scaleway Forgejo archive destination. Track primary coverage
here with forge/package/storage owners; do not silently claim the Nextcloud
account cutover filled it or weaken WP-0029's separate incident closure.