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

Ответы на самые частые вопросы о Databasus: установка, конфигурация и стратегии резервного копирования.

Почему Databasus не использует формат сырого SQL-дампа для логических бекапов PostgreSQL?

Для логических бекапов Databasus использует формат custom утилиты pg_dump со сжатием zstd уровня 5 вместо обычного SQL-формата, потому что он дает лучший баланс между:

  • Скоростью создания бекапа
  • Скоростью восстановления
  • Размером файла (до 20 раз меньше, чем обычный SQL-формат)

Это решение принято после обширного тестирования и бенчмарков разных форматов бекапов PostgreSQL и методов сжатия. Подробнее о тестировании можно прочитать здесь: PostgreSQL backups: comparing pg_dump speed in different formats and with different compression.

Databasus не будет добавлять формат сырого SQL-дампа, потому что:

  • лишнее разнообразие вредит UX;
  • дополнительный формат усложняет поддержку кода;
  • текущий формат дампа покрывает 99% случаев

Куда ставится Databasus при установке через .sh-скрипт?

Databasus устанавливается в каталог /opt/databasus/.

Как работают физические и PITR-бекапы (Point-in-Time Recovery)?

Databasus выполняет физические бекапы удаленно со своего хоста, подключаясь к вашему PostgreSQL по стандартному протоколу репликации, поэтому на сервер базы данных ничего устанавливать не нужно. Если база живет в закрытой сети, Databasus может добраться до нее через SSH-туннель к внутреннему хосту или бастиону, так что базу не придется открывать наружу.

Почему это стало возможным: годами инструменты вроде pgBackRest и WAL-G строили собственные движки инкрементальных блочных бекапов, потому что у PostgreSQL не было родного. Все изменилось с PostgreSQL 17, где эту функциональность разработал Robert Haas при участии David Steele, автора pgBackRest. Теперь PostgreSQL сам поставляет серверные блочные инкрементальные бекапы (pg_basebackup --incremental и summarize_wal), и Databasus строится на них, а не изобретает свои.

Как работают бекапы:

  • Полные бекапы создаются через pg_basebackup и передаются напрямую в Databasus
  • Блочные инкременты используют pg_basebackup --incremental: серверные WAL-сводки PostgreSQL 17 (summarize_wal = on) отслеживают изменения, поэтому передаются только измененные блоки
  • WAL передается непрерывно через pg_receivewal, чтобы цепочка восстановления между бекапами оставалась полной
  • Физические бекапы требуют PostgreSQL 17 или новее; на более старых версиях используются логические бекапы через pg_dump

Как работает восстановление:

  • pg_combinebackup собирает работоспособный каталог данных из полного бекапа и цепочки инкрементов
  • Затем PostgreSQL проигрывает WAL до выбранного вами целевого времени, восстанавливаясь на любую секунду между бекапами
  • После запуска PostgreSQL завершает восстановление, становится первичным сервером и возвращается к обычной работе

Делать это вручную не обязательно. Интерфейс Databasus дает пошаговые инструкции для восстановления на хост или в Docker-базу: либо готовым скриптом, либо ручным скачиванием бекапов. Мы подготовили скрипт так, что восстановление — это одна команда, но при желании вы можете собрать цепочку из полных, инкрементальных и WAL-частей сами. Инкременты и WAL тоже опциональны: можно снимать только полный бекап, без инкрементов, и WAL не обязателен.

Почему мы используем родные бекапы PG 17:

  • Они переиспользуют собственный механизм резервного копирования PostgreSQL вместо его переизобретения — вы получаете проверенные временем внутренности с тысячами тестов и учтенных граничных случаев
  • Они работают с удаленными базами, включая управляемые сервисы вроде Amazon RDS и Google Cloud SQL, которые открывают протокол репликации, но запрещают установку ПО на хост
  • Они дают почти нулевую потерю данных: восстановиться можно на любую секунду между бекапами

Почему Databasus отказался от бекапов через агент?

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

Почему агент был неверным подходом:

  • Это была наивная реализация, которая лишь копировала WAL поверх полных бекапов, что приводило к долгому RTO
  • Пользователям приходилось настраивать и Databasus, и отдельный агент, хотя делать все удаленно из одного места намного проще
  • Поскольку агент жил вне основной системы, было трудно покрыть все тестовые случаи
  • По сути агент решает только одну задачу: доступ к базе, недоступной снаружи. Для 99% пользователей это уже решается запуском Databasus внутри приватной сети или подключением по SSH, так что агент изобретал колесо и делал простую задачу сильно сложнее, чем нужно
  • Он не мог работать на управляемых базах вроде RDS и Cloud SQL, которые запрещают установку на хост, но уже открывают протокол репликации, поэтому удаленный путь был нужен в любом случае
  • Еще он тянул за собой много граничных случаев. Разрывы соединений, обновления агента и сбор логов из отдельного процесса были болезненными, а чем меньше движущихся частей в системе, тем надежнее она в повседневной работе

