RPO и RTO: сколько данных бизнес готов терять и как быстро восстанавливаться

RPO показывает, сколько данных компания готова потерять без критических последствий, а RTO — сколько времени можно потратить на восстановление работы после сбоя. Без этих двух цифр резервное копирование превращается в игру наугад: бэкапы делаются, но никто не знает, спасут ли они бизнес в реальной аварии.

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

RPO (Recovery Point Objective) — это допустимая точка возврата, то есть максимальный объём данных, который компания согласна потерять при сбое. Если бэкап делают раз в сутки, а авария случилась вечером, теряется вся информация за день — это и есть фактический RPO. RTO (Recovery Time Objective) — это допустимое время простоя, за которое систему нужно восстановить и вернуть в рабочее состояние.

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

Как понять, сколько данных компания готова потерять?

Чтобы определить RPO, нужно оценить, как быстро устаревают данные и насколько дорого обходится их потеря. Для интернет-магазина потеря заказов за час может означать реальные деньги и недовольных клиентов, а для внутреннего архива документов — вполне приемлемый риск. Универсального ответа нет: одни системы требуют бэкапа каждые несколько минут, другим достаточно резервной копии раз в сутки.

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

Как рассчитать RTO — время на восстановление?

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

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

Сумма этих этапов и даёт реальный RTO. Часто оказывается, что технически восстановить данные можно за минуты, а вот согласования и ручные проверки растягивают процесс на часы — и именно эти скрытые задержки нужно сокращать в первую очередь.

Что влияет на выбор конкретных значений RPO и RTO?

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

Важно понимать, что жёсткие RPO и RTO обычно стоят дороже: частое копирование нагружает инфраструктуру, а быстрое восстановление требует дублирующих мощностей. Поэтому задача — не стремиться к нулевым потерям во всём, а найти баланс между риском и затратами для каждой конкретной системы.

Какие ошибки чаще всего допускают компании?

Самая распространённая ошибка — вообще не задумываться о этих показателях и надеяться, что «бэкапы есть, значит, всё в порядке». Вторая по частоте — установить одинаковые требования для всех систем, хотя критичность у них разная. Третья — рассчитать RPO и RTO один раз и забыть про них, хотя бизнес растёт, объём данных увеличивается, а старые нормативы перестают соответствовать реальности.

Есть и обратная проблема: компании ставят слишком амбициозные цели — например, требуют восстановление за минуты, — но не выделяют на это ни бюджет, ни процессы. В итоге план существует только на бумаге.

Как RPO и RTO связаны с выбором стратегии резервного копирования?

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

Здесь свою роль играет и инфраструктура. Например, в облачных сервисах, включая аренду серверов через «Клауд АйСи», резервное копирование настраивается с учётом требуемых RPO и RTO: можно задать частоту создания копий и заранее подготовить ресурсы для быстрого восстановления, чтобы простой не растягивался на часы.

Как проверить, что реальные показатели соответствуют плановым?

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

Интересный и широко известный пример того, к чему приводит отсутствие продуманного восстановления — история с анимационным фильмом «История игрушек 2» на студии Pixar. Во время работы над фильмом важные файлы были случайно удалены прямо на рабочем сервере, а резервная копия оказалась неполной. Проект спасла сотрудница, у которой на домашнем компьютере хранилась личная копия рабочих файлов — иначе месяцы работы пришлось бы начинать заново. Этот случай стал классическим напоминанием: бэкап, который не проверен и не соответствует реальным потребностям, может не сработать в критический момент.

С чего начать расчёт RPO и RTO для своего бизнеса?

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

Такой подход избавляет от иллюзии, что «бэкапы есть — значит, всё под контролем», и превращает резервное копирование из формальной процедуры в реальный инструмент управления рисками.