Databasus: вернуть базу PostgreSQL на минуту до сбоя

Копия с ночи не вернёт сегодняшний день

Сбой в 15:00. Последняя копия базы снята в 03:00. Админ разворачивает её, и всё, что накопилось с утра, исчезает: заявки, оплаты, переписка в боте. Условный пример: CRM получает 20 заявок в час, с 9 до 15 набралось 120. Это прикидка, цифры у вас свои.

Бывает и хуже: в 14:20 сотрудник удалил не ту таблицу. Вчерашняя копия вернёт базу без ошибки, но и без всего сделанного за день. Нужна база на 14:19.

Это называется восстановлением на момент времени, по-английски PITR. Копии по расписанию я разбирал в статье про GoBackup, там как раз ночные дампы. Здесь речь о возврате к минуте перед бедой.

Как работает возврат на момент времени

Документация PostgreSQL описывает схему так. База записывает каждое изменение в журнал WAL. Берут физическую копию файлов базы и складывают рядом все журналы, что накопились после неё. При восстановлении копию разворачивают, PostgreSQL проигрывает журнал и останавливается там, где вы сказали: на дате и времени, на именованной точке или на номере транзакции.

Из той же документации следуют три вещи. Цепочка журналов от копии до нужного момента должна быть непрерывной, один потерянный кусок ломает всё. Возвращается кластер целиком, отдельную таблицу так не достать. Обычный дамп pg_dump для этого не годится, в нём нет данных для проигрывания журнала. На загруженной базе журналов набирается много, хранилище под них нужно считать заранее.

Что обещает Databasus и что подтверждается

Репозиторий databasus/databasus описывает проект как инструмент для самостоятельной установки с упором на восстановление на момент времени при низких RPO и RTO. Механизм расписан в README и в разделе FAQ документации на databasus.com, это работающая функция.

Полные копии делаются через pg_basebackup. Инкрементальные, где передаются только изменённые блоки, используют встроенный механизм PostgreSQL 17. Журнал WAL идёт непрерывным потоком через pg_receivewal. При восстановлении pg_combinebackup собирает каталог данных из полной копии и инкрементов, а PostgreSQL проигрывает WAL до выбранного времени. В интерфейсе есть пошаговая инструкция и готовый скрипт, по словам авторов, восстановление сводится к одной команде. Инкременты и WAL можно не включать.

Отдельно есть проверка восстановления: Databasus сам поднимает контейнер, разворачивает копию, сверяет размер и показывает список таблиц с числом строк. Для неё на сервере запускают отдельный агент проверки. Охватывает ли она физические копии с WAL, в документации прямо не сказано.

Цифр RPO и RTO авторы не называют, обещают «близкую к нулю потерю данных». На своих серверах я режим для статьи не запускал, выводы сделаны по документации.

Лицензия, возраст, установка

В файле LICENSE лежит Apache License 2.0, правообладатель Databasus, 2026 год. Лицензия разрешает коммерческое использование, в том числе установку у заказчика, при условии сохранения текста лицензии.

Репозиторий создан в июне 2025 года, раньше проект назывался Postgresus, и старые ссылки ведут на прежнее имя. На 8 октября 2026 у него около 8,8 тысячи звёзд, 548 форков и 17 открытых обращений. Последний релиз v3.60.0 вышел 22 сентября, всего за неделю с 16 по 22 сентября их было пять. Проект живой и быстро меняется: версия с агентом на сервере базы поддерживается только до 3.42.0, потом авторы перешли на удалённые копии.

Ставится скриптом на Linux, через docker run, Docker Compose или Helm. Минимум по документации: одно ядро, 500 МБ памяти, 5 ГБ диска под установку плюс место под копии, Docker 20.10 или новее. Для рабочего сервера в документации есть пример с Caddy и автоматическим HTTPS. Секретный ключ шифрования копий сохраните отдельно: без него зашифрованные копии не открыть.

Что важно учесть

Физические копии и возврат на момент времени требуют PostgreSQL 17 или новее. README перечисляет версии с 14 по 18, но FAQ уточняет, что на старых версиях доступны только логические дампы pg_dump. Если у вас 14 или 15, сначала нужен переезд на 17, и это отдельная работа.

Нужен доступ по протоколу репликации. По документации PostgreSQL для pg_receivewal требуются роль с правом REPLICATION, разрешение в pg_hba.conf и свободное место в max_wal_senders. Какие именно права нужны самому Databasus, в его документации я не нашёл. README обещает пользователя только для чтения по умолчанию, как это сочетается с физическими копиями, не выяснил. Из управляемых баз названы Amazon RDS и Google Cloud SQL, у российских провайдеров не проверено.

О нагрузке на базу авторы не пишут. Копия идёт по сети, журнал течёт постоянно, объём растёт с числом записей. Канал и хранилище стоит оценить на тестовой неделе.

Вернуть можно только весь кластер. Одну таблицу достают так: поднимают восстановленную базу рядом, выгружают нужное и переносят в рабочую. И сам Databasus нужно копировать, иначе при потере его сервера вы останетесь с зашифрованными файлами без ключа.

Что можно сделать уже сейчас

Первое. Выполните в базе SHOW server_version. Семнадцать и выше: возврат на момент времени возможен. Ниже: пока дампы, а обновление версии идёт в план.

Второе. Решите, сколько данных вы готовы потерять, в минутах, и за сколько часов базу нужно вернуть. Если честный ответ «сутки», хватит ночного дампа и ежемесячной проверки, что он открывается.

Третье. Поднимите Databasus на отдельном сервере, не на том, где живёт база, а копии кладите в другое хранилище. Включите уведомления в Telegram.

Четвёртое. Раз в месяц разворачивайте базу на момент «час назад» на отдельной машине и сверяйте с боевой. Про цену потерянных данных писали в статье о важности копий.

Мы настраиваем это под ключ: ставим, подключаем хранилище и уведомления, проводим тест восстановления и пишем памятку «что нажимать в день аварии». Это входит в услуги DevOps, ориентиры по стоимости на странице цен.

Частые вопросы

Можно ли вернуть одну таблицу, а не всю базу?

Напрямую нет, PostgreSQL восстанавливает кластер целиком. Обходной путь: поднять восстановленную копию рядом, выгрузить нужную таблицу и загрузить в рабочую базу.

Databasus заменяет ночные дампы?

На PostgreSQL 17 и новее он делает полные копии и журнал, логические дампы тоже остаются. На старых версиях дампы единственный вариант.

Сколько это стоит?

Программа бесплатная (Apache 2.0). Платить придётся за сервер и хранилище, нашу работу можно прикинуть по странице цен.

Коротко о главном

Databasus описывает рабочий механизм возврата на момент времени и собирает его из штатных утилит PostgreSQL 17. Подтверждено документацией: лицензия, установка в Docker, потоковая запись WAL, сборка и проигрывание при восстановлении. Не подтверждено: нагрузка на базу, точные права доступа, поведение у российских хостеров.

Хотите, чтобы после сбоя база вернулась на минуту до него? Напишите мне в Telegram слово «ВОССТАНОВЛЕНИЕ». Посмотрим версию вашей базы, допустимую потерю данных и соберём схему копий с тестом восстановления.