Три способи зробити резервну копію бази Supabase, і чого бракує

Кожен, хто будує на Supabase, зрештою ставить те саме запитання, зазвичай десь за тиждень після запуску і зазвичай о другій ночі: якщо я щось зламаю, чи поверну свої дані?

Відповідь цілком залежить від того, який із трьох шляхів ви обрали, і кожному з них бракує того, що покривають два інші.

Який із них обрати?

Увімкніть те, що дає ваш тариф Supabase, а потім тримайте копію деінде. Це дві різні справи, і зробити лише першу означає припуститися саме тієї помилки, заради якої написано цю статтю.

Копія з панелі захищає вас від ваших власних помилок. Копія, яку тримаєте ви, захищає від втрати акаунта: невдалого списання, призупиненого проєкту, пароля, який не вдається відновити. Це різні катастрофи, і вони потребують різних відповідей.

Що насправді міститься в резервній копії

Ваші таблиці, ваші рядки, ваші індекси й функції та ваші правила Row Level Security, тобто політики, які вирішують, хто що може читати, а не лише таблиці, до яких вони застосовуються. Оце й усе.

У ній немає всього того, що ніколи не було в базі:

Люди найчастіше спотикаються на Storage. Кожен аватар, кожен завантажений PDF, кожне зображення, яке додали ваші користувачі, живе в об'єктному сховищі, а не в базі. База тримає лише шлях до кожного файлу. Відновіть копію бази в порожній проєкт, і ви отримаєте таблицю, повну посилань на файли, яких там немає.

Шлях 1: панель Supabase

Найпростіший, і той, який більшості варто увімкнути першим. Supabase робить щоденні копії на платних тарифах, а відновлення на конкретний момент часу доступне як надбудова, якщо потрібно відмотати до певної хвилини, а не до минулої півночі.

У чому він добрий: працює без вас, він повний, а відновлення займає кілька кліків в інтерфейсі, а не команду, яку треба ввести правильно під тиском.

Чого йому бракує: копія лежить усередині акаунта. Якщо проєкт призупинено, якщо не пройшла прив'язана картка або ви втратили доступ до входу, копії опиняються за тими самими дверима, що й те, що вони мали захищати. Це пожежний вихід усередині будівлі.

До того ж на безкоштовному тарифі його немає взагалі, а саме там і сидить більшість щойно запущених застосунків.

Від того, на якому ви тарифі, залежить, чи є це у вас узагалі, а перевірка займає дві хвилини.

Шлях 2: pg_dump на вашій власній машині

Supabase працює на Postgres, тож стандартний інструмент Postgres підходить. pg_dump записує всю базу у файл, який тримаєте ви.

pg_dump "postgresql://…ваш рядок підключення…" \
  --clean --if-exists --no-owner \
  --file backup-2026-08-09.sql

У чому він добрий: безкоштовний, повний, файл ваш, і ви можете відновити його в цілком новий проєкт на іншому акаунті. З трьох шляхів це єдиний, який переживає втрату всього іншого.

Чого йому бракує: він стається лише тоді, коли ви про нього згадаєте. Це не дрібниця, це і є вся вада. Дамп на вашому ноутбуці має дату того дня, коли ви востаннє про нього подумали, а день, коли він потрібен, ніколи не буває днем, коли ви про нього думали.

Є й друга, тихіша проблема: неперевірений дамп лишається здогадом. Файл, записаний тоді, коли міграція була застосована наполовину, або мовчки обрізаний через розрив з'єднання, виглядає точнісінько як добрий, аж до дня, коли ви спробуєте ним скористатися.

Шлях 3: керовані резервні копії

Щось інше знімає копію за розкладом, кладе її поза вашим акаунтом і перевіряє, що копія справжня, перш ніж вважати справу зробленою. Саме ця остання частина справді має значення.

Саме це робить Reeve Care: кілька копій на день залежно від тарифу, зашифрованих і збережених поза вашим акаунтом Supabase, кожна перевірена підрахунком того, що вийшло, проти того, що зайшло. Копія зараховується як зроблена лише після перевірки, і тому в панелі показано дату останньої перевіреної копії, а не останньої спроби.

Чесний компроміс: це коштує грошей і це ще один сервіс у вашому стеку. Якщо вам вистачає дисципліни вести шлях 2 за справжнім розкладом і перевіряти відновлення, він вам не потрібен.

Увесь цикл показано на сторінці резервних копій Supabase: копія виходить із Supabase, потім перевірка, а потім кнопка, яка повертає все назад.

Чи ви бодай раз робили відновлення?

Це запитання вирішує, чи є у вас резервна копія, чи файл, який ніхто ніколи не відкривав. Дамп, який ніхто не прочитав назад, лишається здогадом про майбутнє, і мить, коли ви дізнаєтеся, що він був хибним, і є тією миттю, коли він мав бути правильним.

Перевірка відновлення не має бути драматичною. Створіть новий проєкт Supabase, завантажте в нього найсвіжішу копію, відкрийте застосунок проти цього проєкту й подивіться, чи є там рядок, який ви впізнаєте. Пів години, раз на квартал. Якщо відновлення провалиться, ви дізнаєтеся про це у вівторок по обіді, а не посеред збою.

Якщо потрібен ширший перелік того, що варто перевірити у щойно запущеному застосунку, 10-хвилинний чеклист безпеки охоплює резервні копії разом з рештою, а посібник із безпеки Supabase проходить по тому, що ще зазвичай лишається відкритим.

Що зробити цього тижня

Варто прочитати далі: якщо ви вважали, що скасування у вашому білдері охоплює й дані, історія версій не є резервною копією варта прочитання першою. Після цього: ваша база даних настільки приватна, наскільки приватні ключі перед нею, і які ключі API безпечні у фронтенді розповідає про той, що обходить кожне правило, яке ви задасте.