RPO (Recovery Point Objective) — бизнес-параметр, определяющий максимально допустимую давность резервной копии при восстановлении после сбоя. RPO = 24 часа означает: можно потерять не более 24 часов данных. Этот показатель определяет частоту резервного копирования.
Как работает
RPO — точка во времени, до которой данные должны быть восстановлены. Если сервер упал в 14:00 с RPO=1 час, последний бэкап должен быть не ранее 13:00. Всё, что произошло между 13:00 и 14:00, будет потеряно — и это приемлемо согласно бизнес-требованиям.
Связанный показатель — RTO (Recovery Time Objective): максимальное допустимое время восстановления работоспособности системы. RPO отвечает на вопрос «сколько данных можно потерять», RTO — «сколько времени может простаивать система».
Для достижения RPO = 0 (zero data loss) используются синхронная репликация данных: транзакция считается завершённой только после записи на реплику. Это повышает latency на 5-50 мс в зависимости от расстояния между ЦОДами.
История
RPO и RTO как формальные метрики DR (Disaster Recovery) оформились в 1980-90-х годах с развитием корпоративных систем хранения. Стандарт BS 25999 (2006) и ISO 22301 (2012) включили RPO/RTO как обязательные метрики в планах непрерывности бизнеса.
Примеры RPO по типам бизнеса
- Банк, биржа — RPO = 0, синхронная репликация, нулевые потери данных.
- E-commerce — RPO = 15-60 минут, транзакционная БД реплицируется.
- Корпоративный портал — RPO = 24 часа, ежесуточный бэкап.
- Личный сайт / блог — RPO = 7 дней, еженедельный бэкап.
Связь с хостингом
RPO определяет выбор технологии резервного копирования на хостинге: ежесуточные инкрементальные бэкапы от хостера дают RPO=24 часа. R1Soft CDP (Continuous Data Protection) даёт RPO в минуты. Синхронная репликация баз данных в разные ЦОДы — RPO около 0. Точка восстановления — практическое воплощение RPO.
Ключевые отличия от похожих терминов
RTO — время восстановления работоспособности (сколько часов будет простой). RPO — давность восстанавливаемых данных (сколько данных потеряем). Оба показателя включаются в SLA на уровне enterprise-соглашений.
RPO и частота резервного копирования
RPO (Recovery Point Objective) — максимально допустимая потеря данных по времени. RPO = 24 часа: ежедневные бэкапы достаточны. RPO = 1 час: ежечасные инкрементальные. RPO = 0: синхронная репликация БД. Чем меньше RPO — тем дороже инфраструктура резервирования.
RPO по типам данных
Транзакционные данные (заказы, оплаты): RPO = 0–15 минут. Контент сайта: RPO = 24 часа. Логи: RPO = 7 дней (или не резервировать). Медиафайлы: RPO = 24–72 часа. Для RPO < 1 часа: WAL archiving в PostgreSQL, binlog в MySQL — непрерывный поток изменений.
RPO vs RTO
RTO (Recovery Time Objective) — время на восстановление. RPO = потеря данных. Пример: RPO=1 час, RTO=4 часа. SLA хостинг-провайдера должен покрывать оба параметра. Проверка: учения по disaster recovery — реальное тестирование, не только на бумаге.
RPO в Kubernetes
Stateless приложения в Kubernetes: RPO=0 (нет состояния). Stateful (базы данных через StatefulSet): RPO определяется частотой снапшотов PersistentVolume. Velero — бэкап Kubernetes ресурсов + PV. Kasten K10 — enterprise решение для backup/restore Kubernetes workloads.