Перейти к содержанию

Резервное копирование

Стратегия и порядок бэкапа развёрнутой платформы DataHUB. Описывает что бэкапить, как часто, куда складывать и как восстанавливать. Конкретные инструменты — pg_dump, rabbitmqctl export_definitions, tar — стандартные, подходят для любой Linux-инфраструктуры.

Что подлежит бэкапу

Объект Критичность Источник истины
База PostgreSQL (DataHUB) критичный postgres:/var/lib/postgresql/data
Определения RabbitMQ (exchange/queue/binding/user) важный Management API → JSON
Конфигурации /etc/datahub/ важный хост-файловая система
TLS-сертификаты важный /etc/datahub/nginx/certs/ (входит в архив /etc/datahub/)
Секреты Сервера DataHUB (pepper, JWT, service token) критичный /etc/datahub/backend/certs/ (входит в архив /etc/datahub/)
Сообщения в очередях RabbitMQ НЕ бэкапим эфемерные, гарантии — через повторную обработку
Логи (/etc/datahub/nginx/log/, docker logs) опционально ротация средствами logrotate и Docker

База PostgreSQL — самый критичный артефакт: в ней хранится конфигурация обмена, пользователи, маршруты, состояние всех клиентских систем. Потеря БД без бэкапа = переинсталляция и ручная перенастройка всей конфигурации обмена.

Секреты Сервера DataHUB (pepper.txt, private_key.pem, public_key.pem, service_token.jwt) критичны не сами по себе, а тем, что без них все ранее выпущенные пароли и токены становятся невалидными. Потеря этих файлов = переинициализация всех пользовательских паролей и пересоздание service token'а.

Рекомендуемое расписание

Что Частота Срок хранения
Полный дамп PostgreSQL ежедневно 30 дней
rabbitmqctl export_definitions еженедельно 8 недель
Архив /etc/datahub/ еженедельно 12 недель
Дополнительный «контрольный» дамп PostgreSQL перед каждым обновлением платформы до следующего успешного обновления

Точные значения настраиваются под регламент заказчика. Если есть требование к точке восстановления (RPO) меньше суток — переходить к continuous archiving PostgreSQL (pg_basebackup + WAL-archiving), это выходит за рамки штатной поставки.

Куда складывать бэкапы

Каталог хранения — на отдельной файловой системе или хотя бы на отдельном диске от /etc/datahub/. Рекомендуемая локация — /var/backups/datahub/. Структура:

/var/backups/datahub/
├── postgres/
│   ├── datahub-2026-01-15.dump
│   ├── datahub-2026-01-16.dump
│   └── ...
├── rabbitmq/
│   ├── definitions-2026-W02.json
│   └── ...
└── etc/
    ├── etc-datahub-2026-W02.tar.gz
    └── ...

Дополнительно — копия в удалённое/географически разнесённое хранилище (S3, FTP, дублирующий сервер, лента). Бэкап, лежащий на том же сервере, что и продуктив, защищает только от ошибок оператора, но не от физической потери сервера.

PostgreSQL — резервное копирование

Один полный логический дамп:

sudo docker exec -t postgres pg_dump -U "$POSTGRES_USER" -d DataHUB -F c -f /tmp/datahub-$(date +%F).dump

Извлечение из контейнера на хост:

sudo docker cp postgres:/tmp/datahub-$(date +%F).dump /var/backups/datahub/postgres/

Удаление дампа из контейнера, чтобы не занимать data/:

sudo docker exec postgres rm /tmp/datahub-$(date +%F).dump

Скрипт-обёртка для cron, который делает дамп и удаляет старые файлы старше 30 дней:

sudo tee /usr/local/bin/datahub-pg-backup.sh >/dev/null <<'EOF'
#!/usr/bin/env bash
set -euo pipefail
BACKUP_DIR=/var/backups/datahub/postgres
DATE=$(date +%F)
DUMP=datahub-${DATE}.dump
mkdir -p "$BACKUP_DIR"

docker exec -t postgres pg_dump -U "$(grep ^POSTGRES_USER /etc/datahub/postgres/.env | cut -d= -f2)" \
    -d DataHUB -F c -f "/tmp/$DUMP"
docker cp "postgres:/tmp/$DUMP" "$BACKUP_DIR/"
docker exec postgres rm "/tmp/$DUMP"

find "$BACKUP_DIR" -name 'datahub-*.dump' -mtime +30 -delete
EOF
sudo chmod +x /usr/local/bin/datahub-pg-backup.sh

Расписание в cron:

0 2 * * * /usr/local/bin/datahub-pg-backup.sh >> /var/log/datahub-backup.log 2>&1

PostgreSQL — восстановление

Восстановление в существующую базу (с очисткой):

sudo docker cp /var/backups/datahub/postgres/datahub-YYYY-MM-DD.dump postgres:/tmp/restore.dump
sudo docker exec -i postgres pg_restore -U "$POSTGRES_USER" -d DataHUB --clean --if-exists /tmp/restore.dump
sudo docker exec postgres rm /tmp/restore.dump

Восстановление в чистый стенд (после переинсталляции):

  1. Развернуть платформу по Быстрому старту до момента запуска flyway — БД создана, схема пуста.
  2. НЕ запускать flyway — схема уже зашита в дампе.
  3. Положить дамп в контейнер и выполнить pg_restore (см. выше).
  4. Продолжить с шага запуска backend.

