На днях познакомился с сервисом для бэкапа баз данных - Portabase.

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

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

▪️Поддержка всех популярных СУБД - PostgreSQL, MySQL/MariaDB, MongoDB,
Redis/Valkey, SQLite, Firebird, MSSQL и даже Docker Volume. Последнее, кстати, может быть наиболее актуальным для такого рода продукта.
▪️Веб интерфейс для настройки и управления.
▪️Клиент-серверная архитектура. На хосты с СУБД ставится агент. Он взаимодействует с СУБД локально, удалённые подключения к базам открывать не нужно. Агент сам отправляет данные, снятые с баз. С сервера бэкапов нет непосредственного доступа к самим базам данных, только к архивам. Это на самом деле неплохо сделано.
▪️Оповещения по всем популярным каналам - email и различные мессенджеры, сервисы уведомлений.
▪️Аутентификация через OIDC/OAuth2.
▪️Управление доступом RBAC.
▪️Политика хранения бэкапов, расписание, различные бэкенды хранения (локальные, S3 и некоторые сервисы).
▪️Для управления есть CLI и API.
▪️Бэкапы только в виде дампов.

По сути это просто обвязка вокруг pg_dump, mysqldump, mongodump и т.д. То есть только полные бэкапы, никаких инкрементов и WAL. Всё это относительно просто можно сделать с помощью bash и cron, что я обычно и делаю. Сложнее будет с правами доступа, но это не так часто нужно. Только в каких-то больших командах, но там, мне кажется, это тоже не совсем формат - малоизвестный проект какой-то французской команды.

Я некоторое время назад писал про похожее решение. Оно мне тоже показалось удобным и интересным. Начал пользоваться в одной компании. Добавил несколько серверов, стал снимать бэкапы. Потом в какой-то момент приложение умерло. Уже не помню, какие там были ошибки. Просто перестали создаваться бэкапы. Ни с того, ни с сего. Разбираться стало лень, я просто забил и вернулся к своим старым проверенным скриптам, где всё то же самое реализовано - бэкапы, проверки, уведомления, политика хранения и т.д. Работает просто и надёжно, мониторит Zabbix. Для восстановления ничего не надо, кроме самого дампа.

А в подобных программах само состояние бэкапов хранится в отдельной базе данных, которую тоже надо бэкапить. Если умрёт сервис, то все понаделанные бэкапы могут превратиться в тыкву, либо трудночитаемую кашу из дампов с именами в виде UUID.

К минусам Portabase отнесу довольно тяжёлый агент, который запускается в отдельном Docker контейнере. Ожидаешь от подобного подхода небольшого локального бинарника, а тут агент с образом на 862MB 😱.

# docker images | grep portabase
portabase/agent  latest  254181b7ced0  2 days ago  862MB

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

На выходе имеем довольно навороченную систему для снятия дампов с баз данных. Насколько она кому-то нужна в таком виде, судить не берусь. Мне не особо приглянулась. Для каких-то команд с кучей небольших баз возможно это будет решением их проблем. А такие на самом деле есть. Я когда-то давно смотрел выступление инженера одной крупной компании. У них там сотни мелких баз Postgresql крутились в кластерах Kubernetes. Практически у каждого микросервиса была своя база данных. Даже если у вас штук 50 баз, уже что-то подобное придётся городить. А тут из коробки OIDC/OAuth2 и RBAC, плюс API. Можно настроить автоматизацию для доступа команд только к своим бэкапам.

#backup