На днях познакомился с сервисом для бэкапа баз данных - Portabase. Видел обзор у одного... — 24 августа 2026 г. в 11:00:04.577
На днях познакомился с сервисом для бэкапа баз данных - 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