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

Единственный stateful-компонент платформы — PostgreSQL. Всё остальное (API-служба, консоль, агенты) — stateless; потеря подов не приводит к потере данных.

Что резервировать

Что	Метод	Частота
PostgreSQL	managed backup / pg_dump + WAL-G	ежесуточно + PITR
JWT private key (Secret)	snapshot вашего хранилища секретов	при изменении
Helm values всех компонентов	Git-репозиторий инфраструктуры	при изменении
TLS-сертификаты	secret-snapshot	при изменении
Список подключённых кластеров с company token	хранится в БД, отдельного бэкапа не требует	—

PostgreSQL: бэкап

Managed

Для managed-сервисов (Yandex Managed PostgreSQL и другие managed-PostgreSQL-сервисы вашего провайдера) включите:

• ежедневный автобэкап (обычно уже включён по умолчанию),
• PITR с retention 7–30 дней,
• периодическое тестовое восстановление в staging.

Self-hosted

pg_dump -h pg.internal -U opsman -d opsman -Fc \
  -f /backups/opsman-$(date +%F).dump

Для PITR используйте WAL-G / pgBackRest.

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

1. Подготовьте пустую БД на новом инстансе:

   CREATE USER opsman WITH PASSWORD '***';
   CREATE DATABASE opsman OWNER opsman;

2. Восстановите из бэкапа:

   pg_restore -h new-pg.internal -U opsman -d opsman \
     /backups/opsman-YYYY-MM-DD.dump

3. Обновите DATABASE_URL в values.prod.yaml API-службы и выполните helm upgrade.

4. Проверьте:

   • curl -sf https://api-opsman.company.com/healthz → 200
   • Тестовый логин
   • Данные Dashboard за последние 7 дней

Что может потеряться

Если использовали не PITR, а только daily-бэкап — возможна потеря до 24 часов данных от момента бэкапа до инцидента. Эти данные придут повторно из облачного биллинга и из ingest агента, но история полного дня будет с пропусками.

JWT-ключ: потеря и восстановление

Если JWT-ключ потерян безвозвратно:

1. Сгенерируйте новый.
2. Обновите secret в Kubernetes.
3. Rolling restart API-службы.
4. Все активные сессии пользователей станут невалидными — потребуется повторный логин.

План на случай полного сбоя

1. Развернуть новый Kubernetes-кластер (или использовать резервный).
2. Развернуть PostgreSQL, восстановить из бэкапа.
3. Применить Helm-чарты из Git (infrastructure-as-code).
4. Восстановить JWT-ключ и TLS-сертификаты.
5. Проверить: логин, UI, ingest, уведомления.

Ориентировочное время восстановления с нуля — 60–90 минут.

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

Раз в месяц выполняйте тестовое восстановление в staging-окружении и прогоняйте smoke-тест: логин, открытие Dashboard, наличие данных за последние 7 дней. Без регулярных проверок бэкапы могут оказаться непригодными в момент, когда они нужны.