DR posture of both projects, itemised

The itemised audit, ready to recite.

Traverse — what exists

1. WAL archiving: wal_level=replica, archive_mode=on, archive_timeout=300, archive_command → S3 bucket traverse-db-backups-697114252450 (us-east-1). Bounded RPO of 5 minutes, including idle periods (the timeout is the enforcement).
2. Offsite base backups: scripts/pg-backup-sync.sh on host cron (every 3 days) syncing to Aiven (AIVEN_BACKUP_DB_URL) — a managed provider as the "different vendor, different failure domain" copy (the 3-2-1's offsite leg).
3. Blast-radius separation: backups in a different region and with different credentials than user files (careers bucket, ap-south-1). A leaked application credential cannot read database backups.
4. Executable recovery: pitr.service.ts — status, backup listing, snapshot, restore, rollback-safety, history, exposed as admin endpoints. Recovery is a documented, callable procedure.
5. Redis AOF: job durability across restarts (≤1 s loss), paired with idempotent handlers.
6. Immutable-ish data model: submissions/solves/attempts are append-mostly; the derived state (revisions, streaks) is recomputable from facts — so partial loss degrades features rather than corrupting truth.

Traverse — the three gaps (fixes ready)

1. No immutability on the backup bucket: versioning + Object Lock (WORM) defends against deletion attacks (ransomware's first move). Bucket config, zero code.
2. No drilled restore: the endpoints exist; a scheduled quarterly drill (restore into a scratch DB, verify invariants, record RTO) is the missing practice.
3. Soft-delete purge not implemented: User.deletedAt + grace exists; the job that hard-deletes after grace (and cascades to caches/derivatives) doesn't — so "deleted" data persists indefinitely, which is both a compliance and a storage issue.

Zoth — what exists and what doesn't

Exists: Postgres in-cluster with a PVC (survives pod reschedule); Aiven managed PG in the prod env config (.env.prod) — so a managed instance is provisioned, which is the seed of a real story; migrations embedded (schema is reproducible from the repo); the audit chain (integrity, not durability); drift detection (reconciles external state, not data loss).

Doesn't exist: WAL archiving, base backups, restore runbook, drills, RPO/RTO definitions. Recovery = redeploy + re-seed.

The honest framing (this is the version to use): "Zoth's data is demo-scale and largely regenerable (users/groups sync from the identity provider; access requests are workflow artifacts). I chose not to spend the budget on backup infrastructure for data I can reconstruct — and I can say exactly what production would require: archive_command to Azure Blob, daily base backups, a restore runbook, and a monthly drill. Traverse, whose data is not regenerable (user history), got the full treatment. Matching durability investment to data value is the decision; the mistake would be doing neither."