Блог

RTO и RPO: что это такое и как использовать при выборе решения для бэкапа

2026-05-27 15:10
На совещании по непрерывности бизнеса финдиректор задаёт два вопроса - за сколько восстановим работу и сколько данных потеряем. У ИТ-отдела часто нет конкретных цифр. RTO и RPO формализуют разницу между «у нас есть бэкап» и подписанным обязательством.
RTO отвечает на вопрос «за сколько восстановим», RPO - «сколько потеряем». Это разные вопросы и разные решения. Ниже разберём метрики, методику расчёта и сопоставим архитектуры бэкапа с целевыми RTO/RPO.

Что такое RTO и что такое RPO - простыми словами

RTO (Recovery Time Objective) - целевое время восстановления. Сколько времени проходит от момента сбоя до возобновления работы. Если RTO 2 часа, значит при падении сервиса бизнес должен иметь рабочую систему через 2 часа максимум. RPO (Recovery Point Objective) - целевая точка восстановления: какой объём данных может быть потерян. Если RPO 15 минут, после сбоя данные восстанавливаются на момент не старше чем 15 минут назад. Всё, что было создано после - теряется.
RTO ближе к разговору с операционным директором: «сколько мы простоим». RPO к разговору с DBA: «сколько транзакций потеряем». Метрики ставятся на каждый сервис отдельно, и цена решения нелинейна: с 24 часов до 4 - относительно дёшево, с 4 часов до 30 минут - кратно дороже, с 30 минут до 1 минуты - ещё на порядок.

Чем RTO и RPO отличаются: два разных вопроса

RTO - про время простоя бизнеса

Время восстановления RTO - это интервал от инцидента до штатной работы, который складывается из обнаружения сбоя, решения о переключении, технических работ, проверки и допуска пользователей.
Для банковской системы RTO измеряется в минутах, для корпоративной 1С - 2–4 часа, для архивной кадровой - допустимо 24+ часов. Чем меньше RTO, тем дороже архитектура: горячий резерв, HA-кластер, DR-сайт. Типичная ошибка - указывать «RTO бэкапа», то есть время восстановления только серверной части. А пользователи ждут ещё возврат сети, рабочих мест и интеграций.

RPO - про объём потерянных данных

Точка восстановления RPO - момент, до которого данные восстановимы. Пример: RPO 1 час, сбой в 14:30 — данные возвращаются на 13:30, остальное теряется. RPO зависит от частоты бэкапов: ежедневный полный - около 24 часов, инкрементный почасовой - около 1 часа, непрерывная репликация транзакций - от секунд до минут.
Финансовые операции и торговля требуют RPO в секунды-минуты. Корпоративная переписка и документооборот живут с RPO час-два, архивы переносят RPO в сутки. Ловушка планирования: если бэкап идёт раз в сутки, а инцидент случился перед бэкапом, теряются почти полные сутки работы - это фактический RPO в худшем случае. Транзакционные БД требуют малых RPO (log shipping, CDP - Continuous Data Protection, непрерывное копирование изменений), файловые данные - нет.

Как считать RTO и RPO для своих систем

Не одна цифра на компанию: у каждой системы свои RTO и RPO. Прод 1С, корпоративная почта, веб-сайт и тестовые стенды имеют разную критичность.
  1. Перечислить все ИТ-системы с приоритизацией. Кто пользуется, как часто, что происходит при недоступности. На этом шаге составляется реестр критичности.
  2. Согласовать с владельцами бизнес-процессов. RTO для CRM ставит коммерческий директор, для 1С:Бухгалтерии - финдиректор, для сайта - маркетинг. Без согласований ИТ-отдел проектирует «в вакууме».
  3. Категоризировать. Tier 1 - критичные (RTO до 1 часа, RPO до 15 минут): прод-БД, торговая система, расчётные операции. Tier 2 - важные (RTO до 4 часов, RPO до 1 часа): корпоративная почта, документооборот, ERP. Tier 3 - обычные (RTO до суток, RPO до 24 часов): файловое хранилище, архивы, тестовые системы.
  4. Сопоставить с реальной стоимостью простоя. Если час простоя CRM - это убытки X рублей, а инфраструктура для RTO 30 минут стоит Y, компания выбирает осознанно.
  5. Зафиксировать в SLA с бизнесом. Без подписанного документа цели RTO/RPO остаются разговором за обедом. При инциденте проще, когда прописаны обязательства и ответственные.
Пересмотр - раз в год: бизнес растёт, системы меняются. Расчёт «один раз и навсегда» работает редко.

Как RTO и RPO влияют на архитектуру бэкапа

Соответствие классов бэкапа целевым RTO и RPO

