Venus DB backup lane: executor unknown, last local dump 2026-06-16 — identify owner or declare backup-gap incident; fix db/README.md §Backup

Sub-tickets

Questions

Activity

• wi-cli-venus created · 2w ago
• wi-cli-venus note · 2w ago
  bin-venus-cc findings (msa25eckemvp): venus clinical DB is SUPABASE-HOSTED (fjnhfjwskixzsilxrkph) — host-side executor hunt structurally cannot find a platform dumper. Venus host runs NO pg_dump (script/timer/cron all absent). ~/gdrive/backup/venus dead since 2026-06-16 (was 2-hourly); adjacent agent-state lane is ALIVE but contains zero clinical data (trap for readers). Leading hypothesis: observed postgres-role COPY = Supabase managed backup → doc defect, not data loss. Platform PITR/backup retention UNVERIFIED. Dispatched: coder-venus-cc to attempt Management API backups read via VENUS-303 credential (msa25ugz2n2e); db-venus-cc to capture application_name/client_addr/sequential-walk on next COPY hit (msa25yrutfby). Elazar escalation held until either returns; honest state = self-managed lane dead, platform coverage unverified.
• wi-cli-venus note · 2w ago
  db-venus-cc discriminator (msa26f7a2zo8): pg_stat_statements IS installed on the Supabase project (bin's 'not installed' read was a different surface/role — to pin down). COPY inventory = FULL-DATABASE pg_dump signature: walks every schema sequentially (public, auth.*, storage.*, realtime.*, cron.*, supabase_migrations, vault.secrets) as role postgres, matched call counts, ACTIVE ~3/day. Executor+destination unidentifiable from SQL; vault.secrets read implies platform-privileged → platform backup leading candidate; open wrinkle: platform cadence is 1/day vs observed ~3/day. WI wording upgraded: self-managed gdrive lane dead since Jun 16; ACTIVE unattributed full-dump lane (~3/day, postgres role); platform backup/PITR setting UNVERIFIED — coder-venus Management API read in flight (msa25ugz2n2e).
• wi-cli-venus statusChanged · 2w ago
  INCIDENT: Management API VERIFIED (coder-venus msa276ikg9sk, HTTP 200): pitr_enabled:false, backups:[] — platform reports ZERO restorable backups. With self-managed lane dead since Jun 16, venus clinical data has NO verified restorable backup. Elazar notified (msa27juy8ur5). bin-venus-cc dispatched to re-stand pg_dump→gdrive lane + immediate dump (msa27qbvg2v6). ~3/day full-DB dump stays UNATTRIBUTED (postgres logs silent on application_name/client_addr; passive watch fallback). Byproducts: bin's false-negative = unqualified name + search_path lacking extensions schema ('does not exist' error asserts absence when truth is inaccessibility — keep); PostgREST sentinel ERROR every ~32s = empty exposed-schema list (desired posture) but ~2700 rows/day log noise floor — separate WI candidate.
• wi-cli-venus note · 2w ago
  bin-venus (msa2mhw4z2r4): BACKUP LIVE — first encrypted artifact venus-prod-20260801-0746.sql.gz.gpg (2.7MB enc / 23MB restored), independently verified by decrypting the GDRIVE copy: 82 CREATE TABLE (public 47 + auth 23 + storage 8 + realtime 3 + supabase_migrations 1), 50787 rows; auth.* included so logins restore with clinical data. Script pushed sh.git 3de77c0, maintainer row 82 filed. Restore key escrowed off-venus (2 holders, DM-only). NOT automatic yet — timer unit drafted + handed to nw-venus-cc; until installed the lane is manual-only. Do NOT close on this alone.
• wi-cli-venus note · 2w ago
  Backup-gap picture REVISED (nw-whey-cc msa2u10ka9sw): a live venus backup lane has existed on WHEY the whole time — evolutiva-backup@venus.timer, 3/day, pg_dump public+auth, /gdrive/backup/evolutiva/venus (2-day retention) + whey USB backupYes (90-day retention). The 'gdrive lane dead since Jun 16' finding referred to the venus-host lane; the whey lane kept running. Zero-restorable-PLATFORM-backups finding (pitr false, backups:[]) unchanged. bin's encrypted lane remains the venus-host protective rebuild; whey lane is unencrypted at rest on gdrive/USB — coverage now: two independent dump lanes.
• wi-cli-venus note · 2w ago
  Revision (bin msa2wvd0mofy): whey's lane is working but PARTIAL — omits storage (8 tables/61 rows), realtime (3/79), supabase_migrations (1/82; restored DB would lose migration history), unencrypted at rest, gdrive copy only 2-day retention (90-day depth is whey USB — gone if whey is gone). Accurate picture: venus had a partial unencrypted 3/day lane nobody venus-side knew about, and now also a full-schema encrypted verified-restorable lane. Keep BOTH — different failure modes, different hosts; retire neither.
• wi-cli-venus note · 2w ago
  nw-venus-cc (msa32y04m50j): timer unit INSTALLED — venus-db-backup.timer + staleness alert, both enabled, live-verified. Encrypted lane now automatic. Remaining before close: db/README.md §Backup rewrite to the measured two-lane reality (whey partial public+auth lane + venus encrypted full-schema lane, escrow location pointer without the secret) — dispatching coder-venus-cc.
• wi-cli-venus completed · 2w ago
  Backup gap closed: encrypted full-schema lane live+automatic (sh.git 3de77c0, venus-db-backup.timer + staleness alert), first artifact decrypt-verified; whey partial lane documented; db/README.md §Backup rewritten to measured two-lane reality (198a1d6, markdown-only, origin-verified). Unattributed-reader remainder lives in VENUS-350; DR.md staleness split to its own WI.