Database backups do not include Storage files
Supabase's backup documentation distinguishes file metadata from file contents. If an uploaded image was deleted, restoring an older database does not bring the image itself back. Treat a working database query and a working file download as separate acceptance checks.
This guide is for builders planning recovery, including apps built with Lovable or Bolt that actually use a Supabase project. First identify the real backend; do not apply Supabase dashboard instructions to a different managed service. This is an editorial checklist, not an executed recovery procedure or a promise to recover lost data.
Map the artifacts before choosing a restore
| Artifact | Documented boundary | What to record or verify |
|---|---|---|
| Database records and schema | Use an available database restore point; a Git commit is a different artifact. | Record the backup timestamp, target and tables needed. Compare known sample records after a drill. |
| Storage files | Database backups hold object metadata, not the uploaded file contents. | Keep a separate file-copy inventory. Verify sample downloads, not only rows in storage.objects. |
| Auth users versus Auth settings | Restore to a new project copies Auth user data, but Auth settings and API keys need manual setup. | Separate account records from provider configuration, redirect URLs and application secrets. |
| Functions and project services | A new-project restore requires separate setup of Edge Functions and other services. | Inventory function source, dependencies, secrets, Realtime and integrations before calling the app recovered. |
| Custom role passwords | Daily backups omit these passwords. | Assign a credential owner; do not place replacement passwords in a public recovery worksheet. |
The table combines backup limitations with new-project restore scope. It does not claim every restore method transfers the same objects. Add rows for your payment provider, email service or external search index if the app needs them. An artifact with no identified owner stays UNVERIFIED.
Choose a recovery path, not just a backup label
Existing database backup or PITR
Daily backup access is plan-dependent: Pro retains 7 days, Team 14, and Enterprise up to 30. Supabase recommends regular off-site CLI exports for Free projects. PITR is a paid add-on with finer-grained recovery points; use the recovery window actually shown in the dashboard. A restore makes the project unavailable while it runs. See current backup requirements before approval.
Write down the last known good time and its timezone. Do not assume enabling a feature today proves yesterday's state is available. Decide how to reconcile legitimate changes after the selected point; recovering one missing record should not silently discard other work.
Restore to a new project
Supabase labels this feature beta and requires a paid plan with physical backups. A new project adds costs. Most importantly, copied extensions can start external jobs immediately after restoration; they cannot be paused or excluded beforehand in this binary restore flow. A separate project is not automatically isolated from emails, webhooks or scheduled actions.
Ask the maintainer to inventory scheduled jobs, outbound requests and connected services. Do not treat a clone as a harmless drill when it could contact real customers or alter another system.
Manual logical backup and restore
The CLI guide separates database, function and Storage migration. Function downloads omit import maps and deno.json; custom auth/storage schema changes need separate review. The clone documentation points to a manual logical restore when external jobs must be inspected before running. That path does not automatically transfer the encryption root key: Vault secrets and encrypted columns require separate key handling.
These are different procedures with different prerequisites, not interchangeable buttons. This page deliberately provides no generic production restore command. A maintainer must select the procedure for the actual source, destination and encryption setup.
Before any recovery attempt
- Define the incident. Distinguish a missing record, missing file, inaccessible account and unavailable database. Record the symptom and time without assuming a cause.
- Preserve options. Avoid deleting projects or overwriting the only backup. Ask the owner how to preserve the current state without worsening the incident.
- Name the destination. Record source and target project references and who may approve writes. Do not rely on similar dashboard names.
- Collect the recovery set. Identify the database artifact, separate file copies, code revision, configuration record and secret owner. Use protected storage; do not paste credentials here or into an AI chat.
- Plan side effects and downtime. Identify external jobs, billing implications, a maintenance window and a stop decision. A technical ability to restore is not authorization to do so.
- Arrange an authorized drill. Use disposable data and a target with controlled integrations. For an actual incident, coordinate the method with the maintainer or provider support instead of experimenting on the only live copy.
What would count as evidence of recovery?
A successful restore notification is only the start of application verification. Before reconnecting users, propose checks for known records, sample file contents, ordinary-user login, cross-user access restrictions and functions with external calls disabled or controlled. Compare with your pre-incident expectations rather than accepting an empty page because it no longer shows an error.
Example: an app record references an invoice PDF. The record returning is not enough; verify the matching file can be opened by its owner and is not exposed to another user. Use a fictional document in a drill. This is a proposed test case, not a ShipStackLab test result.
- Source / target / method / approver: __________
- Incident time / selected recovery point / timezone: __________
- Database / files / configuration / code artifacts: __________
- External jobs / containment owner / estimated cost: __________
- Expected records and access / observed result / redacted evidence: __________
- Result: PASS, FAIL or UNVERIFIED — __________
- Remaining data gap / stop condition / next reviewer: __________
Keep this record privately in your project. If timestamps do not match, files are missing, keys are unavailable or side effects cannot be contained, stop and leave the outcome UNVERIFIED. A partial recovery should be described as partial, with the missing parts named.
Related decisions
Use the Supabase profile for product and version context, the migration inventory for a platform move, and the Lovable security checklist to plan user-access checks. Add recovery work and temporary infrastructure to your app budget; do not substitute a product subscription for an evidenced recovery plan.