Supabase backups: what to protect and how to verify recovery
A backup is useful when you can restore what your app needs. For Supabase, that means checking the PostgreSQL backup, files stored outside the database and the recovery process. Don’t stop at seeing a backup entry in the dashboard.
Start with two recovery questions
How much recent work could you afford to lose? How long could the application be unavailable? Decide those limits before choosing how often to back up and how you’ll recover. A development prototype and an application taking customer orders usually need different answers.
List the database tables your application depends on, its uploaded files, external services and configuration. This inventory prevents a database-only restore from being mistaken for recovery of the entire product.
Understand the managed backup boundary
Check the backups available to your specific project in the dashboard. Supabase’s backup documentation explains managed backups and point-in-time recovery. Availability and retention depend on the project’s configuration and plan; verify those details before assuming a particular recovery window.
The documentation also calls out two important exclusions: database backups do not include the actual files uploaded through Storage, and custom-role passwords are not preserved in daily backups. Include separate file protection and a credential restoration procedure in your recovery plan.
Keep a portable copy when you need one
A physical backup used by the platform is different from a logical SQL export that you can download and restore elsewhere. Supabase documents logical exports when physical backups are enabled. Pick the procedure for your source and target rather than renaming a file and assuming compatibility.
Our export guide explains the difference between CSV, schema and reconstruction copies. A CSV can validate selected business records, but it does not preserve every database object and relationship required by an application.
Run an isolated recovery exercise
- Choose a separate recovery environment and document which backup you will use.
- Record the backup timestamp, application version and expected recovery point.
- Follow the provider’s restore procedure for that backup type.
- Check table presence, representative records, permissions and required extensions.
- Test application login and one complete read/write workflow using test accounts.
- Verify that uploaded objects referenced by the restored records actually exist.
- Record the elapsed time and every manual step before calling the exercise successful.
Do not run a practice restore over your only production project. When testing outbound integrations, use sandbox destinations so a recovery exercise cannot accidentally send real customer notifications or repeat a charge.
Validate business facts, not just file sizes
A large backup file can still be incomplete for your application’s purpose. Prepare a few expected facts: a known account exists, the latest expected order is present, a document opens, and an ordinary user sees only authorized records. Keep these checks free of copied customer details in public reports.
Record who can access backups, where encryption and access controls apply, and how long copies should be retained. Revisit the exercise when schema changes, authentication changes or a new storage provider make the old procedure incomplete.
Use a database viewer to inspect the recovered copy
A PostgreSQL desktop client can help inspect schemas and spot-check rows after a restore. It does not by itself establish that the whole application recovered. Use the Supabase viewing walkthrough for inspection, and keep the recovery procedure with your deployment documentation.