Backup and DR architecture
Current provider capability
- Supabase documentation states that Pro projects receive automatic daily database backups with access to the last 7 days of backups.
- Point-in-Time Recovery is a separately enabled add-on for Pro, Team, and Enterprise projects.
- Database backups contain object metadata but do not restore deleted Storage objects.
- Cloudflare Pages can roll production back to a previous successful production deployment.
Recovery boundaries
Frontend rollback, database restore, object recovery, serverless deployment, configuration, and third-party reconciliation are separate actions. Restoring one plane does not restore the others. Supabase warns that a database restore causes project downtime; duration depends on database size.
Required recovery sequence
- declare and classify the incident;
- stop unsafe writes and preserve evidence;
- identify affected release, data, objects, configuration, and providers;
- select an authorised rollback or restore point;
- communicate expected downtime and data-loss window;
- execute provider recovery through authorised administrators;
- validate authentication, tenant isolation, critical workflows, audit history, and integrations;
- reconcile missing or duplicate external transactions;
- document actual recovery time and recovery point;
- complete a post-incident review.
Recovery runbook by plane
| Plane | Recovery source | Recovery action | Mandatory validation |
|---|---|---|---|
| Frontend release | Previous successful immutable Cloudflare deployment | Move production traffic to the selected deployment | Routes, asset loading, authentication entry, public configuration, and critical browser workflow |
| PostgreSQL | Supabase daily backup or separately enabled point-in-time recovery | Authorised in-place restore to the selected recovery point | Schema version, identity linkage, tenant isolation, constraints, recent critical records, and application compatibility |
| Storage objects | Independent protected copy, version, or provider-supported object recovery mechanism | Restore object bytes and reconcile ownership metadata | Object hash or size, business purpose, owner, access policy, and application retrieval |
| Trusted functions | Approved source revision and deployment record | Redeploy the compatible serverless release and protected configuration | Authentication, authorization, secrets, provider calls, callback handling, and scheduled execution |
| Configuration and secrets | Approved provider configuration record and secret custody process | Reapply configuration and rotate exposed or uncertain credentials | No secret in public output, successful provider authentication, predecessor revocation, and monitoring |
| External transactions | Provider statement, callback, or status evidence | Reconcile payments, messages, calls, quotes, and other effects across the outage window | No duplicate side effect, missing terminal state, or unexplained financial difference |
Business owners assign recovery objectives by service rather than copying provider backup retention into every workflow. The approved matrix records maximum tolerable outage, maximum tolerable data loss, peak-period dependency, manual workaround, recovery owner, validation owner, and escalation threshold. A timed exercise records achieved recovery time and the actual recoverable point.
Limitations
The Pro-plan entitlement is documented, but this review did not establish the current backup list, PITR enablement, object-backup mechanism, approved RPO/RTO, recovery owners, or a completed restore exercise. Provider entitlement is recorded as backup capability, not as tested recoverability.