# How to test that your Supabase backup actually restores

**URL:** <https://forum.devtalk.com/t/how-to-test-that-your-supabase-backup-actually-restores/251464>\
**Category:** Blogs/Articles/Talks/Podcasts\
**Tags:** docker, postgresql, backups, blog-post\
**Created:** [6 November 2026 17:59 UTC](https://forum.devtalk.com/t/how-to-test-that-your-supabase-backup-actually-restores/251464 "2026-11-06T17:59:12Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![super](https://forum.devtalk.com/letter_avatar_proxy/v4/letter/s/8edcca/32.png) [@super](https://forum.devtalk.com/u/super)\
**Post date:** [6 November 2026 17:59 UTC](https://forum.devtalk.com/t/how-to-test-that-your-supabase-backup-actually-restores/251464/1 "2026-11-06T17:59:12Z")

</div>

I wrote a guide on restore-testing a Supabase Postgres backup, because a truncated dump, a dump taken with the wrong role and a job that half-failed all look the same as a good backup sitting in a bucket.

The manual version takes about fifteen minutes and never connects to production:

- Start a throwaway Postgres in Docker that matches your Supabase major version, bound to 127.0.0.1 and with a fresh random password, and check readiness over TCP rather than the Unix socket.
- Create stand-ins for what a Supabase project provides (the anon, authenticated and service\_role roles and the auth.uid() / auth.jwt() helpers). Without them, a table with `default auth.uid()` never gets created, and pg\_restore carries on to the end anyway.
- Restore with `--no-owner --no-privileges`, then sort the expected sandbox errors from the real ones.
- Check the table count, that tables that should have rows aren’t empty, and `max(created_at)` to catch a job that has quietly stopped running.

It also covers running the same loop as one command with the open-source backupdrill CLI (MIT, I work on it), what a passed test does and doesn’t prove, and how often to run it.

> **[How to test that your Supabase backup actually restores](https://backupdrill.com/guides/test-supabase-backup-restore)**
>
> Three ways to verify a Supabase backup restores: a manual restore drill in Docker with working pg\_restore commands, the open-source CLI, or scheduled drills.

---

<div class="post-metadata">

**Author:** ![aicost\_tools](https://forum.devtalk.com/user_avatar/forum.devtalk.com/aicost_tools/32/8251_2.png) [@aicost\_tools](https://forum.devtalk.com/u/aicost_tools)\
**Post date:** [7 November 2026 10:15 UTC](https://forum.devtalk.com/t/how-to-test-that-your-supabase-backup-actually-restores/251464/2 "2026-11-07T10:15:47Z")

</div>

The “looks fine in the bucket” trap is real — we’ve been burned by truncated dumps that still had a plausible byte size. Matching the major Postgres version in the throwaway container is the detail most guides skip. We work on aicost.tools (editor account), so we treat restore drills as part of cost hygiene too: a backup you can’t restore is just expensive object storage. Do you also assert row counts / checksum on a couple of critical tables after restore?