Мы позаботились о сохранности существующих бекапов. Если вы обновляетесь с версии, где еще есть агентские бекапы, Databasus не удалит их молча: он предупредит об изменении и даст выбор — остаться на поддерживаемой версии 3.42.0 или удалить старые агентские бекапы самостоятельно перед обновлением. Реализация на агенте остается доступной до версии 3.42.0 и будет работать еще долго, так что ничего не сломается.

Полную аргументацию можно прочитать в архитектурных решениях: ADR-0008: родные бекапы PG17 с обязательной WAL-сводкой и ADR-0009: удаленные физические бекапы вместо агентов.

Как ИИ используется в разработке Databasus?

В ишью и обсуждениях спрашивали, как в разработке проекта используется ИИ. Поскольку проект сосредоточен на безопасности, надежности и продакшен-использовании, важно объяснить, какое место ИИ занимает в процессе разработки.

ИИ используется как помощник для:

  • Проверки качества кода и поиска уязвимостей
  • Чистки и улучшения документации, комментариев и кода
  • Помощи во время разработки
  • Перепроверки PR и коммитов после ревью человеком

ИИ НЕ используется для:

  • Написания всего кода
  • Подхода «вайб-кодинга»
  • Кода без построчной проверки человеком
  • Кода без тестов

У проекта есть:

  • Серьезное тестовое покрытие (и юнит-, и интеграционные тесты)
  • Автоматизация CI/CD с тестами и линтингом для контроля качества кода
  • Ревью разработчиков с опытом крупных проектов с высокими требованиями к безопасности

Так что ИИ — лишь ассистент и инструмент, который помогает разработчикам работать продуктивнее и следить за качеством кода. Работу делают разработчики.

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

Даже написанный вручную код не гарантированно попадет в проект. Вайб-код не допускается вовсе, и все такие PR по умолчанию отклоняются (см. руководство по контрибуциям).

Мы также стараемся быстро разбирать проблемы и сообщения об уязвимостях.

Как забекапить сам Databasus?

Если вы хотите забекапить свой инстанс Databasus (включая все конфигурации, базы и учетные данные), сделайте следующее:

  1. Зайдите в /opt/databasus (или папку, куда вы установили Databasus)
  2. Перейдите в каталог databasus-data

Забекапить нужно:

  • secret.key — ключ шифрования ваших учетных данных
  • /pgdata — внутренняя база PostgreSQL самого Databasus со всеми конфигурациями и метаданными бекапов

Если вы храните бекапы в локальном хранилище, можно забекапить и папку backups.

Важно: есть два разных сценария восстановления:

  • Восстановить бекапы без интерфейса Databasus: бекапы баз можно восстановить с одним лишь файлом secret.key, без самого Databasus и его внутренних данных. Подробные инструкции — в руководстве по ручному восстановлению.
  • Восстановить интерфейс Databasus со всеми конфигурациями: чтобы вернуть интерфейс Databasus со всеми конфигурациями, расписаниями и историей бекапов, нужно забекапить и secret.key, и папку /pgdata (в ней лежат метаданные шифрования и все конфигурации Databasus).

Чтобы восстановить Databasus на другом сервере: просто воссоздайте структуру папки databasus-data из сохраненных файлов и запустите Databasus.

Как Databasus поддерживается open-source-программами Anthropic и OpenAI?

В марте 2026 года Databasus был принят и в Claude for Open Source от Anthropic, и в Codex for Open Source от OpenAI. Для нас очень ценно, что две ведущие ИИ-компании мира признали проект важным open-source-софтом для индустрии — особенно с учетом высоких требований обеих программ к участникам.

Что это значит для пользователей? Это еще одно подтверждение надежности: проект прошел независимую оценку и признан лидерами индустрии критичной инфраструктурой, которую стоит поддерживать. Так что качество кода становится еще выше, ревью безопасности — быстрее, а разработка остается активной благодаря доступу к новейшим ИИ без ограничений.

Databasus принят в программу Claude for Open Source от AnthropicDatabasus принят в программу Codex for Open Source от OpenAI

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