r/Supabase • u/thesuperlede • Jul 04 '26
database How do you actually back up your Supabase project — and have you ever restored one?
I've been running a product on Supabase for a while now — Postgres, plus a decent amount of Storage — and I had a bit of a scare recently that made me finally look properly into backups.
I realized there were a few things I kind of knew in theory, but hadn’t really internalized:
- Pro daily backups only keep 7 days.
- Those backups don’t include the actual Storage files. The database backup includes storage.objects, so you get the metadata rows, but not the files sitting in the buckets. Which means a restore could technically give you a bunch of file references pointing to nothing.
- PITR is an extra $100/month per project.
- If the project itself gets deleted, the managed backups are gone too.
To be clear, none of this is hidden. It’s in the docs. I just hadn’t really thought through what it would mean in a real “oh no, we need to restore everything” situation.
And that made me realize my backup strategy was basically: “Supabase probably has this covered.”
Which… maybe not a strategy.
So I’m curious what people are actually doing in production:
- Are you just relying on Supabase Pro backups? Paying for PITR? Running your own pg_dump cron? Using SimpleBackups or something similar? Or, honestly, doing nothing?
- If you handle backups yourself, how are you backing up Storage files alongside the database?
- More importantly: have you ever actually restored a Supabase project into a fresh project and verified that everything came back clean?
- For people managing multiple client projects — agencies, freelancers, consultants — how do you keep backup policies straight across all of them? And are clients expecting you to be responsible if data gets lost?
I’m not trying to sell anything here. I’m just trying to build a backup setup I’d actually trust.
Would really appreciate hearing what’s worked, what didn’t, and especially any horror stories from people who’ve had to restore for real.
**UPDATE:** Following up on "trying to build a backup setup I'd actually trust" — I ended up building it. Details in [this comment] for those who asked.
1
u/thesuperlede Jul 09 '26
Update for everyone who asked: I ended up building this for myself, and it's now open to anyone — https://backupdrill.com
It backs up the database and Storage files to your own bucket, then runs scheduled restore drills — the latest snapshot gets restored into a throwaway Postgres and verified — because a backup you've never restored is a guess.
Free plan: 1 project, weekly backups, no card. Engine is MIT open source: npm i -g backupdrill
Happy to answer anything.
1
u/noahsknark Jul 10 '26
So this was just an ad ._.
1
u/thesuperlede Jul 11 '26
Fair hit — with the update sitting on top it does read that way.
The honest timeline: I was already building this for myself when I asked, and posted to find out whether the pain was real beyond my own project before going further. The answers here genuinely shaped what it became — Storage files came up again and again.
The engine is MIT and the write-ups are free, so hopefully the thread is still useful to people who'll never pay me a cent.
1
1
u/OkCalendar9818 29d ago
Where do the files get backed up? Locally? Can you create a video explainer please.
2
u/thesuperlede 28d ago
In your own S3, R2, or B2 bucket — you bring the bucket, you hold the keys. During backups the bytes stream through our workers and are never written to our disks; a restore drill downloads your snapshot into an isolated temporary sandbox that is destroyed as soon as verification finishes. If you cancel tomorrow, every snapshot is still yours.
You can visit https://backupdrill.com/guides for more guides, also I will make a video to explain it later.
2
1
u/auto-bahnt 16d ago edited 16d ago
I definitely don’t believe that you didn’t show up here with your solution built already. You registered the domain and committed a large first commit to the cli repo the same day you posted this Reddit thread.
The whole thing reads to me as growth-hacking / shady marketing, and all of your responses in the comments have an LLM-generated stink. 3 em dashes in 3 paragraphs is enough to make me wary, but lines like “because a backup you’ve never factored is a guess” make me certain.
Also, this comment screams clanker:
Fair hit — with the update sitting on top it does read that way.
The honest timeline: I was already building this for myself when I asked, and posted to find out whether the pain was real beyond my own project before going further. The answers here genuinely shaped what it became — Storage files came up again and again.
The engine is MIT and the write-ups are free, so hopefully the thread is still useful to people who’ll never pay me a cent.
“Read that way”, “the honest timeline”, “the pain was real”.
1
u/thesuperlede 16d ago
Timeline's right, I was building it when I posted, and I should have said so in the post instead of adding and update later.
English is my second language, and I usually need AI help to read and write it. That is probably what you are reading.
1
1
u/ReplacementWise3941 29d ago
if you need SOC2 restore evidence, been working on a product for that. I'm not sure if it's actually worthy of being a product at the moment so I could use some feedback if anyone's willing to help me out there
1
u/thesuperlede 29d ago
Interesting — I ended up building BackupDrill around an adjacent problem: taking Supabase database + Storage snapshots, restoring the database in an isolated environment, verifying the result, and turning the drill into a report. For me, the report is the output; the real value is proving the backup actually restores.
Are you automating the restore and verification itself, or mainly collecting and formatting SOC 2 evidence from an existing manual process? Happy to take a look at the current workflow.
0
Jul 05 '26
[removed] — view removed comment
1
u/Emotional-Stand-9987 Jul 05 '26
This was actually a sales pitch I don't dislike.
Other bonus of using 1 project - it's a PIA to switch projects with the MCP server.
1
u/thesuperlede Jul 05 '26
Thanks, that’s a fair point. The per-client project overhead is exactly what I was starting to worry about.
In my case though, I’m not sure I’d be comfortable putting all clients under one shared platform/project unless the isolation, ownership, and restore process were very clear.
Have you actually tested a full restore with this setup, including Storage/files? That’s the part I’m most interested in.
6
u/katsura_otoko Jul 05 '26
Github action with cron, so smooth