С момента первого релиза Postgresus прошло 6 месяцев. За это время проект получил 246 коммитов, новые функции, а также ~2.7к звёзд на GitHub и ~40к загрузок из Docker Hub. Сообщество проекта тоже подросло, сейчас в проекте числится 11 контрибьюторов, а группа в Telegram — 87 человек.

В этой статье я расскажу:

• что поменялось в проекте за полгода;

• какие новые возможности появились

• какие планы дальше.

Содержание

• Что за проект?

• Новые функции, которые появились к версии 2.0

  • Проверка состояния базы

  • Новые источники для хранения резервных копий и для отправки уведомлений

  • Управление проектами и пользователями

  • Шифрование и защита

    • Шифрование всех паролей и секретов

    • Шифрование файлов резервных копий

    • Использование read only пользователя для резервного копирования

  • Сжатие по умолчанию, причём самое оптимальное

  • Поддержка Kubernetes Helm

  • Темная тема

  • Отказ от инкрементальных резервных копий и PITR (Point In Time Recovery)

  • Много-много мелких улучшений
    

• А что не получилось?

  • Полноценный мониторинг ресурсов БД

  • SQL консоль
    

• Заключение

Что за проект?

Для тех, кто впервые слышит о проекте: Postgresus — это open source инструмент для резервного копирования PostgreSQL с графическим интерфейсом. Главная задача проекта: делать резервные копии нескольких баз данных по расписанию и сохранять их как локально, так и во внешних хранилищах. При этом уведомлять пользователя о статусе: когда копирование закончилось или провалилось.

Проект разворачивается одной командой в Docker. Его можно установить через shell скрипт, Docker команду, docker-compose.yml и теперь через Helm для Kubernetes. Детальнее о способах установки.

Помимо основной функции "делать резервные копии", проект умеет:

• Сохранять резервные копии локально, в S3, CloudFlare R2, Google Drive, Azure Blob Storange и NAS. Детальнее здесь.

• Отправлять уведомления о статусе в Slack, Discord, Telegram, MS Teams, по почте и в настраиваемый вебхук. Детальнее здесь.

• Разделать базы по проектам, выдавать доступы другим пользователям и сохранять аудит логи. Детальнее здесь.

• Шифровать резервные копии и доступы. Детальнее здесь.

• Работать как с self hosted базами, так и с облачными managed базами.

Сайт - https://postgresus.com/
GitHub - https://github.com/RostislavDugin/postgresus (буду раз звезде ⭐️)

Вот июльская статья про проект: "Как я пришёл в open source в 2025-м (с утилитой для бекапа PostgreSQL), чуть не потеряв проект на ~$1500\мес в 2023-м"

Интерфейс проекта выглядит вот так:

Обзорное видео на английском:

Для тех, кто хочет принять участие в разработке, есть отдельная страница в документации. Если кто-то хочет помочь проекту, но не хочет программировать — просто рассказывайте о проекте своим коллегам и знакомым! Это тоже большая помощь и вклад в проект.

Разрабатывать я умею, а вот продвигать даже open source проект достаточно сложно. Проект получает узнаваемость благодаря тем, кто делает видео обзоры и рассказывает о проекте в Telegram каналах. Спасибо вам!

Новые функции, которые появились к версии 2.0

За эти полгода многое поменялось. Проект улучшился по четырем направлениям:

• расширение базового функционала;

• улучшение UX;

• появление новых возможностей для команд (DBA, DevOps, аутсорс компаний);

• улучшение защиты и шифрования, чтобы соответствовать enterprise требованиям.

Теперь обо всем по порядку.

1) Проверка состояния базы

Postgresus, помимо резервного копирования, научился проверять состояние базы: чтобы показывать и предупреждать, если база была недоступна какое-то время.

UPD: скриншот от пользователя с интервалом 7 дней

Проверку состояния можно отключить и настроить.

Если база недоступна — система пришлёт уведомление об этом.

2) Новые источники для хранения резервных копий и для отправки уведомлений

Изначально Postgresus умел хранить резервные копии только локально и в S3. К ним добавились Google Drive, CloudFlare R2, Azure Blob Storange и NAS. В планах добавить ещё FTP и, возможно, SFTP и NFS.

Для уведомлений изначально в проекте были Telegram и почта (SMTP). Теперь поддерживается ещё Slack, Discord, MS Teams и вебхуки. Причём вебхуки теперь гибко настраиваются, чтобы подключаться к разным платформам:

3) Управление проектами и пользователями

Раньше в системе был только один пользователь (администратор), а базы были глобальными для всей системы. Теперь Postgresus поддерживает создание проектов для разделения баз и добавление пользователей к проектам. Причём с разделением ролей:

