Self-hosted Supabase backups and PITR: verify and run a restore drill

FeaturePlannedView on roadmap· by Elsama· 5 months ago

Context: Backup and point-in-time-recovery posture for the self-hosted Supabase Postgres is not visible from the app repo. This is a priority before marketing traffic.

Scope:

Confirm automated Postgres backups exist (frequency, retention, offsite copy).
Confirm WAL archiving / PITR is configured.
Document and rehearse a full restore into a scratch environment.
Include Garage S3 bucket backup or replication for uploaded media.

Done when: a restore drill succeeds and the runbook is written.

Comments (4)

Elsama· 8 days ago
Progress: docs/BACKUP_PITR.md and backup runbook notes ship in-repo. Confirming WAL/PITR on the self-hosted Supabase host and completing a restore drill into a scratch DB remains an operator task (not app-code).
Elsama· 8 days ago
Runbook docs/BACKUP_PITR.md is in the repo. Actual restore drill + confirming WAL/offsite copies on the self-hosted Supabase VM remain operator infra - leaving Planned until a drill succeeds.
Elsama· 8 days ago
Runbook docs/BACKUP_PITR.md ships in-repo. This card stays Planned until an operator completes a restore drill into a scratch environment (infra, not app code). Overnight code path continues on product features; PITR remains operator-owned.
Elsama· 8 days ago
Hygiene: docs/BACKUP_PITR.md runbook is in the repo (operator restore drills). Live backup/PITR verification on the self-hosted Supabase host is still operator infra — keep this Planned until a restore drill is actually executed and recorded.

Join the discussion