Резервное копирование и восстановление

На этой странице:

• Область применения
• Что копируется
• Рекомендуемый регламент
• Копирование конфигурации
• Копирование учётных записей и прав доступа
• Копирование настроек и журналов из БД
• Копирование данных телеметрии
• Проверка резервной копии
• Восстановление
• Хранение копий

Область применения

Регламент описывает резервное копирование ProtoOBP Backend в варианте установки на одном сервере (см. Установка бэкенда). Для конфигураций из двух и более серверов порядок копирования предоставляется по запросу в техническую поддержку Proto.

Далее используются значения путей по умолчанию:

• каталог установки — /opt/protoobp;
• каталог данных (POBP_DATA_DIRECTORY) — /opt/protoobp/data.

Если при установке значения менялись — скорректируйте команды.

Агенты ProtoOBP резервному копированию не подлежат: их конфигурация задаётся при установке и восстанавливается переустановкой агента.

Что копируется

Состояние платформы делится на четыре группы с разной ценностью и разной стоимостью копирования.

Не копируются (восстанавливаются автоматически при запуске платформы):

• data/kafka, data/zookeeper — транзитная очередь телеметрии;
• data/analyzer — кеш аналитического слоя;
• debug/ — отладочные дампы.

Рекомендуемый регламент

Глубина хранения по умолчанию: ежесуточные копии — 14 дней, еженедельные — 8 недель, предобновленческие — до успешной приёмки следующего обновления.

Копирование конфигурации

Выполняется на работающей платформе.

BACKUP_DIR=/backup/protoobp/$(date +%F)
mkdir -p "$BACKUP_DIR"

tar -czf "$BACKUP_DIR/protoobp-config.tar.gz" \
  -C /opt/protoobp \
  --exclude=./data --exclude=./debug \
  .

Архив содержит .env с лицензионным ключом, паролями SMTP и ключом доступа к внешней языковой модели, поэтому его следует хранить с ограниченным доступом (см. Хранение копий).

Копирование учётных записей и прав доступа

Учётные записи, роли, группы и параметры подключения к каталогу пользователей хранятся в БД сервиса proto-auth. Копия снимается на работающей платформе:

docker exec proto-postgresql \
  pg_dump -U protoobp -d proto-auth --format=custom \
  > "$BACKUP_DIR/proto-auth.dump"

При использовании внешнего каталога пользователей (LDAP/AD или OIDC) сами учётные записи находятся во внешней системе, и в копии сохраняются только настройки подключения и локальные назначения ролей.

Копирование настроек и журналов из БД

Выгрузка выполняется на работающей платформе и занимает секунды: перечисленные таблицы малы по сравнению с телеметрией. Такую выгрузку имеет смысл делать ежесуточно, даже если полное копирование данных не выполняется.

CH="docker exec proto-database clickhouse-client -u protoobp --password proto-clickhouse"
mkdir -p "$BACKUP_DIR/settings"

for T in \
  alert_rules alert_receivers alert_routes \
  dashboards dashboard_folders dashboard_versions \
  business_processes business_process_steps bp_step_map \
  key_business_transactions slo_definitions \
  maintenance_windows maintenance_window_revisions \
  report_definitions report_runs \
  incident_workflow_config incident_workflow_config_history \
  service_apdex_threshold data_extraction_rules annotations \
  normalized_segments \
  resource_types relationship_types resource_type_ci_mapping \
  ci_classes ci_subclasses resource_retention_policies \
  ci_change_history ci_mapping_quarantine rbac_audit_log
do
  $CH -q "SELECT * FROM proto.$T FORMAT Native" > "$BACKUP_DIR/settings/$T.native"
done

tar -czf "$BACKUP_DIR/protoobp-settings.tar.gz" -C "$BACKUP_DIR" settings && rm -rf "$BACKUP_DIR/settings"

В выгрузку входят как сами настройки, так и связанные с ними журналы, которые невозможно восстановить из других источников: журнал аудита действий пользователей (rbac_audit_log), история изменений конфигурационных единиц модели ресурсов (ci_change_history), карантин сопоставления типов ресурсов (ci_mapping_quarantine), история изменений рабочего процесса инцидентов (incident_workflow_config_history) и история запусков отчётов (report_runs). Их объём растёт со временем, но остаётся на порядки меньше телеметрии; ограничивается сроками хранения самих таблиц (журнал аудита — согласно параметру срока хранения, история изменений CI — 365 дней, история запусков отчётов — 180 дней).

Состав таблиц соответствует версии 202; при обновлении платформы список следует сверять с примечаниями к выпуску.

Не входит в выгрузку история исполнения бизнес-процессов (business_process_execution_steps) — это телеметрия, привязанная к трейсам, с собственным коротким сроком хранения; она копируется только вместе с каталогом данных.

Восстановление такой выгрузки выполняется на запущенной платформе после её первичной инициализации (таблицы уже созданы):

tar -xzf protoobp-settings.tar.gz

