Настройка мониторинга RPO/RTO для DR compliance

В большинстве компаний RPO и RTO живут только в SLA — без дашбордов и алертов. Пока не случится реальный DR, никто не знает, насколько свежие бэкапы и сколько времени займёт восстановление. Мы интегрируем RPO/RTO в observability и делаем compliance видимым. Используем Prometheus, Grafana и автоматические restore-тесты, чтобы вы всегда знали фактическое состояние резервных копий. Каждый час простоя обходится в среднем в $9k–13k, а мониторинг RPO позволяет сократить простой на 40%.

Как мониторинг делает RPO и RTO измеримыми

RPO (Recovery Point Objective) — максимально допустимый возраст данных, которые можно потерять. Если RPO = 1 час, резервная копия должна быть не старше 1 часа. Мониторинг: current_time - last_backup_time ≤ RPO. RTO (Recovery Time Objective) — максимальное время восстановления сервиса. RTO = 4 часа означает, что от аварии до рестарта должно пройти не более 4 часов. RTO нельзя измерить без фактического восстановления, поэтому мы используем регулярные DR-учения с замером времени в Prometheus.

Какие метрики нужно собирать для RPO мониторинга

Для каждого бэкапа публикуем три ключевые метрики через Pushgateway: backup_last_success_timestamp_seconds, backup_size_bytes и backup_success (0/1). Дополнительно — backup_restore_test_success и backup_restore_test_duration_seconds для валидации. Все метрики имеют метки по БД, типу (full/incremental) и окружению. Сравнивая возраст бэкапа с RPO target, мы вычисляем deviation и триггерим алерт при нарушении. Более 95% нарушений RPO выявляются на стадии тестирования, а MTTR снижается на 40% за счёт раннего обнаружения — это подтверждает наш опыт внедрения на 50+ проектах.

Как настроить мониторинг RPO для баз данных

Каждый backup-скрипт публикует метрику времени последнего успешного выполнения через Prometheus Pushgateway. Пример для PostgreSQL:

#!/bin/bash
# backup_postgres.sh
if [ $? -eq 0 ]; then
    BACKUP_SIZE=$(stat -c%s "$BACKUP_FILE")
    cat <<EOF | curl --data-binary @- http://pushgateway:9091/metrics/job/backup/instance/postgres-prod
# TYPE backup_last_success_timestamp_seconds gauge
backup_last_success_timestamp_seconds{database="postgres-prod",type="full"} $(date +%s)
# TYPE backup_size_bytes gauge
backup_size_bytes{database="postgres-prod",type="full"} $BACKUP_SIZE
EOF
fi

Алерт в Prometheus нарушает RPO при превышении заданного порога:

- alert: BackupRPOViolation
  expr: |
    (time() - backup_last_success_timestamp_seconds{type="full"}) > (3600 * 2) # RPO = 2 часа
  for: 5m
  labels:
    severity: critical
  annotations:
    summary: "RPO violation: last backup of {{ $labels.database }} was {{ $value | humanizeDuration }} ago"

Для MySQL аналогично: mysqldump + Pushgateway. Для Velero в Kubernetes — встроенная метрика velero_backup_last_successful_timestamp при включении --metrics-port. Автоматические restore-тесты в 3 раза быстрее ручных учений — среднее RTO снижается с 6 до 2 часов на этапе тестирования.

Почему RTO нужно проверять через DR-учения

Фактическое RTO нельзя измерить без восстановления. Плановые учения раз в квартал: восстанавливаем из бэкапа в изолированное окружение, фиксируем время завершения в Prometheus:

cat <<EOF | curl --data-binary @- http://pushgateway:9091/metrics/job/dr_drill
# TYPE dr_actual_rto_seconds gauge
dr_actual_rto_seconds{service="api-service",environment="staging"} 7200
# TYPE dr_drill_timestamp_seconds gauge
dr_drill_timestamp_seconds{service="api-service"} $(date +%s)
EOF

Автоматизируем restore-тесты для БД: barman check, mysqlcheck, mongorestore + валидация данных. Метрики:

# TYPE backup_restore_test_success gauge
backup_restore_test_success{database="postgres-prod"} 1
# TYPE backup_restore_test_duration_seconds gauge
backup_restore_test_duration_seconds{database="postgres-prod"} 1847

Автоматизация restore-тестов позволяет сократить среднее время восстановления на 40% за счёт раннего обнаружения проблем. Без них вы узнаете о повреждённом бэкапе только в момент реальной аварии — когда каждая минута на счету. Наши сертифицированные инженеры гарантируют, что каждый restore-тест проходит с полной валидацией данных.

Дашборды RPO/RTO compliance в Grafana

Строим две ключевые панели. RPO Compliance — таблица по системам: название, RPO target, фактический возраст последнего бэкапа, статус. Запрос:

(time() - backup_last_success_timestamp_seconds) / 3600 

RTO Trend — график фактического RTO из учений по времени, отображает тренд и позволяет прогнозировать проблемы.

Дополнительная таблица — сводка restore-тестов:

Типичные ошибки при настройке RPO мониторинга

• Бэкап запускается, но молча падает — статус не проверяется. Нужна метрика backup_success с алертом при отсутствии.
• Следующий успешный бэкап может быть через дни — RPO мониторинг должен оповещать при превышении допустимого окна.
• Бэкап успешен, но данные повреждены — обязательны restore-тесты с метрикой успеха.
• RTO замеряется только во время реального DR — внедрите регулярные учения с публикацией метрик.
• Мониторинг RPO не оповещает при нарушении — настройте Alertmanager на critical severity.

Процесс работы и что входит

1. Аудит текущего состояния: схемы бэкапов, инструменты, существующие метрики.
2. Инструментирование backup-скриптов через Pushgateway или экспортеры.
3. Настройка алертов RPO и дашборда Grafana с RPO Compliance и RTO Trend.
4. Автоматизация restore-тестов под ваш стек БД (PostgreSQL, MySQL, MongoDB, Velero).
5. Документация runbook и обучение дежурных инженеров.

Сроки: от 2 до 5 дней в зависимости от числа систем. Стоимость рассчитывается индивидуально. Закажите консультацию — оценим проект за 1-2 дня и подготовим коммерческое предложение. Получите прозрачность своих DR-метрик без авралов при реальной аварии. Наша гарантия качества — более 5 лет опыта и 50 успешных внедрений DR-систем. Свяжитесь с нами, чтобы запустить аудит.