ReviveDB проверяет резервную копию Supabase, восстанавливая её во временную базу PostgreSQL и сравнивая с исходной структурой. По описанию сервиса, только после этого копия получает статус проверенной.
Сервис сохраняет копию проекта Supabase на Postgres 17 вне Supabase, затем восстанавливает каждую копию базы во временный PostgreSQL. По заявлению разработчика, копия считается проверенной после восстановления и сравнения с исходным перечнем объектов.
Подход описан в сообщении ReviveDB от 28 октября. Это анонс отдельного коммерческого продукта в разделе Related Proprietary на сайте PostgreSQL. Он не является независимым испытанием сервиса или новой встроенной функцией самого PostgreSQL.
Практический вопрос правильный: файл копии может существовать, но пригодность восстановления нужно подтвердить отдельной операцией.
В анонсе перечислены таблицы, строки, столбцы, ограничения, индексы, последовательности, представления, функции, триггеры, политики доступа, права и расширения. Разработчик отдельно отмечает, что одного количества строк недостаточно, чтобы заметить потерю ограничения или правила доступа.
Например, приложение может получить прежний набор таблиц, но перестать правильно выдавать записи разным пользователям. Поэтому структура и права важны вместе с данными.
При этом описание не следует читать как гарантию работы любого приложения после любого сбоя. Нужно знать, какие проверки выполнил сервис, какие объекты не поддержаны и что осталось за пределами отчёта.
Для каждого запуска сервис использует собственную короткоживущую роль PostgreSQL с доступом только на чтение, включая строки за правилами RLS. В той же точке восстановления, по описанию ReviveDB, хранятся данные Auth, файлы Storage и Edge Functions.
RLS — правила, которые определяют доступ к отдельным строкам базы. Роль, способная читать скрытые ими записи, получает существенный объём данных. Перед подключением нужно разобраться, где они хранятся и как ограничен доступ со стороны сервиса.
Проверка восстановления базы не означает автоматически одинаковую глубину проверки всех остальных частей проекта. Разницу между хранилищем, входом пользователей и внешними подключениями разбираем в статье о зависимостях сайта.
Восстановите проект в отдельную копию и пройдите несколько важных действий приложения: вход, чтение учебной записи, проверку прав и открытие нужного файла. Затем сравните полученный результат с заранее записанным ожиданием.
Наш пример — два учебных пользователя с разными правами. После восстановления каждый должен видеть свои записи; существование обеих строк в базе само по себе этого не доказывает. Рабочую базу для такой первой проверки менять не требуется.
ReviveDB описывает восстановление в новый проект либо в исходный после репетиции на копии. Для владельца важны ещё время возвращения в работу и свежесть восстановленных данных. Как задать эти требования без путаницы между целью и замером, есть в объяснении RTO и RPO. Сам сервис мы к рабочему проекту не подключали.
