Databasus: бэкап PostgreSQL с веб-интерфейсом, PITR и проверкой восстановления
Бэкап PostgreSQL, который ни разу не восстанавливали, не даёт уверенности, что данные удастся вернуть. Закон 152-ФЗ (статья 19, часть 2, пункт 7) относит к мерам защиты персональных данных их восстановление после модификации или уничтожения вследствие несанкционированного доступа, а восстановить можно только из рабочей копии.
Databasus объединяет веб-интерфейс для управления расписанием, физические копии с PITR для PostgreSQL 17+ и отдельный агент, который по расписанию разворачивает логическую копию во временном контейнере и сверяет схемы, таблицы и число строк.
Агент Databasus автоматически проверяет только логические копии. Если у вас физические копии с PITR, держите рядом логическую копию для проверки или восстанавливайте физическую цепочку вручную по расписанию.
Содержание
Копия, которую не пробовали восстановить, ещё не бэкап
Логическая копия в формате custom-dump может пройти проверку целостности pg_restore –list, но упасть на фактическом восстановлении: несовместимые расширения, права на схему, табличные пространства, которых нет на целевом сервере. С физической копией ошибка видна позже: pg_basebackup проходит, а при попытке стартовать кластер PostgreSQL отказывается применять WAL из-за пропуска в последовательности сегментов. Единственный способ отличить рабочую копию от «вроде бы рабочей» — поднимать её в изолированной среде и считать строки.
Ручной прогон восстановления раз в квартал пропускает деградацию между прогонами. База растёт, схема меняется, появляются новые таблицы, которые забыли включить в выборку, или новое расширение, которого нет на хосте восстановления. Поэтому проверка восстановления должна быть такой же плановой, как сам бэкап, и запускаться на отдельной копии СУБД той же версии. Хранение копий по правилу 3-2-1 защищает от потери носителя, но не от копии, которая не разворачивается.
Отсюда простой критерий для системы резервного копирования: если инструмент не умеет самостоятельно поднимать копию в чистом окружении и сверять содержимое, его придётся дополнять скриптами, cron и мониторингом. Databasus — попытка собрать этот контур в одном продукте с веб-интерфейсом.
Что Databasus умеет и чего не умеет
Databasus — self-hosted инструмент резервного копирования баз данных с веб-интерфейсом, лицензия Apache-2.0, платных функций нет; раньше назывался Postgresus, с версии 2.16.0 переименован, потому что проект вышел за пределы PostgreSQL. Бэкенд написан на Go, интерфейс на TypeScript, есть русская локализация, актуальная версия на момент тестов — 3.61.0. Основной источник документации — официальный сайт и репозиторий.
По PostgreSQL инструмент работает в двух режимах. Логические копии через pg_dump в custom-формате со сжатием zstd уровня 5 поддерживаются для версий с 14 по 18. Физические копии и восстановление на точку во времени (PITR) появились в версии 3.43.0 и работают только с PostgreSQL 17 и новее. Так записано в архитектурном решении проекта ADR-0008, хотя таблица версий в README относит 14–18 к обоим режимам. Для физических копий Databasus запускает штатные pg_basebackup (в том числе с флагом –incremental), pg_receivewal и pg_combinebackup, а для инкрементальных копий требует параметр summarize_wal = on на сервере. Для MySQL 5.7–9, MariaDB 5.5–13 и MongoDB 4.2–9 доступны только логические копии.
В физическом режиме не поддерживаются пользовательские табличные пространства (tablespaces), нет дифференциальных копий, delta restore и создания standby. В хранилище уходят только заполненные WAL-сегменты, поэтому возможную потерю данных задаёт параметр archive_timeout на сервере PostgreSQL, а не настройки Databasus. Если archive_timeout = 60, потеря ограничена минутой.
Шифрование — AES-256-GCM, отдельный ключ на каждую копию, выведенный из мастер-ключа secret.key. На отдельной странице документации описан сценарий восстановления без Databasus: Python-скрипт расшифровывает копию по secret.key и файлу .metadata, дальше работает обычный pg_restore.
Копии сохраняются на локальный диск, в S3 и S3-совместимые хранилища (свой endpoint, path-style или virtual-hosted-style, выбор класса хранения), Google Drive, Azure Blob, NAS, FTP, SFTP и rclone. Уведомления — Email, Telegram, Webhook, Slack, Discord, Teams, Mattermost; для Telegram с версии 3.61.0 можно указать свой Bot API-сервер или прокси вместо api.telegram.org. Для команд есть рабочие пространства, роли viewer/member/admin/owner и журнал аудита. Агент на сервере базы не нужен: Databasus подключается к ней удалённо или через встроенный SSH-туннель.
Как развернуть Databasus на отдельном сервере
Databasus разворачивается одной командой docker run; официальные требования — от 1 CPU, 500 МБ RAM и 5 ГБ диска, так что хватит небольшой виртуальной машины, например VPS в Beget. Ставить его на хост с боевой PostgreSQL не стоит: при отказе этого хоста пропадут и копии. Минимальная конфигурация — отдельный узел с собственным диском и сетевым доступом к СУБД. Варианты Docker, Docker Compose и Helm описаны на странице установки.
Для быстрого старта достаточно одного контейнера с томом под данные и пробросом порта. Мастер-ключ secret.key Databasus создаёт сам в каталоге данных. Для постоянной работы удобнее Docker Compose. В этом docker-compose.yml образ закреплён на v3.61.0, порт 4005 слушает только 127.0.0.1, а данные лежат в томе ./databasus-data:
services:
databasus:
container_name: databasus
image: databasus/databasus:v3.61.0
ports:
- "127.0.0.1:4005:4005"
volumes:
- ./databasus-data:/databasus-data
restart: unless-stopped
Публиковать порт 4005 на 0.0.0.0 не стоит: у инструмента есть доступ к продакшен-базам, а интерфейс по умолчанию защищён только логином и паролем. Надёжнее слушать только loopback и выставлять интерфейс через обратный прокси (nginx или Caddy) с сертификатом от внутреннего УЦ или Let’s Encrypt. Ограничение доступа по IP тогда тоже настраивается на прокси, там правила писать проще, чем на уровне контейнера.
При первом запуске сервер принимает регистрацию по email и паролю, почта не подтверждается, и первый зарегистрировавшийся становится администратором. По умолчанию регистрация открыта всем, кто дотянулся до интерфейса: во время тестов посторонний пользователь создал собственное рабочее пространство. Поэтому сразу после установки выключите в настройках внешнюю регистрацию (сервер начнёт отвечать «external registration is disabled»), включите двухфакторную аутентификацию для существующих пользователей и закройте прямой доступ к порту.
Если secret.key лежит только на сервере Databasus, при потере этой виртуальной машины зашифрованные копии не восстановить, даже имея S3-бакет. Поэтому ключ сразу после установки скопируйте в менеджер секретов или другое защищённое хранилище вне этого сервера. Для ручного восстановления без Databasus нужны ключ, файл .metadata и сама копия из S3.
Как настроить бэкап PostgreSQL по расписанию с хранением в S3
Бэкап PostgreSQL по расписанию в Databasus собирается из трёх частей: подключения к базе, хранилища и задания с расписанием и политикой хранения. Всё это настраивается в веб-интерфейсе, а правки на стороне PostgreSQL нужны только для физических копий.
Для бэкапов лучше сразу создать в PostgreSQL отдельного пользователя. С суперпользователем Databasus работать умеет, но при проверке подключения показывает предупреждение «Using a user with full permissions for backups is not recommended» и предлагает создать роль только на чтение — кнопка заводит пользователя с правом SELECT. Для логических копий этого достаточно. Для физических копий роли нужен атрибут REPLICATION и право на функцию pg_switch_wal(): без него проверка подключения на стенде вернула ошибку no_wal_switch_privilege. Слот репликации Databasus создаёт сам. Параметры PostgreSQL 17 для физических копий и PITR и отдельная роль для Databasus:
-- PostgreSQL 17+: параметры для физических копий и PITR
-- (wal_level применяется после перезапуска сервера)
ALTER SYSTEM SET wal_level = 'replica';
ALTER SYSTEM SET summarize_wal = 'on';
ALTER SYSTEM SET max_wal_senders = 10;
ALTER SYSTEM SET archive_timeout = 60;
-- Отдельная роль для Databasus
CREATE ROLE databasus_backup LOGIN PASSWORD 'сменить' REPLICATION;
GRANT pg_read_all_data TO databasus_backup;
GRANT EXECUTE ON FUNCTION pg_catalog.pg_switch_wal() TO databasus_backup;
-- pg_hba.conf: разрешить репликационное подключение
-- host replication databasus_backup <IP сервера Databasus>/32 scram-sha-256
Хранилище S3 добавляется с явным указанием endpoint и стиля адресации. Бакет можно взять у провайдера объектного хранилища, например S3 в Adman, или поднять своё. Список поддерживаемых хранилищ — на странице storages. При неверном ключе сервер возвращает ошибку подписи. Класс хранения S3 задаётся в настройках хранилища.
Политика хранения различается по типу копии: для логических копий есть выбор между сроком, количеством и схемой GFS (Grandfather-Father-Son — ежедневные, еженедельные, ежемесячные с разным удержанием); для физических — число цепочек и полных копий или GFS. Как отправная точка для базы среднего размера подойдёт ежедневная логическая копия с удержанием 14 дней плюс еженедельная физическая цепочка с инкрементами и удержанием двух цепочек, то есть двух недель истории с возможностью PITR.
Уведомления подключаются отдельно и привязываются к заданию. Уведомление об успешном бэкапе не говорит, что из копии можно восстановиться, поэтому задание проверки восстановления настраивается сразу вместе с заданием копирования.
Проверка восстановления ловит битые логические копии, но не физические
Проверку восстановления в Databasus выполняет отдельный агент на Go, который ставится на хост с Docker: он берёт последнюю логическую копию, поднимает временный контейнер с той же версией СУБД, восстанавливает туда копию штатным инструментом, считает схемы, таблицы и строки, удаляет контейнер и отправляет результат на сервер Databasus по HTTPS. Расписание задаётся отдельно для каждой базы, подробности — на странице restore-verification. Для физических копий проверки нет: инструмент их создаёт, но автоматически восстанавливать и сверять не умеет.
Физическая цепочка с инкрементами на базе в сотни гигабайт восстанавливается долго и требует дискового пространства кратно размеру кластера. Запрос на автоматическую проверку физических копий автор проекта пока оставил в планах (issue #808). Для PostgreSQL 17 с PITR проверку физических копий приходится делать вручную по расписанию, восстанавливая цепочку на отдельный сервер и запуская контрольные запросы.
В отчёте проверки показываются размер восстановленной базы, число схем, таблиц, строк и код выхода pg_restore. Число строк агент берёт из статистики PostgreSQL, точного COUNT(*) по таблицам он не делает. На тестовой таблице с 5 000 000 строк отчёт показал 4 999 676. Разница в 324 строки ещё не значит, что копия битая: это погрешность pg_class.reltuples, которую обновляет ANALYZE. По отчёту видно, что копия восстанавливается и в каком объёме, но точное совпадение данных по нему не проверить.
Токен подключения агента к серверу Databasus хранится в конфиге открытым текстом и виден в списке процессов на хосте. На недоверенной машине его легко вытащить, поэтому агент имеет смысл ставить только на хост, где и так есть доступ к базам и бэкапам. Удобный вариант — отдельная виртуальная машина под проверку восстановления с минимальными правами и без лишних сервисов.
Агент находит дамп, который создаётся, но не разворачивается: расширение есть в источнике и нет в целевом контейнере, конфликтует роль владельца, пропала схема. Такие ошибки всплывают на следующем запуске агента, до аварии. Поэтому даже на базах с PITR стоит держать логическую копию, которую агент проверяет автоматически.
Проверили на тестовом стенде: время, объём, восстановление
На тестовом стенде 19 октября 2026 года Databasus 3.61.0 отработал полный цикл резервного копирования PostgreSQL 17.11 в S3-совместимое хранилище SeaweedFS на базе 995 МБ, восстановление прошло без расхождений по контрольным суммам. Окружение собрано в Docker на одном сервере, тестовая база — pgbench на 755 МБ плюс таблица со случайными данными, после замеров стенд удалён.
Логическая копия базы 995 МБ с шифрованием AES-256-GCM заняла 14,2 с и уложилась в файл 209,9 МБ. Основную часть файла дали 250 МБ случайных данных, которые почти не сжимаются; данные pgbench сжимаются сильнее, и на чистом pgbench размер копии был бы непоказательным. Память самого Databasus в простое держалась на уровне 112 МБ, во время создания копии поднималась до 214 МБ. Восстановление в заранее созданную пустую базу прошло за 19,6 с; число строк и контрольные суммы по таблицам совпали с исходной базой. Проверка подключения к S3 прошла за 0,21 с.
Проверка восстановления через агент отработала за 36,9 с вместе с первой инициализацией — большую часть времени занял разовый pull образа PostgreSQL для проверки размером 1,13 ГБ, само восстановление заняло 12 с. Отчёт показал размер 994,85 МБ, 1 схему, 5 таблиц, код выхода pg_restore 0 и число строк по каждой таблице. Временный контейнер после проверки удалён штатно.
Физическая копия кластера 2 ГБ на PostgreSQL 17 заняла 24,3 с и 444,6 МБ, инкрементальная после минуты нагрузки — 3,7 с и 28,4 МБ. Databasus сам создал слот репликации и запустил pg_receivewal. PITR реализован в два шага: интерфейс выдаёт одноразовую ссылку, действующую 15 минут, и команду для скрипта восстановления (есть также ручная инструкция из 7 шагов). Скрипт с целевым временем отработал за 36 с, PostgreSQL 17 вышел из восстановления за 4 с, удалённые после точки T1 данные вернулись, контрольные суммы совпали со снимком на момент T1.
Скрипт восстановления PITR для кластера 2 ГБ занял 5,8 ГБ временного места на диске и промежуточные файлы сам не удаляет. На крупной базе места может не хватить посреди восстановления, поэтому закладывайте под него минимум втрое больше размера кластера.
Восстановление без Databasus тоже проверили: Python-скрипт с официальной страницы расшифровал копию из S3 за 0,5 с, pg_restore отработал за 13,3 с, данные совпали. Крупные копии хранятся частями .part000001 с манифестом .parts. На странице это не описано, но влияет на ручное восстановление.
Что сознательно не проверяли: совместимость с Postgres Pro, Tantor, Jatoba и сборками PostgreSQL для 1С, работу на базах в сотни гигабайт, конкретные российские облачные S3. Результаты по SeaweedFS не переносятся напрямую на другие S3-реализации — там будут свои задержки и свои ошибки подписей.
Databasus, pgBackRest, WAL-G или pg_probackup: что выбрать для бэкапа PostgreSQL
Выбор инструмента для бэкапа PostgreSQL зависит от трёх вещей: нужен ли веб-интерфейс и командная работа, какие версии PostgreSQL используются и есть ли tablespaces, нужны ли дифференциальные копии, delta restore и standby. Веб-интерфейс и командную работу Databasus даёт полностью, а по версиям, tablespaces, дифференциальным копиям, delta restore и standby уступает классическим инструментам.
pgBackRest остаётся самым полным инструментом для физических копий PostgreSQL. Он поддерживает полные, дифференциальные и инкрементальные копии, delta restore (восстанавливает только изменившиеся блоки), параллельное восстановление, standby и работает со всеми актуальными версиями PostgreSQL. Интерфейса нет, конфигурация через ini-файлы, уведомления и расписание — внешними средствами. Это выбор, когда база измеряется сотнями гигабайт или терабайтами, нужны пользовательские tablespaces и максимально быстрое восстановление. Документация — pgbackrest.org.
WAL-G — лёгкий инструмент на Go, который работает на самом сервере базы, умеет сжатие (brotli, zstd, lz4), шифрование, PITR, передачу копий напрямую в S3 и совместимые хранилища. По сравнению с pgBackRest проще в настройке и не требует отдельного репозитория копий. Хорошо подходит, когда весь инструментарий — командная строка и ansible-роли, а веб-интерфейс не нужен. pg_probackup от Postgres Professional — выбор, когда СУБД Postgres Pro: инструмент поддерживается вендором и умеет инкрементальные копии. Barman работает с централизованным репозиторием копий PostgreSQL и тоже управляется из командной строки.
Из этого списка только у Databasus есть веб-интерфейс, поддержка нескольких СУБД, командная работа и встроенная проверка восстановления. Проект молодой и в основном развивается одним разработчиком; риск единственного мейнтейнера частично компенсируют лицензия Apache-2.0 и описанный путь восстановления без самого Databasus. Похожую задачу — централизованные копии нескольких СУБД на одном дашборде — мы решали другим инструментом в кейсе с Portabase.
База до нескольких десятков гигабайт, нужен веб-интерфейс и команда без выделенного DBA, PostgreSQL 14–18 без tablespaces — подойдёт Databasus. База сотни гигабайт и больше, PostgreSQL старых версий, нужны tablespaces, standby и дифференциальные копии — pgBackRest. Весь контур на командной строке, базы разного размера, важен лёгкий инструмент под S3 — WAL-G. Postgres Pro — pg_probackup. Для 1С с PostgreSQL любой из инструментов сначала проверьте на тестовой базе: ни один не гарантирует работу со всеми патчсетами 1С.
Итог
- Databasus подходит базам на PostgreSQL 14–18 без tablespaces, которым нужен веб-интерфейс; PITR — только с PostgreSQL 17.
- Агент автоматически проверяет только логические копии, поэтому даже на базах с PITR держите логическую копию.
- Число строк в отчёте проверки берётся из статистики PostgreSQL и точную сверку данных не заменяет.
- secret.key храните вне сервера Databasus: без него копии не расшифровать.
- Под восстановление PITR закладывайте на диске втрое больше размера кластера: скрипт не удаляет промежуточные файлы.
Часто задаваемые вопросы
Чтобы создать логическую копию, подключите базу через веб-интерфейс Databasus, выбрав пользователя с правом SELECT. Инструмент выполнит pg_dump в custom-формате со сжатием zstd уровня 5. Физические копии и PITR доступны только для PostgreSQL 17+, для инкрементальных копий нужен параметр summarize_wal = on. Копии можно шифровать AES-256-GCM, они отправляются в выбранное хранилище (S3, локальный диск и др.) по настроенной политике хранения.
Логическую копию можно восстановить через интерфейс Databasus в заранее созданную пустую базу данных. Для PITR (восстановления на точку во времени) Databasus выдаёт одноразовую ссылку и скрипт восстановления, который применяет WAL-архивы к базовой физической копии. Восстановить копию можно и без Databasus: официальный Python-скрипт расшифровывает файл по ключу secret.key и файлу .metadata, дальше работает pg_restore или штатные средства PostgreSQL для кластера.
У Databasus есть веб-интерфейс, встроенная проверка восстановления в изолированном контейнере и поддержка MySQL, MariaDB и MongoDB. pgBackRest работает через командную строку и умеет то, чего нет в Databasus: дифференциальные копии, delta restore, tablespaces, старые версии PostgreSQL. WAL-G — лёгкий консольный инструмент на сервере базы с отправкой копий прямо в S3. Databasus подходит базам до нескольких десятков гигабайт на PostgreSQL 14–18 без tablespaces, где нужен веб-интерфейс.
Да, если копия secret.key лежит вне сервера Databasus. Без secret.key копии AES-256-GCM не открыть ни штатно, ни вручную. Если сервер утерян, копии расшифровывает официальный Python-скрипт по сохранённому secret.key и файлу .metadata.
Официально нет: документация совместимость с Postgres Pro, Tantor, Jatoba и сборками PostgreSQL для 1С не подтверждает, в наших тестах мы её не проверяли. Databasus поддерживает стандартный PostgreSQL 14–18. Перед использованием в инфраструктуре 1С нужно тестовое развёртывание и проверка данных после восстановления: у сборок для 1С могут отличаться расширения и права доступа.
Константин Тютюнник — основатель и инженер IT For Prof. Сопровождает корпоративную ИТ-инфраструктуру российского бизнеса: серверы, почтовые системы, мониторинг, корпоративные мессенджеры и платформы вроде Битрикс24. Делится практикой импортозамещения и self-hosted-решений в блоге и GitHub-организации IT-for-Prof. В рубрике об инфраструктуре пишет о серверах, виртуализации, резервном копировании и VPN. Кейс по теме: Pulse для Proxmox: подняли мониторинг 6-нодового кластера за день — что нашёл Pulse Patrol на первой неделе.
Если резервные копии PostgreSQL у вас есть, но восстановление из них не проверяли, поможем: внедрим Databasus или подберём другой инструмент под ваши базы и настроим регулярную проверку восстановления. Эта работа входит в администрирование серверов.
