Сообщить об ошибкеКороткий ответ
RPO (Recovery Point Objective) — максимально допустимый объём потерянных данных, измеряемый временем с последней консистентной точки восстановления; RTO (Recovery Time Objective) — максимально допустимое время простоя до восстановления сервиса.
Как это работает подробнее
RPO определяет, как часто нужно делать бэкапы или реплицировать данные (если RPO = 1 час, бэкапы раз в сутки не подходят), а RTO определяет, какие механизмы восстановления нужны (холодный бэкап восстанавливается медленно, горячая реплика — быстро).
Пример / кейс
Для интернет-магазина бизнес требует RPO ≤ 15 минут и RTO ≤ 1 час для базы заказов.
Ожидаемое поведение: нужна репликация базы с лагом менее 15 минут (например, логическая репликация или WAL-шиппинг) и готовый, многократно протестированный runbook восстановления, который укладывается в 1 час — простое "бэкап раз в сутки" этим требованиям не соответствует.
Что использовать на практике
- Практический подход. Эти метрики задают бизнес-владельцы продукта исходя из допустимых потерь, а инженеры подбирают архитектуру (частота бэкапов, репликация, автоматизация восстановления) под эти цифры. Без заранее согласованных RPO/RTO во время инцидента команда тратит время на споры "а что допустимо", вместо выполнения плана.
Подводные камни
- Частые ошибки. Считать, что RPO=0 достижим бесплатно для любой системы; не тестировать восстановление заранее, из-за чего реальное RTO оказывается в разы больше заявленного; путать RPO и RTO между собой.