for F in ./settings/*.native; do
  T=$(basename "$F" .native)
  docker exec -i proto-database clickhouse-client -u protoobp --password proto-clickhouse \
    -q "INSERT INTO proto.$T FORMAT Native" < "$F"
done

Копирование данных телеметрии

Хранилища платформы держат часть состояния в памяти, поэтому копирование каталога данных на работающей платформе даёт неконсистентную и непригодную для восстановления копию. Полная копия данных снимается только при остановленной платформе.

1. Остановите платформу:

   cd /opt/protoobp && docker compose -f docker-compose-202.yaml down
   

2. Скопируйте каталог данных, исключив транзитные и кешируемые каталоги:

   tar -czf "$BACKUP_DIR/protoobp-data.tar.gz" \
     -C /opt/protoobp/data \
     --exclude=./kafka --exclude=./zookeeper --exclude=./analyzer \
     .
   

3. Запустите платформу:

   cd /opt/protoobp && docker compose -f docker-compose-202.yaml up -d
   

На время останова телеметрия от агентов не принимается и накапливается на стороне агентов ограниченное время; продолжительный останов приводит к разрыву в данных. Окно обслуживания следует выбирать в период минимальной нагрузки и заранее объявлять в режиме обслуживания, чтобы не порождать ложные оповещения.

Проверка резервной копии

Копия, которую ни разу не разворачивали, резервной копией не является. Не реже одного раза в квартал следует выполнять контрольное восстановление на отдельном сервере и проверять:

• платформа поднимается, веб-интерфейс доступен по UI_URL;
• вход выполняется существующей учётной записью, роли и права сохранены;
• дашборды и правила алертинга присутствуют;
• при восстановлении данных — исторические метрики отображаются на дашбордах.

Для быстрой проверки целостности архивов достаточно:

tar -tzf "$BACKUP_DIR/protoobp-config.tar.gz" >/dev/null && echo OK
tar -tzf "$BACKUP_DIR/protoobp-data.tar.gz" >/dev/null && echo OK

Восстановление

Восстановление выполняется на сервере, подготовленном согласно разделу Подготовка сервера, с установленным Docker. Версия образов платформы должна совпадать с версией, из которой снята копия (указана в .env и docker-compose-202.yaml). Если на сервере ещё нет Docker-образов платформы, потребуется доступ к репозиторию образов (docker login, см. Установка бэкенда) либо образы, перенесённые вручную по оффлайн-процедуре.

1. Восстановите конфигурацию:

   mkdir -p /opt/protoobp && tar -xzf protoobp-config.tar.gz -C /opt/protoobp
   

2. При восстановлении на другом сервере проверьте в .env значения POBP_COMPUTE и UI_URL и, при необходимости, скорректируйте их и DNS-записи.

3. Восстановите данные телеметрии — только если они копировались:

   mkdir -p /opt/protoobp/data && tar -xzf protoobp-data.tar.gz -C /opt/protoobp/data
   

   Затем в любом случае создайте недостающие каталоги данных и восстановите права доступа (как при установке):

   mkdir -p /opt/protoobp/data/database  && chown -R 101:101   /opt/protoobp/data/database
   mkdir -p /opt/protoobp/data/opensearch && chown -R 1000:1000 /opt/protoobp/data/opensearch
   mkdir -p /opt/protoobp/data/logs      && chown -R 1000:1000 /opt/protoobp/data/logs
   mkdir -p /opt/protoobp/data/metrics   && chown -R 1000:1000 /opt/protoobp/data/metrics
   mkdir -p /opt/protoobp/data/kafka     && chown -R 65532:65532 /opt/protoobp/data/kafka
   mkdir -p /opt/protoobp/data/zookeeper && chown -R 1001:1001   /opt/protoobp/data/zookeeper
   chown 65532:65532 /opt/protoobp/alertrules.yml /opt/protoobp/alertpolicies.yml
   

4. Запустите платформу и дождитесь инициализации:

   cd /opt/protoobp && docker compose -f docker-compose-202.yaml up -d
   

   При первом запуске часть контейнеров инициализируется и перезапускается — как и при установке, появление ошибки в выводе docker compose на этом этапе является штатным, повторите команду.

5. Восстановите учётные записи:

   docker compose -f docker-compose-202.yaml stop proto-auth
   docker exec -i proto-postgresql \
     pg_restore -U protoobp -d proto-auth --clean --if-exists < proto-auth.dump
   docker compose -f docker-compose-202.yaml start proto-auth
   

6. Если каталог данных не восстанавливался, загрузите выгрузку настроек и журналов из БД — порядок описан в разделе Копирование настроек и журналов из БД. Загрузку выполняйте после полной инициализации платформы (все контейнеры запущены) и только один раз, чтобы не создать дубликаты объектов.

7. Проверьте состояние платформы:

   cd /opt/protoobp && docker compose -f docker-compose-202.yaml ps
   

   Все контейнеры должны быть в состоянии running. Затем откройте веб-интерфейс и выполните проверки из раздела Проверка резервной копии.

Если данные телеметрии не восстанавливались, платформа стартует с пустыми хранилищами и начинает накапливать данные заново. Все пользовательские настройки — правила алертинга, каналы и маршруты оповещений, дашборды, бизнес-процессы, ключевые транзакции, SLO, окна обслуживания, расписания отчётов, настройки модели ресурсов, а также журнал аудита и история изменений — восстанавливаются из копии data/database либо из выгрузки таблиц настроек; файлы alertrules.yml и alertpolicies.yml платформа перегенерирует из БД самостоятельно. При отсутствии обеих копий эти объекты будут созданы заново из поставляемых по умолчанию шаблонов, а пользовательские настройки утеряны.

Хранение копий

• Копии размещаются вне сервера платформы — на выделенном хранилище или в системе резервного копирования заказчика.
• Архив конфигурации и дамп учётных записей содержат секреты (лицензионный ключ, пароли SMTP и служебных учётных записей, ключ доступа к языковой модели) — доступ к ним ограничивается администраторами платформы, при передаче по сети используется шифрование.
• Права на файлы копий: 0600, владелец — учётная запись, от имени которой выполняется копирование.
• Факт и результат каждого копирования фиксируются в системе резервного копирования заказчика; отсутствие успешной копии за сутки должно порождать оповещение.