КЕЙС · РЕЗЕРВНОЕ КОПИРОВАНИЕ
Бэкапы в неоднородной инфраструктуре: как мы навели порядок с PostgreSQL, MySQL, MariaDB и MongoDB на одном дашборде
Резервное копирование баз данных PostgreSQL, MySQL, MariaDB и MongoDB в одной инфраструктуре — задача нетривиальная. У клиента было 6 серверов, 4 СУБД и ни одного централизованного бэкапа.
Каждая система обслуживалась своим bash-скриптом, восстановление никто не проверял, а ответственного за резервные копии… не существовало.
В этом кейсе — как мы решили задачу за один рабочий день, не потратив ни рубля на лицензии.
Ситуация: когда каждый делает бэкап по-своему
Клиент — производственная компания с собственным IT-отделом. Инфраструктура складывалась годами: разные системы внедрялись в разное время, разными подрядчиками.
Каждый оставлял после себя своё решение для бэкапов. Централизованное резервное копирование баз данных отсутствовало как понятие. В итоге картина стала типичной для таких сред:
- Каждый сервер бэкапируется отдельным bash-скриптом, написанным годы назад разными людьми
- Никто не проверяет, что бэкапы реально восстанавливаются: скрипты «работают», но проверки нет
- Уведомления об ошибках — отсутствуют. Упавший cron-job можно не замечать неделями
- Большинство бэкапов хранится локально на том же сервере, где и данные
- Нет единого журнала: непонятно, когда был последний успешный бэкап каждой базы
- Ответственного за резервное копирование нет — «все следят, значит никто»
По данным Veeam Data Protection Report, 58% компаний теряли данные за последние три года. Самая частая причина — отсутствие проверки восстановления. Бэкап, который никто не тестировал — это не бэкап.
Инфраструктура клиента: что нужно было защитить
Резервное копирование баз данных должно покрывать весь технологический стек без исключений. Перед выбором инструмента мы составили полную карту того, что нужно защитить:
| Сервер | СУБД | Сервис / назначение | Объём БД |
|---|---|---|---|
| db-01, db-02 | PostgreSQL 16 + PG Auto Failover | 1С:Предприятие 8.3 — основная рабочая БД | ~80 ГБ |
| mon-01 | PostgreSQL 16 | Zabbix 7.0 — мониторинг всей инфраструктуры | ~15 ГБ |
| web-01 | MySQL 8.0 | Корпоративный сайт + интернет-магазин (WordPress / WooCommerce) | ~12 ГБ |
| crm-01 | MariaDB 10.11 | CRM-система (Bitrix24 self-hosted) | ~8 ГБ |
| sec-01 | MongoDB 7.0 | Passwork — корпоративный менеджер паролей | ~5 ГБ |
| ИТОГО | PostgreSQL, MySQL, MariaDB, MongoDB | 5 критичных систем / 6 серверов | ~120 ГБ |
Серверы db-01 и db-02 работают в режиме PG Auto Failover: db-01 — primary (ведущий узел), db-02 — standby (горячий резерв). Бэкап снимается с primary-узла через pg_dump. Важный нюанс: при failover IP-адрес primary меняется, поэтому агент Portabase настраивается на VIP (виртуальный IP) или HAProxy-балансировщик, который всегда направляет запросы на текущий primary.
Что рассматривали и почему не подошло
Резервное копирование баз данных нельзя доверять случайному инструменту. Перед выбором Portabase мы честно оценили несколько подходов. Вот что получилось:
То, с чего начали — и от чего уходили. Главная проблема: это не система, а набор разрозненных решений. Нет единого журнала, нет мониторинга, нет уведомлений. Когда cron-задача падает, это обнаруживается только тогда, когда нужно восстановление. Масштабирование на новые серверы — ручная работа каждый раз.
Отличный инструмент для глубокой работы с PostgreSQL: инкрементальные бэкапы, WAL-архивирование, быстрое восстановление на момент времени (PITR). Но: поддерживает только PostgreSQL. Для MySQL/MariaDB и MongoDB нужны отдельные инструменты. Единого интерфейса управления нет. В нашем случае — это ещё три разных решения сверху.
Зрелый инструмент от компании EnterpriseDB, специально для PostgreSQL-окружений. Поддерживает потоковую репликацию, инкрементальные бэкапы. Ограничение: только PostgreSQL. Ситуация та же, что с pgBackRest — для нашей разнородной инфраструктуры нужно несколько инструментов параллельно.
Nakivo Backup & Replication, Veeam Backup — зрелые корпоративные продукты. Почему не подошли: во-первых, стоимость. Во-вторых, и это принципиально — данные или метаданные обработки проходят через инфраструктуру вендора. Для ряда клиентов это неприемлемо с точки зрения информационной безопасности.
Нужен self-hosted инструмент с поддержкой PostgreSQL, MySQL, MariaDB и MongoDB из единого интерфейса. Бесплатный. С web-UI, уведомлениями и RBAC. Именно таким оказался Portabase.
Сравнение инструментов
| Критерий | Bash + cron | pgBackRest | Barman | Portabase ⭐ | Nakivo | Veeam |
|---|---|---|---|---|---|---|
| PostgreSQL | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| MySQL / MariaDB | ± | ✗ | ✗ | ✓ | ✓ | ✓ |
| MongoDB | ± | ✗ | ✗ | ✓ | ± | ± |
| Web-интерфейс | ✗ | ✗ | ± | ✓ | ✓ | ✓ |
| Уведомления | ✗ | ✗ | ✗ | ✓ | ✓ | ✓ |
| Self-hosted | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| S3 / MinIO | ± | ✓ | ✓ | ✓ | ✓ | ✓ |
| RBAC / роли | ✗ | ✗ | ✗ | ✓ | ✓ | ✓ |
| Open Source | ✓ | ✓ | ✓ | ✓ | ✗ | ✗ |
| Цена | 0 ₽ | 0 ₽ | 0 ₽ | 0 ₽ | $$ | $$$ |
± — частичная поддержка или требует ручной настройки. Данные проверены на февраль 2026 г.
Portabase: что это и почему мы остановились на нём
Portabase — open source платформа. Резервное копирование баз данных здесь организовано централизованно: один агент на каждом сервере, единый дашборд для всех СУБД. Проект молодой (активная разработка с 2025 года), но уже готов к использованию в production для SMB-инфраструктур.
Лицензия Apache 2.0 — использование, изменение и распространение свободно.
Поддерживаемые СУБД на февраль 2026 г.: PostgreSQL, MySQL, MariaDB, MongoDB, SQLite. В разработке — Redis.
Ключевые причины выбора
- Единый дашборд для всех СУБД. Один агент на сервере покрывает весь стек клиента. Не нужно переключаться между четырьмя разными инструментами.
- Pull-режим агента. Агент (написан на Rust) сам инициирует соединение с центральным сервером. Не нужно открывать входящие порты на серверах с базами данных — это критично для безопасности.
- Суверенитет данных. Данные не покидают инфраструктуру клиента ни при каких условиях. Нет облачного вендора, нет рисков утечки через третьи стороны.
- Несколько хранилищ одновременно. Можно параллельно писать на локальный диск, MinIO и S3 — одна настройка, три копии.
- RBAC. Разграничение доступа: роли member / admin / owner на уровне системы и организации.
- Уведомления в реальном времени. Telegram, Slack, Discord, Email, Webhooks. Настраивается на уровне каждой базы данных отдельно.
Резервное копирование баз данных: архитектура хранения 3-2-1
Резервное копирование баз данных мы организовали по классическому правилу 3-2-1: 3 копии данных, на 2 разных типах носителей, 1 из которых — за пределами основной площадки. На практике это три хранилища, работающие параллельно:
🖥️ Локальный диск
Быстрое восстановление
Retention: последние 3 дня
Хранение: backup-сервер в той же сети
Цель: моментальное восстановление при сбое в течение рабочей недели
📦 MinIO (self-hosted)
Недельный архив
Retention: последние 7 дней
S3-совместимый, деплой на отдельный сервер
Цель: полный контроль, данные внутри периметра, без абонентской платы
☁️ Yandex Object Storage
Месячный архив
Retention: 30 дней
S3-совместимый API, российские ЦОД
Цель: защита от локальной катастрофы (пожар, затопление, кража сервера)
Для российских клиентов важно хранить данные на российских серверах (ФЗ-152, требования регуляторов). Yandex Object Storage поддерживает S3-совместимый API, поэтому Portabase подключает его как обычный S3-бакет. Альтернативы: VK Cloud Storage, Selectel Object Storage — все с S3-совместимым API.
Как выстраивалось резервное копирование баз данных: от нуля до защищённой инфраструктуры
Резервное копирование баз данных мы развернули за один рабочий день. Вот что делали шаг за шагом.
Шаг 1. Установка Portabase Dashboard
На отдельный сервер (2 ГБ RAM, 20 ГБ диск) устанавливаем центральный сервер Portabase. Используем Docker Compose — официальный и рекомендуемый метод:
# Быстрая установка через CLI
curl -sL portabase.io/install | bash
portabase dashboard .Шаг 2. Установка агентов на каждый сервер
На каждый из 6 серверов устанавливаем агент Portabase. Агент написан на Rust, работает как Docker-контейнер, образ весит ~15 МБ. Агент не требует открытых входящих портов — он сам подключается к Dashboard (pull-режим):
# Установка агента
portabase agent .
# Либо через Docker Compose — см. документацию portabase.io/docsШаг 3. Подключение СУБД через Dashboard
В веб-интерфейсе добавляем базы данных каждого сервера. Для каждой БД указываем: тип СУБД, хост, порт, имя базы, credentials. Portabase хранит данные подключения зашифрованно.
Шаг 4. Нюанс: PostgreSQL-кластер с PG Auto Failover
Кластер 1С (db-01, db-02) требует особого внимания. Portabase снимает бэкап через стандартный pg_dump, подключаясь к базе как обычный клиент.
При PG Auto Failover агент должен подключаться к виртуальному IP (VIP), а не к конкретному IP сервера. VIP или балансировщик (HAProxy, Keepalived) всегда направляет запросы на primary-узел.
Portabase не отслеживает смену primary-узла в кластере автоматически. Это задача балансировщика (Keepalived, HAProxy, Patroni). Если подключить агент напрямую к db-01 и произойдёт failover на db-02, бэкапы будут сниматься со standby-ноды. Правильное решение — VIP поверх кластера.
Шаг 5. Настройка расписаний (Cron)
Для каждой группы баз задаём своё расписание через cron-синтаксис прямо в интерфейсе:
| База данных | Расписание | Cron | Причина |
|---|---|---|---|
| 1С (PostgreSQL, кластер) | Каждые 4 часа | 0 */4 * * * | Высокая транзакционность |
| Zabbix (PostgreSQL) | Ежедневно в 03:00 | 0 3 * * * | Данные мониторинга |
| Сайт / WooCommerce (MySQL) | Ежедневно в 02:00 | 0 2 * * * | Умеренная активность |
| CRM Bitrix24 (MariaDB) | Ежедневно в 01:00 | 0 1 * * * | Критичные данные клиентов |
| Passwork (MongoDB) | Ежедневно в 00:30 | 30 0 * * * | Пароли — максимальная защита |
Шаг 6. Подключение трёх хранилищ
В разделе « Storage backends» подключаем все три хранилища. Portabase поддерживает одновременную запись в несколько backends — каждая база может иметь несколько целевых хранилищ. Настройка retention policy для каждого хранилища — отдельно.
Шаг 7. Настройка уведомлений
Настроили два канала: Telegram-бот (для дежурного администратора — оперативные уведомления) и Email (для руководителя IT-отдела — ежедневный отчёт). Уведомления настраиваются на уровне каждой базы: отдельно для 1С, отдельно для CRM.
Шаг 8. Тестовое восстановление — обязательный шаг
Это критически важно. Бэкап без проверки восстановления — не бэкап. Мы провели тестовое восстановление каждой СУБД на отдельном тестовом сервере, зафиксировали время и убедились, что данные корректны. Результаты занесли в документацию.
Параллельно с бэкапами мы настроили для этой же инфраструктуры мониторинг серверов Zabbix 7.0 — чтобы узнавать о проблемах раньше, чем потребуется восстановление.
Результаты: резервное копирование баз данных в цифрах
«Теперь я вижу статус бэкапов всех систем в одном месте. Telegram присылает отчёт каждое утро. Если что-то пошло не так — узнаём сразу, а не когда уже нужно восстанавливать данные»
— Системный администратор клиента
Часто задаваемые вопросы
На момент публикации (февраль 2026 г.) — да, Portabase распространяется по лицензии Apache 2.0 и является полностью бесплатным. Все возможности доступны без ограничений. Проект открытый — код на GitHub, финансирование через сообщество.
Ничего критичного. Apache 2.0 даёт право форкать, изменять и поддерживать проект самостоятельно. Бэкапы хранятся в стандартных форматах: pg_dump для PostgreSQL (.sql или custom), mysqldump для MySQL/MariaDB, mongodump для MongoDB. Эти форматы читаются нативными инструментами без Portabase.
Через веб-интерфейс Portabase: выбираете базу, выбираете точку восстановления (конкретный бэкап по дате и времени), нажимаете «Restore». Агент на сервере получает задачу, скачивает нужный файл из хранилища и восстанавливает базу. Можно восстановить на тот же сервер или на другой.
Portabase подключается к PostgreSQL как стандартный клиент через pg_dump. Для кластера важно: агент должен подключаться к текущему primary-узлу. Рекомендуется использовать виртуальный IP (VIP через Keepalived) или HAProxy перед кластером. Тогда при failover Portabase продолжает снимать бэкапы без перенастройки.
Да, расписание настраивается индивидуально для каждой базы данных через cron-синтаксис в интерфейсе. Базу 1С можно бэкапировать каждые 4 часа, Zabbix — раз в сутки, а Passwork — ночью. Всё это управляется из единого дашборда.
Проект активно развивается: в январе–феврале 2026 г. вышла версия с поддержкой MongoDB, агент переписан с Python на Rust (размер образа уменьшился в 4 раза, надёжность выросла). Для SMB-инфраструктур без суперстрогих требований — готов. Для enterprise с PITR (point-in-time recovery) для PostgreSQL лучше комбинировать с pgBackRest для PostgreSQL-части.
Нужны надёжные бэкапы для вашей инфраструктуры?
Настроим резервное копирование баз данных под ваш стек — PostgreSQL, MySQL, MariaDB, MongoDB или любую комбинацию. Аудит текущих бэкапов — бесплатно. Внедрение — за один рабочий день.
