coulomb/railiance-platform
5
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Propose platform admission for coherent coulomb-social offsite backups

Browse source 
Assistant: codex
Assistant-Model: gpt-6.1-sol
Assistant-Session: 01a11538-05ea-7b63-b3c7-a2df5f38898d
This commit is contained in:
codex 2026-10-07 19:04:49 +02:00
parent 22651d851f
commit 5a19434c7f
1 changed files with 98 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

98
workplans/RPF-WP-0053-coulomb-paired-backup-admission.md Normal file
View file

@ -0,0 +1,98 @@
---
id: RPF-WP-0053
type: workplan
title: "Admit coherent coulomb-social offsite backup and recovery"
domain: financials
repo: railiance-platform
status: proposed
owner: codex
topic_slug: coulomb-social
created: "2026-10-07"
updated: "2026-10-07"
---
Consumer request from CSOC-WP-0008-T02. The app now has real paired
quiesced database/content capture and isolated restore evidence; local temporary
copies and database-only CNPG jobs do not provide its durable recovery contract.
This is a proposed platform admission record, not an owner acceptance or live
approval. Existing mechanism ownership stays with railiance-platform.
Reviewable consumer implementation: coulomb-social/scripts/paired-backup.py,
scripts/snapshot-content-and-db.py and deploy/backup/*.service/*.timer.
Consumer runbook: coulomb-social/docs/release/paired-backup-operations-2026-10-07.md.
No credential was fetched, no timer enabled, no live upload/overwrite performed.
## T01 — Review and accept the paired backup execution identity
```task
id: RPF-WP-0053-T01
status: todo
priority: high
```
Choose the platform execution owner: the prepared node systemd units or the
existing bounded activity-core execution lane. Review single-writer quiescence,
lock, termination/resume behavior, exact cluster UID, app digest and data scope.
Node systemd candidate uses root/k3s admin, guarded to coulomb-social and
coulomb_social_db; that authority is not a new credential grant and needs
explicit owner/founder admission before unattended operation. Prefer a scoped
platform identity where its execution contract supports coherent DB/PVC capture.
Do not mark the warden offsite workload identity resolved without a declaration.
## T02 — Admit offsite prefix, retention and caller custody
```task
id: RPF-WP-0053-T02
status: wait
priority: high
needs_human: true
intervention_note: "Platform must admit the backup workload and exact Nextcloud prefix/slot overwrite contract, and deliver bounded caller custody before live activation."
```
Reuse governed railiance-backup-offsite-lane, OpenBao path
platform/workloads/railiance/backup/offsite-lane. Admit independent prefix
coulomb-social and 14 daily + 4 weekly encrypted fixed slots; prove directory
existence, PUT replacement and recoverable retrieval. Prepared node consumer
expects root-owned mode-0600 /etc/coulomb-social-backup/offsite.env with
RAILIANCE_BACKUP_NC_TOKEN and RAILIANCE_BACKUP_NC_WEBDAV_URL delivered by the
custody owner; public age recipient is inherited from the platform helper.
Do not put AGE_PRIVATE_KEY in the scheduled worker. Decide delivery/rotation
using the owner contract, rather than copying another workload's Secret.
## T03 — Activate and verify retrieval and application recovery
```task
id: RPF-WP-0053-T03
status: wait
priority: high
needs_human: true
intervention_note: "Needs T01/T02 owner admission and founder go for the exact first quiescence/upload and schedule; independent offsite retrieval and recovery proof remain required."
```
Founder ADMINISTER @ realm:kubernetes/railiance01, activation=APPROVED, plus
explicit offsite prefix write/overwrite authority. Proposed UTC daily03:15
(+up to5min jitter), RPO target24h, hourly stale threshold26h, provisional
RTO target60min for an admitted attended restore. These are proposal targets,
not measured promises. First capture/upload is bounded and app resumes before
encryption/upload. Retrieve ciphertext independently, compare encrypted hash,
decrypt through recovery escrow into a private isolated workspace, unpack only
database.dump/content.tar.gz/receipt.json, run app paired restore and compare
row/sequence/file hashes, actual rendering and denial. Record receipt paths,
counts/timing only; preserve the source recovery point on any failed check.
No production data restore is part of backup schedule activation.
## T04 — Bind monitoring and recurring recovery custody
```task
id: RPF-WP-0053-T04
status: todo
priority: high
```
Connect non-secret freshness/provider receipts and failed units to the
established evidence owner (RPF-WP-0036-T03/T04), prove reception and failure
response; local journald failure alone is not monitored acceptance. Name the
recovery custodian and approve a monthly isolated drill with offsite readback.
Verify key recovery survives node/workstation loss. Record release-triggered
backup helper digest refresh and retention-slot policy. CSOC-WP-0008-T02 stays
progress until operating evidence and service contract are accepted.