После любого восстановления — проверить, что версия миграций в БД соответствует версии backend'а (SELECT * FROM flyway_schema_history ORDER BY installed_rank DESC LIMIT 5;).

RabbitMQ — экспорт определений

Экспорт всех exchange/queue/binding/user в JSON:

sudo docker exec rabbitmq rabbitmqctl export_definitions /var/lib/rabbitmq/definitions.json
sudo docker cp rabbitmq:/var/lib/rabbitmq/definitions.json /var/backups/datahub/rabbitmq/definitions-$(date +%G-W%V).json
sudo docker exec rabbitmq rm /var/lib/rabbitmq/definitions.json

Расписание в cron (раз в неделю):

0 3 * * 0 /usr/local/bin/datahub-rmq-backup.sh >> /var/log/datahub-backup.log 2>&1

RabbitMQ — восстановление определений

Импорт обратно (после переинсталляции, при потере mnesia):

sudo docker cp /var/backups/datahub/rabbitmq/definitions-YYYY-WNN.json rabbitmq:/var/lib/rabbitmq/definitions.json
sudo docker exec rabbitmq rabbitmqctl import_definitions /var/lib/rabbitmq/definitions.json
sudo docker exec rabbitmq rm /var/lib/rabbitmq/definitions.json

После импорта Сервер DataHUB при следующем цикле синхронизации (раз в 60 секунд) сверит топологию с конфигурацией в БД и при необходимости донастроит недостающие очереди — rabbitmqctl import нужен скорее как опорная точка, чтобы быстро восстановить пользователей и vhost.

/etc/datahub/ — архив конфигов

Архив всех конфигов, секретов и сертификатов одной командой:

sudo tar -czf /var/backups/datahub/etc/etc-datahub-$(date +%G-W%V).tar.gz -C /etc datahub

Расписание в cron (раз в неделю):

0 4 * * 0 sudo tar -czf /var/backups/datahub/etc/etc-datahub-$(date +%G-W%V).tar.gz -C /etc datahub >> /var/log/datahub-backup.log 2>&1

Восстановление (на чистом сервере при переинсталляции):

sudo tar -xzf /var/backups/datahub/etc/etc-datahub-YYYY-WNN.tar.gz -C /etc

После — поправить права на каталоги данных (PostgreSQL и т.п. требуют корректного владельца).

Архив /etc/datahub/ содержит секреты

Внутри — .env со всеми паролями и приватные ключи. Хранить с правами 0600, шифровать при отправке в удалённое хранилище.

Восстановление после полной потери сервера

Сценарий: физическая потеря сервера или повреждение /etc/datahub/ без возможности восстановления in-place.

  1. На новом сервере выполнить Быстрый старт до момента создания /etc/datahub/, не запуская блоки.
  2. Удалить пустой /etc/datahub/ и восстановить из архива:
sudo rm -rf /etc/datahub
sudo tar -xzf /var/backups/datahub/etc/etc-datahub-YYYY-WNN.tar.gz -C /etc
  1. Запустить devops-core → rabbitmq → postgres (но не flyway и не backend):
cd /etc/datahub/devops-core && sudo docker compose up -d
cd /etc/datahub/rabbitmq    && sudo docker compose up -d
cd /etc/datahub/postgres    && sudo docker compose up -d
  1. Восстановить БД из дампа в postgres (см. выше).
  2. Восстановить определения RabbitMQ (см. выше).
  3. Запустить остальные блоки в стандартном порядке (pg-agmin → backend → frontend → nginx), пропустив flyway — схема уже в БД.
  4. Проверить healthcheck'и, ключевые сценарии, журналы.

После успешного восстановления — обязательно сделать новый полный бэкап.

Тестирование восстановления

Бэкап, который ни разу не разворачивался, нельзя считать работоспособным. Регулярно (минимум раз в квартал) — выполнять тестовое восстановление в отдельное окружение:

  1. Поднять на тестовом сервере чистый стенд по Быстрому старту.
  2. Применить процедуру восстановления PostgreSQL и /etc/datahub/.
  3. Войти в личный кабинет, проверить наличие конфигурации обмена, отправить тестовое сообщение.
  4. Зафиксировать факт успешного восстановления в журнале администрирования.

При первом тестовом восстановлении обычно вылезают мелкие проблемы (отсутствующие переменные, забытые шаги ротации секретов) — это и есть смысл регулярного теста.

Что НЕ делать

  • Не бэкапить /etc/datahub/postgres/data/ файлами на работающем postgres. Это не атомарный снапшот — данные в data/ могут оказаться в несогласованном состоянии. Только через pg_dump или предварительную остановку контейнера.
  • Не делать docker commit контейнеров. Это не бэкап — это снапшот файловой системы контейнера, который смешивает образ и данные. Используйте штатные инструменты резервного копирования.
  • Не хранить единственную копию бэкапа на той же машине, что и продуктив. Минимум — копия на отдельной файловой системе, оптимально — географически разнесённое хранилище.
  • Не пропускать тестовое восстановление. Бэкап без проверенного восстановления — лотерея.

Что дальше