• только просмотр (можно смотреть историю бекапов, скачивать файлы резервных копий);

• редактирование (можно добавлять\удалять\изменять базы в дополнении к чтению).

Следовательно, теперь можно разделять базы:

• базы клиента Х;

• базы стартапа Y;

• базы команды Z;

Так как Postgresus начали использовать команды DBA и большие компании по аутсорс разработке — это оказалась важная функция. Чтобы проект был полезен не только отдельно взятым разработчикам, DevOps'ам или DBA, а целым командам и компаниям.

А ещё появились аудит логи:

Если кто-то решил удалить все базы данных или зачем-то скачал все резервные копии всех баз — это будет видно ?

4) Шифрование и защита

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

Но когда Postgresus вышел в open source, внезапно выяснилось, что резервные копии часто сохраняют в командные S3 и не хотят, чтобы кто-то мог их прочитать. Пароли к базам тоже не нужно хранить в БД самого Postgresus'a, потому что к серверам с ним имеет доступ сразу много людей. Да и присутствует некоторое недоверие друг к другу. Просто не отдавать секреты через API — уже мало.

Итого, шифрование и защищенность всего проекта стала основным приоритетом для Postgresus'a. Теперь защита стоит на трех уровнях, для этого даже есть отдельная страница в документации.

1) Шифрование всех паролей и секретов

Все пароли к базам, секретные токены к Slack'у и пароли от S3 хранятся только в зашифрованном виде в базе Postgresus'а. Расшифровка происходит в момент обращения. Секретный ключ хранится в файле отдельно от БД, чтобы даже если каким-то чудом БД Postgresus'a взломали (хотя она вообще не торчит наружу) — всё равно ничего не прочитали. Для шифрования используется AES-256-GCM.

2) Шифрование файлов резервных копий

Файлы резервных копий теперь тоже шифруются (опционально, но по умолчанию шифрование включено). Если вы потеряли файл или сохранили его в публичном S3 — уже не так страшно.

Причём для шифрования используется и соль, и уникальный initial vector. Чтобы нельзя было установить закономерность и подобрать ключ шифрования (пусть даже это очень дорого и сложно), если у вас украли все файлы резервных копий.

Шифрование идет в потоковом режиме, тут тоже используется AES-256-GCM.

3) Использование read only пользователя для ��езервного копирования

Несмотря на первые два пункта, не существует 100% способа защиты. Всё равно присутствует мизерный шанс, что:

• ваш сервер взломают целиком и полностью, получат секретный ключ и легитимный IP адрес для доступа к базе;

• хакер каким-то чудом расшифрует пароли во внутренней БД Postgresus'а и узнает пароль от вашей БД;

• или, хуже того, это будет не хакер, а человек из внутреннего контура;

• и испортит вам базу, предварительно удалив резервные копии.

Следовательно, Postgresus должен помочь своему пользователю минимизировать ущерб. От того, что вероятность такого взлома стремится к нулю — не сильно поможет тому, с кем эта вероятность случилась.

Поэтому теперь, когда вы добавляете в Postgresus пользователями с правами записи, система предлагает автоматически создать read only пользователя и делать резервные копии через него. Шанс, что кто-то создаст роль с правами только на чтение гораздо выше, когда такое действие требует один клик, а не пойти в базу и всё сделать вручную.

Вот так Postgresus предлагает:

Очень настойчиво предлагает:

С таким подходом, даже если ваш сервер с Postgresus'ом взломали, всё расшифровали и даже получили доступ к вашей БД — хакер хотя бы не сможет испортить базу. Все-таки это очень хорошее утешение знать, что потеряно не всё.

5) Сжатие по умолчанию, причём самое оптимальное

В первой версии Postgresus предлагал любое сжатие, которое поддерживает PostgreSQL на выбор: gzip, lz4 и zstd. И с любым уровнем сжатия с 1 до 9. Тут буду честен: я сам не сильно понимал, зачем такой выбор нужен. И выбирал gzip с уровнем сжатия 5. Просто как самый средний вариант, как мне казалось.

Но проект стал open source'ным. Нужно было всё-таки изучить этот вопрос. Поэтому за сутки я сделал 21 резернвую копию во всевозможных комбинациях и нашёл самую оптимальную по скорости и размеру.

Об этом есть статья на Хабре: "Резервные копии PostgreSQL: сравнение скорости pg_dump в разных форматах и с разными уровнями сжатия".

Поэтому теперь по умолчанию для всех резервных копий стоит zstd с уровнем сжатия 5, если PostgreSQL версии 16 и выше. Если ниже — всё ещё gzip (кстати, ещё раз спасибо контрибьюторам за поддержку PG 12). Вот zstd 5 в сравнении с gzip 5 (он снизу):

