A Supabase backup and restore checklist you can actually use

Write the restore checklist while everything still works. During an outage it should answer boring but urgent questions: who decides, which backup is safe, what gets restored first and when traffic can come back.

The Supabase recovery boundary

The moat is not another checklist of unrelated exports. It is a provider-aware recovery workflow: restore application schemas, translate Supabase-owned state safely, replay Storage and Functions through their APIs, apply supported configuration and report secrets that require a human.

This checklist deliberately covers more than the database. A Supabase application can depend on PostgreSQL, Auth, Storage objects, Edge Functions, secrets, API keys and external services. Restoring only one layer may produce a technically healthy database and a broken application.

Before an incident

• Assign an incident lead and a recovery operator. Avoid two people changing the same target.
• Define Recovery Point Objective (RPO) and Recovery Time Objective (RTO) in measurable terms.
• Record backup locations, retention, encryption ownership and emergency access procedures.
• Keep infrastructure and database migrations versioned.
• Inventory Edge Functions, secrets, Auth settings, redirect URLs, API keys and custom domains.
• Test the runbook in an isolated environment and record actual restore duration.

1. Triage and choose a recovery point

1. Stop or isolate the destructive process. A restore is wasted if a bad worker immediately corrupts it again.
2. Establish the incident time using database logs, application events and deploy history.
3. Choose the newest recovery point known to predate the incident.
4. Record the expected data-loss window and obtain the agreed business approval.

Daily backups and Point-in-Time Recovery support different recovery points. Our Supabase backups versus PITR guide explains the trade-off. A finer recovery point can reduce data loss, but it does not remove the need to validate the restored application.

2. Prepare an isolated target

• Provision a clean target with compatible PostgreSQL and extension versions.
• Block public application traffic while recovery is in progress.
• Use new credentials; do not copy leaked or suspected secrets into the target.
• Confirm there is enough database and object-storage capacity.

Prefer restoring beside production instead of overwriting it immediately. A parallel target preserves evidence, creates a rollback path and lets you test without exposing users to a half-complete system.

3. Restore PostgreSQL

• Restore roles or map ownership explicitly.
• Install required extensions before objects that depend on them.
• Treat restore errors as fatal and save the full log.
• Validate schemas, tables, sequences, functions, policies and row counts.

For custom-format dumps, PostgreSQL documents pg_restore options including single-transaction mode. An all-or-nothing restore reduces the risk of accepting a database after some statements failed.

4. Restore Supabase services around the database

Auth

Validate users and identities, then restore provider configuration, redirect URLs, templates and secrets separately. Test a real login flow with a dedicated recovery account. Counting auth rows cannot confirm that OAuth callbacks or email delivery work.

Storage

Restore the actual object bytes and compare checksums. Supabase explicitly notes that database backups contain Storage metadata, not the objects. See what Supabase backups cover and our Storage backup guide.

Functions and configuration

Deploy Edge Functions from version control and inject secrets through the approved secret store. Supabase’s restore-to-new-project guide lists services and settings that are not transferred automatically, including Storage objects and settings, Edge Functions, Auth settings and API keys, and Realtime settings.

5. Validate before cutover

• Run migrations and application startup checks against the recovery target.
• Test login, tenant isolation and representative row-level security rules.
• Create, read, update and delete a disposable domain record.
• Download private and public Storage objects and compare checksums.
• Invoke critical Edge Functions and inspect downstream side effects.
• Confirm scheduled jobs are paused or made idempotent before enabling them.

6. Cut over and retain evidence

1. Lower DNS or routing risk according to the documented cutover plan.
2. Switch traffic only after the incident lead accepts the validation report.
3. Monitor errors, latency, authentication, queues and data-integrity signals.
4. Keep the old environment read-only until the rollback window closes.
5. Store restore logs, checks, duration, differences and approvals with the incident record.

A checklist becomes trustworthy through rehearsal. Run it quarterly and after major architecture changes. Update the measured RTO, not just the prose. If the exercise takes four hours, a one-hour RTO is an aspiration rather than a capability.

ReviveDB’s Supabase disaster recovery workflow focuses on independent backups and recurring verification so this evidence exists before the incident begins.