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

На совещании по непрерывности бизнеса финдиректор задаёт два вопроса - за сколько восстановим работу и сколько данных потеряем. У ИТ-отдела часто нет конкретных цифр. 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. Не работать без регулярных тестов восстановления. Раз в квартал - тестовое восстановление на отдельный контур. Бэкап, который пишется, но никогда не разворачивался, в половине случаев на боевом инциденте отказывает: битый файл, забытая зависимость, протухшие учётки. Узнавать об этом в момент простоя - поздно.

Как проверить RPO и RTO на практике: пошаговый регламент учений

Значения RPO и RTO, записанные в SLA, часто не подтверждены реальностью. Показатель «восстанавливаемся за 4 часа» превращается в 12 часов, потому что бэкапы читались с медленной ленты, а инженер, который знает пароль, был в отпуске. Регламент учений закрывает этот разрыв.

Что фиксировать до старта учений. Три параметра - целевой RPO и RTO по SLA, критичные системы из перечня, ответственный за каждую роль (бэкап-оператор, сетевой инженер, владелец сервиса, представитель бизнеса). Учения без владельца сервиса бесполезны - только он может подтвердить, что восстановленная система работает корректно.

Кто участвует. Минимум 4 роли: ИТ-специалист по резервному копированию (запускает восстановление), сетевой инженер (проверяет доступность), владелец бизнес-процесса (проверяет функциональность), наблюдатель (фиксирует таймлайн, не помогает). Наблюдатель критически важен - без него замеры оптимистичные.

Что замерять. По шкале от момента объявления инцидента до момента, когда бизнес-процесс работает:

1. T1 - время принятия решения о восстановлении (обычно 15-60 минут).
2. T2 - время подготовки инфраструктуры (провижининг ВМ, настройка сети).
3. T3 - время восстановления данных из копии.
4. T4 - время проверки функциональности бизнесом.

Итого RTO = T1 + T2 + T3 + T4.

Реальное значение RPO - разница между моментом инцидента и меткой времени последней успешной копии, из которой восстановились. Часто оказывается больше SLA, потому что часть копий за последние N часов оказалась битой.

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

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

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

Практика показывает 5 системных ошибок, которые превращают красивые цифры SLA в реальные простои и потери данных.

Ошибка 1. RTO без учёта времени решения об эскалации. SLA часто пишется «восстановление за 4 часа», а замер стартует с момента, когда бэкап-оператор уже сел за консоль. В реальности между инцидентом и стартом восстановления проходит 30-90 минут: мониторинг сработал, дежурный связался с ответственным, ответственный принял решение об эскалации, инженер добрался до консоли. Правильный RTO включает эти минуты, иначе SLA систематически нарушается.

Ошибка 2. RPO по устаревшему объёму данных. SLA пишется 3 года назад для базы 500 ГБ, сейчас база выросла до 5 ТБ. Время бэкапа выросло с 30 минут до 4 часов, значит RPO уже не тот, что в SLA. Пересматривать RPO/RTO нужно раз в год или при росте объёма данных на 30%.

Ошибка 3. Забытые интеграции. Восстановили основную БД, а внешние сервисы (платёжка, СМС-шлюз, CRM-интеграция) на восстановленную БД не смотрят, потому что настройки IP или API-ключа поменялись. Функционально система «работает», но бизнес-процесс не идёт. Учения ловят такие разрывы.

Ошибка 4. Отсутствие проверки резервных копий. Копии делаются, показатель «успешность бэкапа = 100%» есть в мониторинге, а из них никто ни разу не восстанавливал. Реальная статистика - 5-10% копий оказываются нечитаемыми при попытке восстановления. Регламент - раз в месяц пробное восстановление одной случайной копии на тестовый стенд.

Ошибка 5. RPO=0 как маркетинговая иллюзия. SLA-показатель «RPO=0» технически возможен через синхронную репликацию между двумя площадками, но требует канала с гарантированной задержкой, специальной СХД и удвоения затрат на инфраструктуру. Для 90% бизнеса реальный экономически обоснованный RPO - 15 минут для критичных систем и 1-24 часа для остальных.

Если по этому чек-листу становится понятно, что текущие RPO/RTO - из SLA, а не из реальности, стартовая точка - услуга аудита ИТ-инфраструктуры с проверкой резервных копий и замером фактических значений.

Заключение

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

Заполните форму, и мы проведём бесплатный аудит: проверим серверы, сети и системы безопасности, определим риски и предложим план перехода на отечественное оборудование.