RPO и RTO простыми словами: что это, как считать и как влияет на схему защиты

RPO и RTO - две цифры, на которых держится весь план восстановления после сбоя. RPO (Recovery Point Objective) - сколько данных вы готовы потерять: RPO в час значит, что после аварии допустимо откатиться на час назад. RTO (Recovery Time Objective) - за сколько сервис обязан снова заработать: RTO в четыре часа значит, что дольше простоя бизнес не выдержит. Первая цифра задаёт, как часто делать копии, вторая - каким способом восстанавливаться. Разберём обе на оси времени, как посчитать их под свой бизнес и какая схема защиты из них вырастает.

RPO и RTO на оси времени

Проще всего представить их на одной оси времени с точкой аварии посередине. Влево от точки смотрит RPO - сколько данных вы потеряете, откатившись к последней резервной копии. Вправо смотрит RTO - сколько времени сервис пролежит, пока вы его поднимаете.

И сразу важное: обе цифры работают только в паре. Можно героически поднять сервис за 15 минут (прекрасный RTO), но если репликация отставала на сутки, вы вернётесь ко вчерашним данным - RPO провален, и толку от скорости нет. Одна метрика без другой смысла не имеет.

RPO - сколько данных не жалко потерять

RPO отвечает на вопрос «на какой момент в прошлом мы откатимся, если сейчас всё рухнет». Это допустимый объём потерь, выраженный во времени между последней копией и аварией. Делаете копию раз в сутки ночью, а сервер умер вечером - теряете почти целый рабочий день, всё, что ввели после ночного бэкапа. Значит, фактический RPO у вас около суток, нравится это бизнесу или нет.

RPO напрямую задаёт частоту резервного копирования. Нужен RPO в час - делайте копии хотя бы раз в час. Нужен RPO около нуля, когда нельзя терять ни одной транзакции, - обычные копии не спасут, тут нужна непрерывная репликация данных на второй сервер.

RTO - как быстро вернуться в строй

RTO отвечает на вопрос «сколько бизнес проживёт без этого сервиса». Это срок от аварии до полного восстановления работы: поднять сервер, развернуть данные, проверить и запустить. RTO определяет другое - способ восстановления. Допустимы сутки простоя - можно спокойно поднимать новый сервер и разворачивать бэкап руками. Нельзя стоять дольше получаса - нужен заранее готовый резервный сервер, который подхватит нагрузку почти сразу.

Чем RPO отличается от RTO

Их легко перепутать, но это про разное: RPO - про данные (сколько потеряем), RTO - про время (сколько прождём). Они независимы: можно делать частые копии (маленький RPO), но долго их разворачивать (большой RTO), и наоборот.

Из чего на самом деле складывается RTO

Частая ошибка при оценке RTO - считать только время загрузки сервера. На деле восстановление - это цепочка, и каждый шаг ест время:

1. Обнаружение - заметили, что сервис упал (без мониторинга это уже могут быть часы).
2. Решение - поняли, что восстанавливаемся из резерва, а не чиним на месте.
3. Запуск - подняли резервный сервер или развернули бэкап.
4. Валидация - проверили, что данные целы и сервис реально работает.
5. Переключение - завели на него пользователей и нагрузку.

Валидация и переключение нередко съедают больше времени, чем сам запуск. Заложите все шаги в RTO, иначе цифра на бумаге окажется вдвое меньше реальной.

Как посчитать свои RPO и RTO

Цифры берут не с потолка, а из денег. Прикиньте стоимость часа простоя сервиса - упущенная выручка, простаивающие зарплаты, возможные штрафы и удар по репутации. Чем дороже простой, тем меньше нужен RTO. Так же оцените стоимость потерянных данных за период: сколько операций вводится в час и что будет, если они пропадут. Чем дороже потеря - тем меньше RPO.

И главное - не считайте всё одинаково критичным. База с заказами и архив пятилетних документов требуют разных цифр: первую поднимают за минуты, второй спокойно подождёт. Разделите сервисы по критичности и задайте каждому свои значения.

Какая схема защиты вырастает из ваших цифр

От пары значений напрямую зависит, что именно вы строите и сколько это стоит.

Резервное копирование закрывает RPO, а схема восстановления (от ручного разворачивания до горячего резерва) - RTO. Как выстроить сам бэкап - в материале руководство по созданию бэкапов, про схемы непрерывной доступности - в статье о высокодоступных кластерах, а как собрать полный план аварийного восстановления под бизнес - планирование аварийного восстановления.

Частые вопросы

Что такое RPO простыми словами?

Это допустимый объём потери данных, выраженный во времени. RPO в час означает, что при аварии можно потерять не больше часа данных, поэтому копии должны делаться хотя бы раз в час.

Что такое RTO простыми словами?

Это допустимое время простоя: за сколько сервис должен снова заработать после сбоя. RTO в четыре часа означает, что всё восстановление, включая запуск и проверку, должно укладываться в четыре часа.

Чем RPO отличается от RTO?

RPO про данные (сколько потеряем), RTO про время (сколько прождём восстановления). Это независимые величины: можно делать частые копии при маленьком RPO, но долго их разворачивать при большом RTO.

Что важнее - RPO или RTO?

Обе важны и работают в паре: быстрый RTO бесполезен при провальном RPO, и наоборот. Приоритет зависит от сервиса - где недопустима потеря данных, в первую очередь занижают RPO; где критичен простой - RTO.

Как рассчитать RPO и RTO?

Оцените стоимость часа простоя и стоимость потери данных за период для каждого сервиса, разделите сервисы по критичности и подберите цифры так, чтобы цена схемы защиты была соразмерна цене простоя.