Supabase backup best practices for small teams
Simple, practical rules for keeping your Supabase project safe — the 3-2-1 rule, automation, testing restores, and retention strategies that don't require a DevOps team.
Backups Without a DevOps Team
Most small teams and indie developers know they need backups but don't know where to start. The good news: you don't need a DevOps team, expensive infrastructure, or complex scripts. You need five practices.
Practice 1: Follow the 3-2-1 Rule
3
copies of your data
2
different storage media
1
copy kept off-site
For Supabase, this looks like:
- 1Your live Supabase database (production)
- 2Supabase's built-in daily backups (same vendor, same region — not off-site)
- 3Your own backup in Google Drive via Supakeep (different vendor, different region)
Without copy #3, you're violating the off-site requirement. If Supabase has a regional outage, both your database and your backups go down together.
Source: [Veeam — 3-2-1 Backup Rule](https://www.veeam.com/blog/321-backup-rule.html), [Acronis — 3-2-1 Backup Strategy](https://www.acronis.com/en/blog/posts/backup-rule/)
Practice 2: Automate Everything
Manual backups are not backups. They are good intentions.
According to IBM, 49% of data breaches involve human error. If your backup strategy requires a human to remember to run a command, it will fail when it matters most.
- Week 1
- 90% — motivated
- Week 4
- 50% — forgetting
- Week 12
- 20% — abandoned
Automation eliminates this. Supakeep runs on a schedule you set — daily, weekly, or monthly — and the dashboard shows you the status of every run.
Source: [IBM — Cost of a Data Breach Report](https://www.ibm.com/think/topics/database-security), [Konfirmity — SOC 2 Backup Guide](https://www.konfirmity.com/blog/soc-2-backup-and-recovery-for-soc-2)
Practice 3: Back Up Everything, Not Just the Database
| Component | pg_dump | Supabase Backup | Supakeep |
|---|---|---|---|
| Postgres tables & data | Yes | Yes | Yes |
| Storage objects (files) | No | No | Yes |
| Auth data | Partial | No | Yes |
| Edge Functions | No | No | Yes |
| Role passwords | No | No (documented) | Yes |
A backup that only covers the database is not a complete backup. When disaster strikes, you need the storage files, auth configuration, and edge functions too — otherwise your app comes back half-broken.
Supabase's own documentation states: "Database backups do not include objects you store via the Storage API." And "daily backups do not store passwords for custom roles."
Source: [Supabase Docs — Database Backups](https://supabase.com/docs/guides/platform/backups)
Practice 4: Test Your Restores
A backup you've never restored is a hope, not a backup. Compliance frameworks like SOC 2 and ISO 27001 require documented restore testing evidence.
- 1
Compliance minimum
Restore test every 90 days, with saved evidence.
- 2
Best practice
Monthly restore into a scratch project.
- 3
Enterprise audits
Quarterly, documented with screenshots and row counts.
The process is simple:
- 1Download a
.sql.gzbackup from your Google Drive - 2Create a fresh Supabase project (never restore to production)
- 3Run:
gunzip db_backup.sql.gz && psql "postgresql://postgres:PASS@HOST:5432/postgres" -f db_backup.sql - 4Verify row counts and key records
- 5Screenshot the results for audit evidence
See our step-by-step restore guide for the full walkthrough.
Source: [Konfirmity — SOC 2 Backup and Recovery](https://www.konfirmity.com/blog/soc-2-backup-and-recovery-for-soc-2), [ISO 27001 — Annex A 8.13](https://iso27001.com/iso-27001-annex-a-8-13-information-backup/)
Practice 5: Set Smart Retention Policies
- Daily backups
- keep 30 days
- Weekly backups
- keep 12 weeks
- Monthly backups
- keep 6 months
| Retention | Storage Cost | Recovery Window | Best For |
|---|---|---|---|
| 7 backups | Low | Last 7 days | Side projects |
| 14 backups | Medium | Last 14 days | Small SaaS |
| 30 backups | Higher | Last 30 days | Production apps |
| Unlimited | Highest | Full history | Compliance / regulated |
Supakeep lets you keep 7, 14, 30, or unlimited backups — configurable from the dashboard.
Related reading: how to restore a Supabase project from a SQL backup and the off-site restorable backup your SOC 2 auditor asks for.
Frequently asked questions
For production apps: daily minimum. For active apps with frequent writes: multiple times per day. Supakeep offers daily, weekly, and monthly schedules. The right frequency depends on your Recovery Point Objective (RPO) — how much data you can afford to lose.
Keep 3 copies of your data, on 2 different storage types, with 1 copy stored off-site. For Supabase: production database + Supabase's built-in backups + your own Google Drive backup via Supakeep.
No. Supabase's database backups only include metadata about storage objects, not the files themselves. You need a separate process to back up storage buckets. Supakeep handles this automatically.
Download your `.sql.gz` backup, create a fresh Supabase project, and restore using `psql`. Verify row counts and RLS policies. See our [restore guide](https://supakeep.io/blog/restore-supabase-from-backup) for step-by-step instructions.
For side projects: 7-14 backups. For production SaaS: 30 daily backups minimum. For compliance: 30 daily + monthly snapshots. Supakeep lets you configure this from the dashboard.
PITR (Point-in-Time Recovery) is excellent for granular recovery within Supabase's infrastructure. But it's still same-vendor, same-region. You still need an off-site copy for the 3-2-1 rule and to protect against vendor-level failures.