КЕЙС · РЕЗЕРВНОЕ КОПИРОВАНИЕ
Бэкапы в неоднородной инфраструктуре: как мы навели порядок с PostgreSQL, MySQL, MariaDB и MongoDB на одном дашборде
Резервное копирование баз данных PostgreSQL, MySQL, MariaDB и MongoDB в одной инфраструктуре — задача нетривиальная. У клиента было 6 серверов, 4 СУБД и ни одного централизованного бэкапа.
Каждая система обслуживалась своим bash-скриптом, восстановление никогда не тестировалось. Мы внедрили Portabase — open source инструмент для централизованного бэкапа — и организовали резервное копирование на 3 хранилища по расписанию.
Проблема: 6 серверов, 4 СУБД, 0 централизованных бэкапов
IT-инфраструктура клиента формировалась исторически. Каждое бизнес-направление заказывало свои серверы, свои СУБД. К моменту, когда стоимость простоя стала ощутимой, ситуация выглядела так:
- db-01, db-02 — PostgreSQL 15 (кластер 1С, PG Auto Failover, primary + standby)
- db-03 — MySQL 8.0 (корпоративная CRM)
- db-04 — MariaDB 10.11 (сайт и внутренние микросервисы)
- db-05 — MongoDB 7.0 (агрегация IoT-данных с датчиков)
- app-01 — PostgreSQL 15 (ELMA365, HR-процессы)
Резервное копирование баз данных на каждом сервере делалось по-своему: где-то cron + pg_dump, где-то mysqldump через bash-скрипт, где-то вообще ничего. Все бэкапы хранились на том же сервере. Тестового восстановления не проводилось ни разу за 2 года.
- Нет централизованного управления бэкапами
- Нет оповещений о провалах backup-задач
- Нет ротации: диски заполняются без контроля
- Нет offsite-копий — потеря сервера = потеря данных
По данным Veeam Data Protection Report, 58% компаний не могут восстановить данные из бэкапов в установленные сроки. 14% бэкапов вообще не восстанавливаются. Наш клиент был в зоне максимального риска.
Инфраструктура клиента в деталях
Для полноты картины — детальная схема серверов и баз данных. Именно эту таблицу мы использовали при планировании стратегии резервного копирования:
| Сервер | СУБД | Назначение | Объём данных | Бэкап до |
|---|---|---|---|---|
| db-01 (primary) | PostgreSQL 15 | 1С:Предприятие | 120 ГБ | cron + pg_dump, локально |
| db-02 (standby) | PostgreSQL 15 | Реплика 1С (failover) | 120 ГБ | — |
| db-03 | MySQL 8.0 | CRM | 45 ГБ | Ручной mysqldump |
| db-04 | MariaDB 10.11 | Сайт + микросервисы | 12 ГБ | cron + mysqldump, локально |
| db-05 | MongoDB 7.0 | IoT-агрегация | 8 ГБ | — |
| app-01 | PostgreSQL 15 | ELMA365 | 35 ГБ | — |
Серверы db-01 и db-02 работают в режиме PG Auto Failover. Primary-узел может переключиться в любой момент. Это важно для стратегии бэкапов — нужно снимать дамп именно с primary, иначе получим неконсистентный бэкап.
Выбор инструмента: почему Portabase
Резервное копирование баз данных нельзя доверять случайному инструменту. Перед выбором Portabase мы честно оценили несколько подходов. Вот что получилось:
Плюсы: бесплатно, полный контроль
Минусы: каждый скрипт нужно писать под конкретную СУБД, нет мониторинга, нет ротации, нет отчётов. При 6 серверах получается 6+ скриптов, которые нужно поддерживать. Это то, что было у клиента — и именно от этого мы уходим.
Плюсы: enterprise-уровень для PostgreSQL, инкрементальные бэкапы, PITR
Минусы: только PostgreSQL. У нас 4 разных СУБД — пришлось бы дополнительно настраивать отдельные инструменты для MySQL, MariaDB и MongoDB. Это умножает сложность вместо упрощения.
Плюсы: hot backup для MySQL/MariaDB, физические бэкапы
Минусы: опять зоопарк инструментов. Нет единого дашборда, нет централизованных алертов. По сути — те же скрипты, только сложнее.
Плюсы: поддерживает PostgreSQL, MySQL, MariaDB и MongoDB из коробки. Единый дашборд, агентная модель, ротация бэкапов, уведомления в Telegram и email. Open source (Apache 2.0), self-hosted. Написан на Rust — низкое потребление ресурсов.
Минусы: молодой проект (активная разработка с 2025 года), ещё нет инкрементальных бэкапов (планируется), нет PITR. Для нашей задачи (SMB-инфраструктура, логические дампы) — подходит.
Нужен self-hosted инструмент с поддержкой PostgreSQL, MySQL, MariaDB и MongoDB, с единым мониторингом. Portabase — единственный кандидат, который закрывает все 4 СУБД в одном интерфейсе.
Сравнительная таблица инструментов
| Критерий | Bash-скрипты | Barman | XtraBackup | Portabase |
|---|---|---|---|---|
| PostgreSQL | ✅ (pg_dump) | ✅ | ❌ | ✅ |
| MySQL / MariaDB | ✅ (mysqldump) | ❌ | ✅ | ✅ |
| MongoDB | ✅ (mongodump) | ❌ | ❌ | ✅ |
| Единый дашборд | ❌ | ⚠️ (только PG) | ❌ | ✅ |
| Алерты | Самописные | ❌ | ❌ | ✅ (Telegram, email) |
| Ротация бэкапов | Ручная | ✅ | Ручная | ✅ |
| Self-hosted | ✅ | ✅ | ✅ | ✅ |
| Стоимость | Бесплатно | Бесплатно | Бесплатно | Бесплатно |
Что такое Portabase
Portabase — open source платформа. Резервное копирование баз данных здесь организовано централизованно: один агент на каждом сервере, единый дашборд для всех СУБД. Проект молодой (активная разработка с 2025 года), но уже готов к использованию в production для SMB-инфраструктур.
Лицензия Apache 2.0 — использование, изменение и размещение в собственной инфраструктуре без ограничений. Исходный код открыт и доступен на GitHub.
Ключевые возможности
- Мультиплатформенность — PostgreSQL, MySQL, MariaDB, MongoDB в одном интерфейсе
- Агентная модель — легковесный агент (Rust, ~15 МБ Docker-образ) на каждом сервере
- Множество бэкендов хранения — локальный диск, S3, MinIO, Yandex Object Storage
- Гибкие расписания — cron-синтаксис, разные интервалы для разных баз
- Retention policies — автоматическая ротация с настройкой per-storage
- Уведомления — Telegram, email, webhook
- Восстановление — одной кнопкой из дашборда
Стратегия хранения: 3–2–1 на практике
Правило 3–2–1 — золотой стандарт резервного копирования: 3 копии данных, на 2 разных типах носителей, 1 копия offsite. Для каждого сервера мы настроили хранение в трёх местах одновременно:
🖥️ Локальный диск
Быстрое восстановление
Retention: последние 7 дней
Для оперативного восстановления при ошибках пользователей или обновлениях ПО
📦 MinIO (self-hosted)
Недельный архив
Retention: последние 14 дней
S3-совместимое хранилище на отдельном сервере. Защита от выхода из строя основного сервера
☁️ Yandex Object Storage
Месячный архив
Retention: 30 дней
Offsite-копия в облаке. Защита от физической потери оборудования
Для российских клиентов Yandex Object Storage — оптимальный выбор: серверы в РФ, расчёты в рублях, соответствие 152-ФЗ. API полностью S3-совместимый — переключение между провайдерами занимает 5 минут.
Пошаговое внедрение Portabase
Всё внедрение заняло один рабочий день. Вот как мы действовали:
Шаг 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, поэтому важно направить его на текущий primary-узел. Мы настроили подключение через VIP-адрес кластера — при failover бэкап автоматически переключается на новый primary.
Portabase не отслеживает смену primary-узла в кластере автоматически. Используйте VIP-адрес или HAProxy для автоматического переключения. Мы настроили VIP через keepalived.
Шаг 5. Настройка расписаний (Cron)
Для каждой группы баз задаём своё расписание через cron-синтаксис прямо в интерфейсе:
| База данных | Расписание | Комментарий |
|---|---|---|
| PostgreSQL (1С) | Каждые 4 часа | Критичная система, RPO 4 часа |
| MySQL (CRM) | Ежедневно, 02:00 | Минимальная нагрузка ночью |
| MariaDB (сайт) | Ежедневно, 03:00 | Небольшой объём, достаточно 1 раз |
| MongoDB (IoT) | Каждые 6 часов | Данные поступают непрерывно |
| PostgreSQL (ELMA365) | Ежедневно, 01:00 | HR-процессы, стандартный режим |
Шаг 6. Подключение трёх хранилищ
В разделе « Storage backends» подключаем все три хранилища. Portabase поддерживает одновременную запись в несколько backends — каждая база может иметь несколько целевых хранилищ. Настройка retention policy для каждого хранилища — отдельно.
Шаг 7. Настройка уведомлений
Настроили два канала: Telegram-бот (для дежурного администратора — оперативные алерты) и email (для руководителя IT — еженедельная сводка). Уведомления приходят при: успешном бэкапе, ошибке бэкапа, превышении размера дампа (аномалия), приближении к лимиту хранилища.
Шаг 8. Тестовое восстановление
Ключевой этап, который часто пропускают. Мы выполнили тестовое восстановление каждой базы на изолированный сервер:
- PostgreSQL (1С) — восстановление из дампа 120 ГБ заняло 18 минут
- MySQL (CRM) — 45 ГБ за 7 минут
- MariaDB (сайт) — 12 ГБ за 2 минуты
- MongoDB (IoT) — 8 ГБ за 3 минуты
Все восстановления прошли без ошибок. Данные валидны, приложения подключились к восстановленным базам штатно.
Результат: до и после
«Теперь я вижу статус бэкапов всех 6 серверов на одном экране. Раньше приходилось заходить на каждый сервер и проверять вручную — часто забывали. С Portabase забыть невозможно: если бэкап не прошёл, Telegram-бот сообщит через минуту.»
— Руководитель IT-отдела клиента
Частые вопросы
Да, Portabase распространяется под лицензией Apache 2.0. Community-версия бесплатна, включает все основные функции. Для enterprise-потребностей (кластеризация Dashboard, LDAP/SSO, приоритетная поддержка) планируется коммерческая версия.
На момент внедрения (февраль 2026): PostgreSQL, MySQL, MariaDB, MongoDB. В roadmap — ClickHouse и Redis. Для логического бэкапа используются штатные утилиты СУБД (pg_dump, mysqldump, mongodump).
Dashboard и агент доступны как Docker-контейнеры и как бинарные файлы. Мы рекомендуем Docker Compose для Dashboard (проще обновления) и бинарник для агента на минимальных серверах.
Зависит от объёма и источника. В нашем кейсе: 120 ГБ PostgreSQL — 18 минут с локального диска. Восстановление запускается одной кнопкой из дашборда — не нужно заходить на сервер по SSH.
Portabase шифрует данные подключения к базам. Dashboard защищён аутентификацией. Для дополнительной безопасности мы рекомендуем: изолированную сеть для Dashboard, ограничение доступа по IP, регулярное обновление.
Нужна помощь с резервным копированием?
Настроим резервное копирование баз данных под ваш стек — PostgreSQL, MySQL, MariaDB, MongoDB или любую комбинацию. Аудит текущих бэкапов — бесплатно. Внедрение — за один рабочий день.