Как выбрать решение для бэкапа - это всегда сопоставление целевых RTO/RPO с классом архитектуры. Готовых таблиц «RPO 1 час → такое-то решение» нет, но ориентиры стандартные.
Простой бэкап на диск или ленту, ежедневный или раз в несколько суток, даёт RPO 24 часа и RTO часы - подходит для архивов и систем второго эшелона. Дисковый бэкап с инкрементами (полная копия ночью, инкременты каждые 1–4 часа) даёт RPO 1–4 часа и RTO 1–4 часа - это стандарт для корпоративной 1С и документооборота среднего бизнеса. Реализуется на Veeam, Bacula, RuBackup, Proxmox Backup Server. Когда требуемые RTO и RPO зафиксированы, следующий шаг - подбор инфраструктуры под целевые показатели: оборудование для резервного копирования с поддержкой дедупликации, инкрементальных копий и аппаратного шифрования закладывает реалистичную базу под RPO 1–4 часа и RTO в диапазоне нескольких часов.
CDP - непрерывное копирование, RPO в секундах/минутах, RTO 10–30 минут. Применяется на критичных БД, требует выделенной инфраструктуры. Репликация на DR-сайт (активный или горячий резерв с синхронной или асинхронной репликацией) даёт RPO секунды-минуты и RTO 5–30 минут на переключение - стандарт для банков и телекома. HA-кластер с автоматическим переключением даёт RPO около 0 и RTO секунды-минуты, это самая дорогая архитектура. На практике методы совмещают. Гибридная схема выглядит так: HA-кластер закрывает сбои железа (RPO около 0, RTO секунды-минуты), ежечасный бэкап защищает от логических ошибок и случайного удаления (RPO 1 час, RTO 1–4 часа), еженедельный архив на DR-сайт страхует от потери ЦОД целиком (RPO 1 неделя, RTO 4–8 часов). Каждый уровень про свой класс угроз, в проде живут все три одновременно.

Типовые ошибки при работе с RTO и RPO

  1. Обещание бизнесу нереальных цифр без подсчёта стоимости. RTO 30 минут на пять критичных систем при бюджете в 200 тыс. ₽ - невыполнимое обязательство.
  2. Игнорирование связанных систем. Восстановили БД за 2 часа, но забыли про сервер приложений и интеграции - фактическое время до работы пользователей 6 часов.
  3. Невыполненные тесты восстановления. Бэкапы пишутся, мониторинг говорит «всё в порядке», но в боевом режиме их никто не разворачивал. При первом инциденте всплывает битый файл, забытая зависимость или протухшие учётки. Распространённая ошибка.
  4. RTO и RPO «раз и навсегда». Цифры, рассчитанные три года назад, давно неактуальны.
  5. Расчёт «по самому критичному». ИТ-отдел делает одну архитектуру под самые жёсткие RTO/RPO для всех систем сразу - архивная кадровая система живёт в HA-кластере. Переплата без отдачи.

Чего не делать

  1. Не путать RTO и RPO в разговоре с бизнесом. Это две разные цифры, описывающие разные риски. Типовая ошибка: финдиректор спрашивает «за сколько мы восстановим», ИТ отвечает «бэкап делаем каждый час» - это не ответ, это RPO 1 час. На вопрос «за сколько восстановим» нужно отвечать RTO: «полтора часа на разворачивание копии плюс полчаса на проверку, итого два часа». Подмена RTO ответом про RPO - главный источник неоправданных ожиданий и сорванных SLA.
  2. Не обещать SLA без подсчёта стоимости архитектуры. Бизнес часто хочет «всё за минуту», но не готов платить за HA-кластер. Цифры должны соответствовать бюджету.
  3. Не игнорировать восстановление зависимостей. Возврат основной БД - половина дела. Сервис заработает только после возврата сети, интеграций и балансировщиков.
  4. Не работать без регулярных тестов восстановления. Раз в квартал - тестовое восстановление на отдельный контур. Бэкап, который пишется, но никогда не разворачивался, в половине случаев на боевом инциденте отказывает: битый файл, забытая зависимость, протухшие учётки. Узнавать об этом в момент простоя - поздно.

Заключение

RTO и RPO - мостик между бизнес-требованиями к непрерывности и технической архитектурой. Без них планирование бэкапа превращается в «авось хватит», а инциденты в импровизацию. Правило одно: для каждой системы свои RTO и RPO, согласованные с владельцами бизнес-процессов и подписанные в SLA. Если требования по RTO и RPO выходят за пределы того, что внутренняя команда может покрыть скриптами и стандартным ПО, разумнее собрать систему резервного копирования как комплексный проект с регламентами тестирования и согласованным SLA, а не строить её по кусочкам.