Резервное копирование, а не выгорание: что мы выпустили в Postgresus 2.0 (и от чего отказались)

\ Прошло 6 месяцев с первого релиза Postgresus. За это время проект получил 247 коммитов, новые функции, а также ~2,8k звезд на GitHub и ~42k загрузок из Docker Hub. Сообщество проекта также выросло, сейчас в нем 13 контрибьюторов и 90 человек в группе Telegram.

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

• что изменилось в проекте за шесть месяцев;
• какие новые функции появились
• какие планы на будущее.

\

Что такое Postgresus?

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

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

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

• Хранить резервные копии локально, в S3, CloudFlare R2, Google Drive, Azure Blob Storage и NAS. Подробнее здесь.
• Отправлять уведомления о статусе в Slack, Discord, Telegram, MS Teams, по электронной почте и на настраиваемый вебхук. Подробнее здесь.
• Разделять базы данных по рабочим пространствам, предоставлять доступ другим пользователям и сохранять журналы аудита. Подробнее здесь.
• Шифровать резервные копии и учетные данные. Подробнее здесь.
• Работать как с самостоятельно размещенными базами данных, так и с облачными управляемыми базами данных.

Веб-сайт - https://postgresus.com/

GitHub - https://github.com/RostislavDugin/postgresus (буду признателен за звезду ⭐️)

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

Обзорное видео: https://www.youtube.com/watch?v=1qsAnijJfJE

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

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

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

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

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

Давайте рассмотрим каждое из них.

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

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

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

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

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

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

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

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

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

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

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

• базы данных клиента X;
• базы данных стартапа Y;
• базы данных команды Z;

Команды администраторов баз данных и крупные аутсорсинговые компании начали использовать Postgresus, поэтому это стало важной функцией. Это делает проект полезным не только для отдельных разработчиков, DevOps или администраторов баз данных, но и для целых команд и предприятий.

Также появились журналы аудита:

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

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

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

Но когда Postgresus стал проектом с открытым исходным кодом, я быстро узнал, что команды часто сохраняют резервные копии в общих корзинах S3 и не хотят, чтобы другие их читали. Пароли баз данных также не должны храниться в собственной базе данных Postgresus, поскольку многие люди имеют доступ к его серверам. ~~И есть некоторое недоверие друг к другу.~~ Просто не раскрывать секреты через API уже недостаточно.

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

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

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

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

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

Шифрование использует как соль, так и уникальный вектор инициализации. Это предотвращает поиск злоумышленниками шаблонов для угадывания ключа шифрования, даже если они украдут все ваши файлы резервных копий.

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

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

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

• ваш сервер будет полностью взломан, они получат секретный ключ и легитимный IP-адрес для доступа к базе данных;
• хакер каким-то образом расшифрует пароли во внутренней базе данных Postgresus и узнает пароль вашей базы данных;
• или, что еще хуже, это будет не хакер, а кто-то изнутри;
• и они повредят вашу базу данных, предварительно удалив резервные копии.

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

Теперь, когда вы добавляете пользователя базы данных с правами записи в Postgresus, система предлагает автоматически создать пользователя только для чтения и запускать резервное копирование через него. Люди с гораздо большей вероятностью создадут роль только для чтения, когда для этого требуется один клик, а не ручная настройка в базе данных.

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

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

С таким подходом, даже если ваш сервер Postgresus будет взломан, все будет расшифровано, и злоумышленники получат доступ к вашей базе данных — они, по крайней мере, не смогут повредить базу данных. Знание того, что не все потеряно, является довольно хорошим утешением.

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

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

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

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

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

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

Это быстро — мы добавили нативную поддержку k8s с установкой Helm. Команды, запускающие k8s в облаке, теперь могут развертывать Postgresus проще. Три контрибьютора помогли с этой функцией.

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

Я не особый поклонник темных тем. Но было много запросов, поэтому я добавил одну (~~спасибо Claude за помощь и дизайнерский взгляд~~). Удивительно, но она оказалась лучше светлой темы и стала темой по умолчанию. Я даже переделал веб-сайт со светлого на темный — он выглядел так хорошо.

До:

После:

8) Избавление от инкрементальных резервных копий и PITR (восстановление на момент времени)

Сначала немного контекста:

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

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

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

• Очень сложно сделать это удобным с точки зрения UX и DevEx. Потому что вам нужно либо физически подключиться к диску с базой данных, либо настроить репликацию.

Для восстановления — нет варианта не подключаться к диску с базой данных. Для восстановления из инкрементальной резервной копии инструмент резервного копирования просто восстанавливает папку pgdata (точнее, ее часть).

