Supabase backup: protect database, Storage and configuration

Need Supabase operations with separate database and Storage protection? WZ-IT provides managed Supabase hosting and operations with monitoring, backup design and controlled updates.

A Supabase backup must make several data planes recoverable together. PostgreSQL contains tables, Auth data and metadata. The actual Storage file bytes sit outside the database backup. Functions, secrets, SMTP and infrastructure configuration also need their own procedures.

The key question is not “Did the dump run?” but: Can the complete application return to a consistent state within the agreed time?

Which Supabase components need protection?

A complete backup does not have to contain every secret in plain text. It does need to explain how secrets are securely restored or rotated during recovery.

Define RPO and RTO first

Recovery Point Objective (RPO) specifies the maximum acceptable data loss. Recovery Time Objective (RTO) sets the maximum acceptable time to restore service.

Examples:

• An RPO of 24 hours may permit a daily backup.
• An RPO of 15 minutes commonly needs WAL archiving or comparable PITR.
• An RTO of eight hours permits more manual steps.
• An RTO of 30 minutes requires prepared infrastructure, automation and tested timings.

RPO and RTO apply to the application, not PostgreSQL alone. If the database returns in 20 minutes but Storage files need six hours, the application RTO has not been met.

Logical, physical and point-in-time recovery

Logical backups export database objects and data. They are portable and useful for migrations or selective recovery, but can take a long time for large databases.

Physical backups protect state closer to the underlying database files. They can restore faster but are more tightly coupled to version and operating model.

Point-in-time recovery (PITR) combines a base backup with a continuous transaction log, allowing recovery just before a harmful change.

An operating design may combine methods: daily logical exports for portability and physical protection or PITR for shorter objectives.

Protect Storage objects separately

Supabase documentation explicitly states that database backups do not include objects stored through the Storage API. Capture:

• every bucket and object path
• files and sizes
• content types and relevant metadata
• versions where supported by the storage target
• the relation to metadata rows in PostgreSQL

Database and object state need to match during recovery. New database metadata with old files, or the reverse, can produce missing and orphaned objects.

Maintain database and Storage consistency

Strict consistency may require a short write pause during a complete backup. Other systems accept a documented time offset and reconcile afterwards.

Useful controls include:

• object count per bucket
• total file sizes
• checksums for critical files
• samples through the Storage API
• comparison of metadata and actual objects
• tests of private and signed downloads

Apply the 3-2-1 principle

A robust starting point is:

• at least three copies of relevant data
• on at least two different storage types or systems
• at least one copy separated from the primary environment

Production designs should also provide:

• encryption in transit and at rest
• separate credentials
• immutable or deletion-protected retention
• defined daily, weekly and monthly generations
• monitoring of age, size and success

A backup on the same host with the same administrator access only covers part of the risk.

Auth and secrets during recovery

Auth data may reside in PostgreSQL. A working login also needs:

• compatible JWT configuration
• Auth providers and OAuth credentials
• correct redirect URLs
• SMTP and email templates
• DNS and public domains
• secrets for Functions and webhooks

Changing JWT secrets may invalidate existing sessions. The recovery runbook must state whether old keys are restored or users sign in again.

Recovery tests instead of backup trust

A green backup job proves only that a process ended without a reported error. A recovery test answers:

1. Can backups be located and decrypted?
2. Will PostgreSQL start on the target version?
3. Do Storage files match their metadata?
4. Do Auth, RLS and Functions work?
5. Can the application complete critical user journeys?
6. Are RPO and RTO achieved?

Run tests in isolation so they cannot overwrite production or accidentally send email and webhooks.

Monitoring and ownership

At minimum, monitor:

• last successful run
• age of the newest recovery point
• backup size and unexpected deviations
• free capacity and retention
• upload or encryption failures
• date, outcome and duration of the latest recovery test

Every alert needs an owner and response rule. Otherwise backup automation becomes unattended storage consumption.

Sources

• Supabase: database backups
• Supabase: self-hosting
• Supabase: transfer Cloud to self-hosted
• PostgreSQL: backup and restore