RPO и RTO: два числа, из которых растёт схема

Зачем считать

«Делаем бэкапы раз в сутки» это ответ без вопроса. Вопрос звучит иначе: сколько данных бизнес готов потерять и сколько времени готов лежать. Ответы на них называются RPO и RTO, и всё остальное вытекает из этих двух чисел.

RPO: глубина потери

RPO (Recovery Point Objective) — сколько данных не жалко потерять, измеряется во времени.

RPO это требование, а не отчёт: сначала бизнес называет допустимую потерю, потом под неё подбирают расписание. Суточный бэкап в три часа ночи удовлетворяет RPO в 24 часа, но не меньше: авария в два часа дня унесёт всё, что произошло с трёх ночи. Нужен RPO в час — бэкап раз в час. Непрерывная архивация журнала транзакций опускает потерю до минут, а секунды даёт уже потоковая доставка журнала или синхронная репликация.

Считать надо не в файлах, а в деньгах и договорённостях. Потерянный день заказов интернет-магазина это конкретная сумма и конкретные звонки клиентам. Потерянный день логов сборки не стоит почти ничего.

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

RTO: длина простоя

RTO (Recovery Time Objective) — за какое время сервис обязан вернуться в строй.

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

Именно поэтому RTO обычно проваливают не из-за скорости диска. Час уходит на то, чтобы понять, что вообще случилось, ещё час на поиск человека с доступами, и только потом начинается собственно восстановление.

Прикиньте на своём сервисе: сколько займёт скачать 200 ГБ из объектного хранилища по вашему каналу? Развернуть дамп базы такого размера? Пересобрать конфигурацию сервера? Сложите это, и получится честный RTO.

Как числа превращаются в схему

RPO диктует частоту и способ:

• сутки — достаточно ночного дампа;
• часы — дампы чаще плюс снапшоты;
• минуты — непрерывная архивация журнала (для Postgres это WAL);
• секунды — потоковая доставка журнала или синхронная репликация.

RTO диктует форму хранения:

• жёсткий RTO — держите последнюю копию рядом и в готовом к разворачиванию виде, иначе скачивание съест весь срок;
• мягкий RTO — можно уводить архивы в холодное хранилище, где хранение дешевле, а выемка занимает часы.

Отсюда типичный многослойный вариант: горячая копия за сегодня рядом, недельные архивы в объектном хранилище, месячные в холодном классе.

Кто назначает цифры

Не инженер. RPO и RTO это решение бизнеса, потому что за ними стоят деньги: и убыток от простоя, и стоимость инфраструктуры, которая этот простой сокращает.

Задача инженера — перевести пожелание в стоимость. «Хотим RPO ноль и RTO пять минут» это не бэкапы, это горячий резерв в другом регионе с непрерывной репликацией, и стоит он кратно дороже ночного дампа. Когда цифры сравнивают с ценой, требования обычно становятся реалистичнее.

Фиксируйте согласованные значения письменно. В момент аварии «мы вроде договаривались на четыре часа» работает плохо.

Что важно запомнить

RPO это допустимая потеря данных во времени, RTO — допустимое время простоя.

У разных данных в одном проекте RPO разный: база заказов и кеш не равны.

RPO задаёт частоту бэкапов, RTO — где и в каком виде их держать.

RTO съедается не столько восстановлением, сколько обнаружением аварии и поиском ответственного.

Цифры назначает бизнес, инженер показывает их цену.

Дальше разберём правило 3-2-1: где именно должны лежать копии, чтобы одна авария не убила все сразу.