Налаштування моніторингу RPO/RTO для DR compliance

#!/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 порушує RTO при перевищенні заданого порогу:

---
- 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 годин на етапі тестування. Без автоматизації середній час виявлення проблеми — 4 години, з автоматизацією — 30 хвилин.

Як налаштувати моніторинг 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 порушує RTO при перевищенні заданого порогу:

---
- 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 з навчань за часом, відображає тренд і дозволяє прогнозувати проблеми.