Ответ
RPO (Recovery Point Objective) — это целевая точка восстановления, максимально допустимый период времени, за который могут быть потеряны данные из-за инцидента. По сути, это ответ на вопрос: "Насколько старыми данными мы можем позволить себе восстановиться?"
Практическая интерпретация для DevOps: Если RPO = 15 минут, это означает, что процедуры резервного копирования и репликации должны быть настроены так, чтобы в худшем случае мы потеряли не более 15 минут изменений данных.
Как достигаются разные значения RPO:
- RPO = 24 часа: Достаточно ежедневных (ночных) полных или инкрементных бэкапов.
- RPO = 1 час: Требуется более частое бэкапирование (например, каждый час) или асинхронная репликация транзакций.
- RPO ~ 0 (близко к нулю): Требуется синхронная репликация данных, когда каждая операция записи подтверждается только после сохранения на основном и резервном узле. Это дорого и влияет на производительность.
Пример из практики для базы данных:
- Сценарий: Веб-приложение с PostgreSQL.
- Требование бизнеса: Не потерять заказы пользователей.
- Установленный RPO: 5 минут.
- Реализация в DevOps-стеке:
- Настройка непрерывного архивирования WAL (Write-Ahead Logging) в PostgreSQL.
- WAL-логи архивируются в объектное хранилище (например, S3) каждые 2 минуты.
- В случае аварии основного кластера, резервный кластер разворачивается из последнего полного бэкапа и применяет все архивные WAL-логи, что позволяет восстановить данные с точностью до последнего переданного WAL-сегмента.
Важно не путать:
- RPO (Recovery Point Objective) — точка во времени (какие данные мы теряем).
- RTO (Recovery Time Objective) — промежуток времени (как быстро система снова станет доступной). Можно иметь низкий RTO (быстро поднять сервис), но высокий RPO (восстановить старые данные), и наоборот.