railiance-platform/docs/backup-provider-coverage.md

Backup provider coverage — 2026-09-06

Primary: Scaleway Standard Multi-AZ, nl-ams, per RESOURCE-WP-0002 and the operator's confirmation. Independent secondary: governed Nextcloud account Backup, 10 GiB quota. Provider selection does not establish asset coverage.

Asset	Verified primary configuration	Secondary / remaining gap
apps-pg	Scaleway Barman base backups + WAL, platform-pg/apps-pg/	Fresh isolated physical restore passed in 42.64 seconds; Nextcloud logical copy is separate
platform-pg	Scaleway Barman base backups + WAL, platform-pg/	Earlier package restore evidence; independent logical Nextcloud copy
platform-pg-2	Scaleway Barman base backups + WAL, platform-pg/platform-pg-2/	Earlier package restore evidence; independent logical Nextcloud copy
forgejo-db	No native Barman destination observed	Logical SQL/full archive helper targets Nextcloud; primary coverage needs implementation
Forgejo repositories/packages/blobs	No reviewed Scaleway archive destination found	Corrected full-archive capture; 5.35 GB verified encrypted artifact staged; secondary download/application restore still pending
net-kingdom-pg / state-hub-db	No native Barman destination observed	Do not infer protection from the shared cells' healthy backup status
OpenBao / S1 host configuration	Not evaluated by this database restore	Their own encrypted snapshot/host backup and recovery contracts still apply

All three configured cells reported successful 2026-09-05 02:15 UTC backups. The fresh apps-pg restore consumed the existing Scaleway base backup and WAL in a unique scratch namespace, imported only the existing S3 credential fields in captured memory, preserved expected databases and connection limits, left production Ready and removed the namespace. This proves physical database recovery; it does not prove application workflows, PITR targets, or Forgejo recovery. Evidence: docs/evidence/scaleway-primary-restore-2026-09-06.json.

Forgejo primary extension requirements

The existing bucket policy permits the runtime identity only under platform-pg/*. Do not put unrelated archive objects in a Barman server directory or assume a top-level forgejo/ prefix is permitted. Before extending coverage:

1. Accept an exact independent archive prefix and storage/retention contract with reef-storage/resource-control; distinguish it from native database WAL.
2. Use the scoped backup runtime identity, never the Scaleway bootstrap key. Review its delivery to the scheduled archive uploader. The current approved ExternalSecret destination is in databases; activity-core must not inherit write credentials through an undocumented namespace expansion.
3. Use a streaming multipart S3 uploader for growing archives, with abort/cleanup and immutable object naming. Verify completion and content, then recover by GET from Scaleway into the isolated Forgejo procedure.
4. Set native forgejo-db Barman coverage through its owning package/source, with a separate tested recovery and no production in-place restore.
5. Record provider-native retention and primary failure reporting separately from the 10 GiB secondary budget. No retained backup deletion is implicit.

WP-0029 remains the secondary credential incident: old Bernd-share invalidation and replacement recovery. The full primary coverage gap belongs to S3 assurance (RPF-WP-0036-T03), with forge requirements and package/storage-owner inputs.