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

Mon, 01 Jan 0001 00:00:00 +0000

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

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

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

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

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

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

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

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

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

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

Группа	Что входит	Объём	Критичность	Периодичность
Конфигурация в файлах	`/opt/protoobp/.env`, `docker-compose-202.yaml`, каталог `config/`, файлы `.env_ldap*`, `.env_oidc`, файлы SSL-сертификата	единицы МБ	высокая	после каждого изменения + еженедельно
Учётные записи и права	БД сервиса `proto-auth` (том `postgres_data`): пользователи, роли, группы, настройки LDAP/OIDC-подключения	десятки МБ	высокая	ежесуточно
Настройки и журналы в БД	таблицы настроек и журналов в `data/database` (`proto-database`): правила алертинга, каналы и маршруты оповещений, дашборды и папки дашбордов, бизнес-процессы, ключевые бизнес-транзакции, SLO, окна обслуживания, правила и расписания отчётов, настройки рабочего процесса инцидентов, пороги APDEX, правила извлечения данных, правила нормализации URL, маркеры изменений, настройки модели ресурсов, а также журнал аудита действий пользователей, история изменений конфигурационных единиц, история изменений рабочего процесса и история запусков отчётов	единицы–сотни МБ	высокая	ежесуточно
Данные телеметрии	остальное содержимое `data/database` (метрики сервисов, трейсы, инциденты, состояние модели ресурсов, история исполнения бизнес-процессов), `data/metrics` (инфраструктурные метрики), `data/opensearch`, `data/logs` (логи)	десятки–сотни ГБ	средняя	еженедельно или по решению заказчика

Важно

Настройки, которые администратор создаёт в веб-интерфейсе, хранятся не в файлах, а в proto-database, то есть в том же каталоге data/database, что и телеметрия. Резервное копирование только файлов конфигурации из /opt/protoobp их не сохраняет: при потере каталога данных правила алертинга, каналы оповещений, дашборды, бизнес-процессы, ключевые транзакции, SLO, окна обслуживания и расписания отчётов будут утеряны, а платформа стартует с поставляемыми по умолчанию шаблонами. Поэтому в регламент обязательно включается либо ежесуточная выгрузка таблиц настроек и журналов (см. Копирование настроек и журналов из БД), либо полное копирование каталога данных.

Файлы alertrules.yml и alertpolicies.yml резервной копией настроек алертинга не являются: это генерируемый слепок, который платформа перезаписывает из БД при каждом изменении правил и каналов оповещения. Восстановление этих файлов без БД не вернёт настройки — при следующей синхронизации они будут перезаписаны текущим содержимым БД.

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

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

О смысле копирования телеметрии

Данные телеметрии хранятся ограниченное время (см. Конфигурация срока хранения данных): сырые трейсы — сутки, метрики — недели, агрегаты — до 60 дней. Восстановление недельной копии возвращает данные, значительная часть которых уже утратила актуальность. Поэтому минимально достаточный регламент — это копирование конфигурации, учётных записей, а также настроек и журналов из БД: он позволяет восстановить работоспособную и полностью настроенную платформу за минуты, потеряв только историю телеметрии. Полное копирование данных имеет смысл, если история метрик и трейсов используется для разбора инцидентов задним числом или для отчётности.

Периодичность	Объект	Останов платформы	Ориентировочная длительность
После каждого изменения `.env` или параметров запуска	конфигурация в файлах	не требуется	секунды
После массовых изменений правил алертинга, каналов оповещения или дашбордов	настройки и журналы из БД	не требуется	секунды
Ежесуточно, ночью	конфигурация + учётные записи + настройки и журналы из БД	не требуется	минуты
Еженедельно, в окно обслуживания	полная копия, включая данные телеметрии	требуется	зависит от объёма данных, обычно 20–90 минут
Перед обновлением версии платформы	полная копия	требуется	—

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

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

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

Восстановление поверх существующих данных

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

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

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

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

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

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

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

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

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, см. Установка бэкенда) либо образы, перенесённые вручную по оффлайн-процедуре.

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

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

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

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

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

Запустите платформу и дождитесь инициализации:
```
cd /opt/protoobp && docker compose -f docker-compose-202.yaml up -d
```
При первом запуске часть контейнеров инициализируется и перезапускается — как и при установке, появление ошибки в выводе docker compose на этом этапе является штатным, повторите команду.

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

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

Если каталог данных не восстанавливался, загрузите выгрузку настроек и журналов из БД — порядок описан в разделе Копирование настроек и журналов из БД. Загрузку выполняйте после полной инициализации платформы (все контейнеры запущены) и только один раз, чтобы не создать дубликаты объектов.
Проверьте состояние платформы:
```
cd /opt/protoobp && docker compose -f docker-compose-202.yaml ps
```
Все контейнеры должны быть в состоянии running. Затем откройте веб-интерфейс и выполните проверки из раздела Проверка резервной копии.

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

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

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

Документация Proto Observability Platform – регламент