Если база данных действительно большая, например, несколько ТБ и более — требуется тонкая настройка в конфигурациях. Здесь пользовательский интерфейс скорее помеха, чем помощь.

• Большинство облаков (AWS, Google, Selectel) не будут работать с внешними инкрементальными резервными копиями, если они требуют доступа к диску. Теоретически, с некоторыми обходными путями, через репликацию — они будут. Но восстановление из такой резервной копии в управляемое облако все равно не будет работать.
• Все облака предоставляют инкрементальные резервные копии из коробки. В общем, это одна из причин, почему они платные. И даже они обычно не позволяют восстанавливаться с точностью до секунды или до конкретного момента транзакции. А если вы не в облаке — еще менее вероятно, что ваш проект достаточно критичен, чтобы требовать такой точности.

Поэтому, если Postgresus делает резервную копию управляемой базы данных — достаточно делать это примерно раз в неделю. На случай непредвиденной чрезвычайной ситуации или если облако не позволяет хранить резервные копии достаточно долго. В противном случае полагайтесь на собственные инкрементальные резервные копии облака.

• Для большинства проектов инкрементальные резервные копии на самом деле не так уж необходимы. Для небольших баз данных достаточно детализации между резервными копиями в один час, если это необходимо часто. Для больших — хотя бы раз в день. Этого достаточно для 99% проектов, чтобы найти потерянные данные или полностью восстановиться. Эти потребности полностью покрываются логическими резервными копиями.

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

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

• В прошлом, когда не было такого выбора облачных управляемых баз данных, и крупные проекты требовали размещения всего самостоятельно. Теперь те же банки, маркетплейсы и телеком имеют внутренние облака с PITR из коробки.
• Вы являетесь управляемым облаком. Но здесь задача радикально сложнее, чем просто создание резервных копий и восстановление из них.

Учитывая все это, я принял осознанное решение отказаться от разработки инкрементального резервного копирования. Вместо этого я сосредоточился на том, чтобы сделать логические резервные копии максимально удобными, надежными и практичными для ежедневного использования разработчиками, DevOps, администраторами баз данных и компаниями.

9) Множество мелких улучшений

Вышеперечисленные пункты далеко не все. 80% работы обычно не видно. Навскидку, вот короткий список:

• Буферизация и оптимизация оперативной памяти. Postgresus больше не пытается буферизовать все, что отправляет pg_dump, ожидая, пока S3 догонит (загрузка из базы данных обычно быстрее, чем загрузка в облако). Использование оперативной памяти теперь ограничено 32 МБ на параллельное резервное копирование.
• Различные улучшения стабильности и исправления мелких ошибок.
• Добавление SMTP без имени пользователя и без пароля. Я даже не знал, что такое бывает…
• Добавление тем для отправки уведомлений в группы Telegram.
• Появилась документация!
• Поддержка PostgreSQL 12.

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

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

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

1) Полный мониторинг ресурсов базы данных

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

• CPU
• RAM
• ROM
• Скорость ввода-вывода и нагрузка

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

Оказывается, PostgreSQL из коробки предоставляет только метрики использования оперативной памяти и ввода-вывода.

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

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

В конечном итоге эта несущественная функция добавила бы:

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

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

2) SQL-консоль

Я также хотел добавить SQL-консоль. Поскольку Postgresus уже подключен к базе данных, почему бы не запускать запросы прямо из него? Это было бы удобно — не нужно каждый раз открывать PgAdmin, DataGrip или DBeaver.

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

• необходимо добавить поддержку синтаксиса SQL;
• добавить автозаполнение и подсказки;
• сделать ленивую загрузку, чтобы даже 100 МБ строк не приходили в браузер;
• добавить хотя бы несколько экспортов в CSV и XLSX.

Это, по сути, полноценный проект сам по себе, а не просто одна вкладка.

Мы решили отказаться от этой функции и сэкономить усилия. Это оказалось правильным решением, поскольку мы добавили роли только для чтения, которые в любом случае не позволяют INSERT, UPDATE и DELETE.

Заключение

Вот какой путь прошел Postgresus за шесть месяцев. Он вырос из нишевого проекта до инструмента корпоративного уровня, который помогает как отдельным разработчикам, так и целым командам администраторов баз данных (кстати, я был удивлен, узнав об этом всего через ~2 месяца после первого релиза). Я искренне рад, что тысячи проектов и пользователей полагаются на Postgresus.

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

Мои основные приоритеты остаются:

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

Если вам нравится проект или вы находите его полезным — я был бы признателен за звезду на GitHub или за то, что вы поделитесь им с друзьями ❤️

\