Reconcile with same-day Forgejo backup assessment

Risk analysis R2 updated (one restore now evidenced), workplan cross-referenced
with the assessment's pickup queue; new T08 tracks cross-repo backup items.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
tegwick 2026-07-04 12:46:22 +02:00
parent 2f6f489289
commit ddea827192
2 changed files with 35 additions and 7 deletions

View file

@ -5,6 +5,8 @@ Author: claude-code (session with Bernd)
Status: baseline — to be revisited after AssetRegister and first restore drill
Source: `specs/ResilienceControlSetup.md`, `INTENT.md`, current Coulomb/Helix stack
(Gitea, k3s, CoulombCore, Bubble.io, Stripe, OpenRouter, DNS, secrets, Ansible)
Companion: `2026-07-04-forgejo-backup-strategy-assessment.md` — same-day
Forgejo/Railiance deep-dive with a concrete pickup queue for this repo
## Purpose
@ -33,8 +35,11 @@ recovery asset, offsite encrypted backups, DNS cutover procedure, quarterly rebu
The classic silent failure: dumps run for months, first real restore reveals
corruption, missing volumes, undumped databases, or an unknown passphrase.
**L4 / I5** (it converts every other risk into a total loss). Exposure today:
critical — no restore has ever been evidenced.
**Mitigation:** the TestEvidence loop itself — monthly restore drills with dated
high — exactly one restore has been evidenced: the 2026-07-04 Forgejo isolated
restore drill (RAIL-HO-WP-0005-T09, evidence in `railiance-infra`). Gitea (the
canonical source forge today), CoulombCore content, databases, Bubble exports,
and the secret vault have never been restore-tested.
**Mitigation:** the TestEvidence loop itself — recurring restore drills with dated
reports measuring actual RTO/RPO. This is the highest-leverage artifact in the repo.
### R3 — Ransomware / hostile access deletes backups too

View file

@ -22,6 +22,11 @@ Driven by `history/2026-07-04-initial-risk-analysis.md` — priority order R2
R4/R5 (identity & secret recovery), R10 (control plane single-homed), R1
(full server loss). Design source: `specs/ResilienceControlSetup.md`.
The same-day Forgejo/Railiance assessment
(`history/2026-07-04-forgejo-backup-strategy-assessment.md`) proved the Forgejo
restore path (RAIL-HO-WP-0005-T09) and handed this repo a pickup queue: its
items 78 are T03/T04/T06 below; its cross-repo items are tracked by T08.
## Mirror disaster-control off the primary Gitea (R10)
```task
@ -100,11 +105,14 @@ status: todo
priority: high
```
Perform one real restore to a clean target — smallest meaningful scope (e.g.
one Gitea repo from a `gitea dump`, or the secret vault decrypted from cold) —
and write `TestEvidence/restore-drill-2026-MM-DD.md` with measured RTO/RPO,
result, issues found, and follow-up actions. This task is the exit criterion
for the workplan: no drill evidence, not finished.
The 2026-07-04 Forgejo drill (evidence in `railiance-infra`) proved that path;
this task covers the next untested system: restore one Gitea repo/dump or
decrypt the secret vault from cold, onto a clean target. Write
`TestEvidence/restore-drill-2026-MM-DD.md` with measured RTO/RPO, result,
issues found, and follow-up actions; also copy or link the Forgejo drill
evidence so this repo holds the complete evidence trail. Define the recurring
drill cadence (pickup item 7). This task is the exit criterion for the
workplan: no drill evidence here, not finished.
## Incident playbooks (R3, R4, R5, R6, R7)
@ -118,3 +126,18 @@ Write the five playbooks under `IncidentPlaybooks/`: ransomware/hostile access,
credential leak, accidental delete / data corruption, provider outage
(Bubble/Stripe/OpenRouter/DNS/email), loss of admin identity. Keep each to one
page of numbered steps per the spec (§6).
## Track cross-repo backup pickup queue (R2, R9)
```task
id: DISCTL-WP-0002-T08
status: todo
priority: medium
```
Drive closure of the cross-repo items from the Forgejo assessment's pickup
queue (items 16: backup destination decision #7, CNPG ScheduledBackup,
scheduled `forgejo dump`, `railiance-backup` tool, Gitea pre-cutover snapshot,
`apps-pg` coverage). Implementation lives in `railiance-platform` /
`railiance-apps` / `railiance-infra`; this repo tracks status and records the
outcome in the registers and BackupPolicy as each item lands.