В среднем резервные копии сжимаются в ~8 раз относительно фактического размера базы данных.

6) Поддержка Kubernetes Helm

Тут довольно коротко — добавилась нативная поддержка k8s и установка из Helm. Тем, кто использует k8s в облаках стало немного удобнее использовать проект. Причём в эту задачу включилось сразу 3 контрибьютора.

7) Темная тема

Вообще, я не фанат темных тем. Но было много запросов, поэтому добавил её (спасибо Claude за помощь и его дизайнерский взгляд). Внезапно, она оказалась лучше светлой и стала основной. Даже сайт переделал из светлой темы в тёмную — настолько классно вышло. Спасибо моему другу и дизайнеру Максиму за помощь с сайтом, обалденно получилось.

Было:

Стало:

Отказ от инкрементальных резервных копий и PITR (Point In Time Recovery)

Тут нужен контекст:

• Логическая резервная копия — это когда PostgreSQL сам экспортирует свои данные (в файл или группу файлов).

• Физическая резервная копия — это когда мы подключаемся к жёсткому диску PostgreSQL и делаем копию его файлов.

• Инкрементальная резервная копия с поддержкой PITR — это физическая резервная копия + журнал изменений (WAL), скопированный с диска или по протоколу репликации.

У меня было убеждение, что Postgresus в конечном итоге должен поддерживать инкрементальные резервные копии. Ведь так делают серьезные инструменты! Даже ChatGPT говорит, что серьезные инструменты умеют восстанавливаться с точностью до секунды и транзакции.

Поэтому я начал работать в этом направлении. Но пришло осознание:

1. Это очень тяжело сделать удобным с точки зрения UX и DevEx. Потому что нужно или подключаться физически к диску с БД, или настраивать репликацию.
   
   Для восстановления — нет опции не подключаться к диску с базой. Чтобы восстановиться из инкрементальной копии, инструмент резервного копирования просто восстанавливает папку pgdata (точнее её часть).
   
   Если база реально большая, например, несколько ТБ и больше — нужна тонкая настройка в конфигах. Тут UI скорее мешает, чем помогает.

2. Большинство облаков (AWS, Google, Selectel) не будут работать с внешними инкрементальными резерервными копиями, если они требуют доступ к диску. В теории, с танцем с бубном, через репликацию — будут. А вот восстановиться из такой резервной копии в managed облако всё равно не выйдет никак.

3. Все облака предоставляют инкрементальные копии из коробки. В целом, это одна из причин, почему им платят. И то, даже они обычно не дают восстанавливаться секунда к секунде или к моменту конкретной транзакции. А если вы не в облаке — тем более вряд ли у вас достаточно критичный проект, чтобы была нужна такая точность.
   
   Поэтому, если Postgresus'ом делают резервную копию managed БД — достаточно её делать условно раз в неделю. Просто на случай непредвиденного ЧП или если облако не даёт хранить копии достаточно долго. В остальном стоит полагаться на инкрементальные копии самого облака.

4. Для большинства проектов инкрементальные резервные копии, по факту, не особо-то и нужны. Для небольших баз достаточно гранулярности между резервными копиями в один час, если нужно часто. Для больших — хотя бы раз в день. Этого хватит для 99% проектов, чтобы найти потерянные данные или восстановиться целиком. Эти потребности с головой покрывают логические резервные копии.
   
   А вот если вы банк или разработчик managed БД, вам действительно нужна тончайшая настройка резервного копирования ваших десятков и сотен терабайт данных. Тут Postgresus никогда не переплюнет физические резервные копии от WAL-G или pgBackRest в плане консольного удобства и эффективности для БД с объемом в ТБ и более. Но, имхо, это уже специализированные инструменты под такие задачи, которые делают гении и мэйнтейнеры самого PostgreSQL.

В общем, по моему мнению, инкрементальные резервные копии нужны в двух случаях:

1. В прошлом, когда не было такого выбора облачных managed баз и под большие проекты нужно было хостить всё самому. Сейчас те же банки, маркетплейсы и телеком имеют внутренние облака с PITR из коробки.

2. Вы и есть managed облако. Но тут уже задача радикально сложнее, чем просто делать резервные копии и восстанавливаться из них.

Учитывая все пункты выше, я принял волевое решение, что отказываюсь от разработки инкрементальных резервных копий. Вместо этого — фокусируюсь на том, чтобы сделать логическое резервирование максимально удобным, надёжным и подходящим для ежедневного использования разработчиками, DevOps'ами, DBA и компаниями.

9) Много-много мелких улучшений

Пункты выше — это далеко не всё. 80% работы обычно не видно. Навскидку, вот короткий список из того, что я вспомнил:

