[rusholme]

Adds system/backups.md, the findings on the database's pgBackRest repository: bucket versioning, the WAL valve (archive-push-queue-max) with the ruling owed to Ben, and retention stated three ways. Brief pgbackrest-repo task 1 (queue item pgbackrest-repo, Ben's go 2026-10-27 18:47 UTC).

What and why

No backup page existed in system/ (grep for pgBackRest found only foundation.md's backups paragraph), so the findings are a page of their own, linked from that paragraph and listed in system/index.md and its toctree as DRAFT (one ruling pending).

Files: system/backups.md (new), system/index.md (row and toctree), system/foundation.md (one link).

Findings, in short

• Versioning: S3 and pgBackRest 2.60 agree with the bucket's lifecycle; rapid_systems PR 445 turned versioning on with a noncurrent expiry per rule (90 d repository, 7 d clone scratch). No delete-marker rule: Days on the rules already cleans lone markers.
• Valve: acts with archive-async off (2.60 command reference qualifies only the async details; the 2.59.0 release note names the synchronous queue). Past 64 GiB it reports success, drops the segment and warns in the PostgreSQL log. rapid-db-archiver-failing pages at least 50 min before any drop, then returns to OK once drops start (inference from the metric's definition, not observed); rapid-db-wal-40pct stays in ALARM with no action. Recommendation: keep the valve, add a full-backup step to the WAL-full runbook and make the drop visible. Ben's ruling owed; nothing changed.
• Retention: the policy keeps 21 to 28 days of point-in-time recovery (four weekly fulls), above the snapshot set's 14 days and meeting the GC horizon's 21-day floor; no edit. The repository holds 13.6 days now (oldest full stop 2026-10-14 03:52:04 UTC to the latest evidenced endpoint, segment 000000010000000400000090 archived 2026-10-27 18:35:24 UTC), short because the repository started 2026-10-13 and two hand fulls on 2026-10-14 took two places. Nothing in the repository has been restored; the 2026-10-13 drill's full has expired.

Measurements

Read (2026-10-27 UTC)	Value
pgbackrest version (host, 18:56)	2.60.0
fulls / diffs held	4 / 12
WAL archive min / max	…0000004C / …0400000090
segment names present in that range (19:00 listing)	1,093 of 1,093
pg_stat_archiver	archived 1,142, failed 0 since 2026-10-13
latest evidenced endpoint	18:35:24 (segment archive time)
repository span now	13.6 d
policy at steady state	21 to 28 d
last verify	2026-10-26 09:00, completed successfully, output none
WAL in the archive	5.9 GiB compressed, about 1.3 GiB/day raw

Raw evidence (~/Claude/briefs/pgbackrest-repo/t1/): info.out, version.out, archive-listing.txt, contiguity.out, verify-20261026.out, the fetched docs under docs/.

Divergences

• The brief asked to extend an existing backup page; none existed, so this is a new page.
• rapid_systems docs/architecture.md:86's "90-day, point-in-time secondary" is recorded on the page as an over-claim, not edited (rapid_systems is out of this PR, and the design's records piece rewrites that line).

Improvements seen

• The WAL-full runbook (rapid_systems docs/reference/wal-full-recovery-runbook.md) has no backup step after archiving resumes; that is the "keep" route's first edit, after Ben's ruling.
• verify runs with output none; --output=text would put what it checked into the association's output. Seen, not applied.

Session notes

none

What the next task must know

The page states the repository's state as of 2026-10-27 19:00 UTC; the restore drill is what replaces "nothing restored" with a number.

🤖 Generated with Claude Code