Настройка RTO/RPO для проекта 1С-Битрикс
Бизнес говорит: «сайт не должен лежать больше часа». Инженер кивает и уходит настраивать репликацию. Через полгода выясняется, что восстановление из последнего бекапа занимает 4 часа, а бизнес об этом не знал. RTO и RPO — это не технические характеристики, это договорённости с бизнесом, которые нужно зафиксировать и технически обеспечить.
Что такое RTO и RPO применительно к Битрикс
RPO (Recovery Point Objective) — максимально допустимая потеря данных. Если RPO = 1 час, значит при катастрофе можно потерять не более часа транзакций: заказов, регистраций, изменений остатков.
RTO (Recovery Time Objective) — максимально допустимое время недоступности. Если RTO = 30 минут, значит через 30 минут после инцидента сайт должен работать.
Типичные значения для интернет-магазина на Битрикс: RPO = 1 час, RTO = 2 часа. Для highload-проектов: RPO = 5 минут, RTO = 15 минут. Чем жёстче требования — тем дороже инфраструктура.
Технические решения для разных уровней RPO
RPO = несколько часов. Достаточно ежечасного pg_dump во внешнее хранилище. Просто, дёшево, долго восстанавливается при больших базах.
RPO = минуты. Streaming replication PostgreSQL с синхронным режимом (synchronous_commit = on). Каждая транзакция подтверждается только после записи на реплику. Стоимость: +5–15 мс к каждой транзакции.
RPO = секунды. Patroni с синхронной репликацией + непрерывное архивирование WAL через archive_command в S3. При WAL-архивировании можно восстановить базу на любой момент времени (PITR — Point-in-Time Recovery).
# postgresql.conf для PITR
archive_mode = on
archive_command = 'aws s3 cp %p s3://backup-bucket/wal/%f'
Технические решения для разных уровней RTO
RTO = несколько часов. Восстановление из pg_dump + деплой кода из git. Линейно зависит от размера базы: 10 ГБ — примерно 45–90 минут восстановления.
RTO = 30–60 минут. Standby-сервер с горячей репликой. При инциденте — ручной failover: промоция реплики, смена DNS или конфига приложения. Не автоматически, но быстро.
RTO = менее 10 минут. Автоматический failover через Patroni + HAProxy. Без участия человека. Требует предварительной настройки и регулярного тестирования.
Матрица решений для Битрикс
| Размер проекта | RPO | RTO | Инфраструктура |
|---|---|---|---|
| До 5k заказов/сутки | 1 час | 4 часа | pg_dump в S3, деплой из git |
| 5–50k заказов/сутки | 15 мин | 1 час | Streaming replica + ручной failover |
| Свыше 50k заказов/сутки | 1 мин | 10 мин | Patroni + HAProxy + WAL archiving |
Расчёт реального RTO: что входит во время восстановления
Время восстановления — это сумма всех шагов, а не только «восстановить базу»:
- Обнаружение инцидента — от 0 до 15 минут (зависит от мониторинга)
- Принятие решения о failover — 5–10 минут
- Восстановление/промоция БД — зависит от RPO-решения
- Смена конфигурации приложения — 2–5 минут
- Прогрев кешей — первые запросы после восстановления медленные, Redis/memcached пустые
- Проверка работоспособности — 5–10 минут
Пункт «прогрев кешей» часто игнорируется в расчётах RTO. После восстановления база принимает нагрузку с нуля: кеш Битрикс пустой, OPcache холодный. Первые 5–10 минут работы — пиковая нагрузка на БД. Если нет rate limiting, это может повалить только что поднятый сервер.
Документирование и тестирование
RTO/RPO без задокументированного runbook — ничто. Runbook должен содержать точную последовательность команд для каждого сценария отказа: падение primary БД, падение веб-сервера, потеря /upload/, компрометация сервера.
# Пример раздела runbook: failover PostgreSQL (ручной)
# 1. Проверить, что primary недоступен
pg_isready -h primary.db -p 5432
# 2. Промотировать реплику
ssh replica.db 'pg_ctl promote -D /var/lib/postgresql/data'
# 3. Обновить конфиг Битрикс
sed -i "s/primary.db/replica.db/" /var/www/bitrix/.settings.php
# 4. Очистить кеш
php /var/www/bitrix/bitrix/modules/main/cli/cache_clear.php
Что настраиваем
- Определение целевых RPO и RTO совместно с бизнесом
- Выбор и настройку инфраструктурного решения под заданные параметры
- WAL-архивирование для PostgreSQL PITR при RPO < 15 минут
- Runbook с командами восстановления для каждого сценария отказа
- Регламент тестирования: ежеквартально поднимаем из бекапа, замеряем реальный RTO