• Буферизация и оптимизация использования RAM. Теперь Postgresus не пытается запихнуть в оперативную память всё, что ему пришлёт pg_dump, пока S3 тормозит с записью (скачивание из базы обычно медленнее отправки в облако). Введено ограничение расхода в 32 МБ оперативной памяти на одну параллельную резервную копию.

• Всевозможное улучшений стабильности и мелкие исправления ошибок.

• Добавление SMTP без имени пользователя и без пароля. Я даже не знал, что так бывает...

• Добавление тем для отправки уведомлений в Telegram группы.

• Появилась документация!

• Поддержка PostgreSQL 12.

И много всего другого.

А что не получилось?

Разумеется, не всё получается сделать и от чего-то приходится отказываться. Все-таки Postgresus я делаю в свободное от работы время. Которого обычно нет. Поэтому нужно не распылять ресурс. Да и не усложнять UX лишними возможностями. Избыток функций и возможностей — это тоже плохо.

1) Полноценный мониторинг ресурсов БД

У меня была идея сделать Postgresus также и инструментом для мониторинга загруженности PostgreSQL. Включая мониторинг системных ресурсов сервера, где PostgreSQL установлен:

• CPU

• RAM

• ROM

• Скорость и загрузка IO

Даже сделал каркас для сбора метрик (любых) и шаблон графиков:

Оказалось, что мониторить в PostgreSQL из коробки можно только загрузку RAM и показатели IO.

Для мониторинга остальных ресурсов нужно устанавливать расширения. Но не каждая база может установить нужные мне расширения, поэтому приходилось добавлять сбор только части метрик. Затем выяснилось, что облачные базы вообще не особо дают устанавливать расширения.

Потом пришло понимание, что неплохо бы метрики хранить не в PostgreSQL самого Postgresus, а в VictoriaMetrics или, хотя бы, TimescaleDB, что усложняло сборку образа.

В общем, не самая ключевая функция добавила:

• серьезное усложнение кода, а значит усложнение поддержки;

• повышение требований к сборке образа (нужно больше компонентов);

• усложняло UX (как я сказал, избыток возможностей — тоже плохо);

• да и усложняло позиционирование: то ли бекапим, то ли мониторим, то ли всё по чуть-чуть.

Поэтому от опции мониторинга ресурсов решил отказаться. При этом сфокусировав силы на резервном копировании, чтобы быть лучшим инструментом под эту задачу.

2) SQL консоль

Также была идея сделать SQL консоль. Раз Postgresus уже подключен к БД, нет проблем сразу же из него делать запросы и что-то смотреть. Удобно, под рукой. Чтобы не идти каждый раз в PgAdmin, Data Grip или DBeaver.

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

• нужно сделать поддержку синтаксиса SQL;

• добавить автокомплит и подсказки;

• сделать ленивую подгрузку, чтобы в браузер не пришло даже 100МБ строк;

• добавить хотя бы несколько экспортов в CSV и XLSX.

Что уже тянет на полноценный проект, а не на одну вкладку.

В общем, от функции было решено отказаться и не тратить силы. Что оказалось правильным решением, так как добавилась read only роль, которая не даёт делать INSTERT, UPDATE и DELETE.

Заключение

Собственно, вот такой путь прошёл Postgresus за полгода. Из нишевого проект вырос до инструмента enterprise уровня, который упрощает жизнь и простым разработчикам, и целым командам DBA (я, кстати, удивился такому инсайту спустя всего ~2 месяца после релиза первой версии). Я искренне рад, что Postgresus'ом пользуются тысячи проектов и пользователей.

Проект не планирует останавливаться. Теперь у меня цель сделать Postgresus самым удобным инструментом для резервного копирования PostgreSQL в мире. Есть достаточно большой беклог функций и улучшений, которые будут постепенно появляться.

При этом для меня главными остаются приоритеты:

• безопасности проекта — это критично, без этого всё остальное не имеет смысла;

• удобный UX в плане использования самого проекта и отсутствие переизбытка функций (выполняем одну задачу, но очень хорошо);

• удобный UX в плане деплоя: чтобы всё деплоилось одной командой и ничего не нужно было настраивать из коробки;

• открытость проекта — полностью open source и бесплатный для любого человека или компании.

Как и говорил, если проект понравился или оказался полезным — буду раз звезде на GitHub или если поделитесь со знакомыми ❤️. И Telegram канал у меня есть, но это так, вдруг интересно.

---

Также может быть интересно:

• Как я встроил процесс тренировок в свою жизнь (и собрал спортзал дома, вложив $400 в течение 2-х лет)

• Постмортем: 4 мои ошибки во время отражения DDOS атаки (спойлер — выкуп в $250 мы все-таки не заплатили)

• 10 непривычных моментов в Go для Java разработчика

• Мои 7 правил при собеседовании разработчиков