-
-
Notifications
You must be signed in to change notification settings - Fork 259
Open
Labels
bugSomething isn't workingSomething isn't working
Description
Currently, Supabase automated backups (and Point-In-Time Recovery) only back up the Postgres database. The Supabase Storage (buckets and objects) are not included in these backups. This creates a serious integrity issue between the database and storage, since restoring a database backup will not restore the corresponding state of files in Storage.
Problem
- When restoring from a database backup or using PITR, the storage.objects table reflects metadata from a past point in time, but the actual files in the storage bucket reflect the current state. This mismatch can lead to:
- Broken links or missing files referenced in the restored database
- Orphaned files in buckets that no longer exist in the restored metadata
- Data integrity issues for any app relying on synced database–storage relationships
- Difficulty in disaster recovery or environment rollback
Proposed Solution
- Add Storage backups that are automatically:
- Included in the same backup cycle as database backups
- Point-in-time consistent with the database snapshot (for PITR-enabled projects)
- Restorable alongside database recovery, ensuring data and file integrity
Benefits
- Data integrity: Ensures database and storage remain in sync after restoration
- Reliable recovery: Enables full environment recovery to a consistent past state
- Developer confidence: Reduces risk of corruption or missing assets after restores
- Enterprise readiness: Aligns Supabase with best practices for complete backup solutions similar to AWS RDS + S3 versioned backups
Optional Enhancements
- Ability to selectively restore storage buckets to a specific point in time
- Integration with existing PITR timelines for seamless rollback
- Option to enable versioned or incremental backups to optimize costs
Metadata
Metadata
Assignees
Labels
bugSomething isn't workingSomething isn't working