RPO и RTO простыми словами: сколько данных можно потерять

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

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

Два вопроса, на которые отвечают RPO и RTO

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

Как выбрать значения: считаем цену потерь

Правильный способ — посчитать, сколько стоит час простоя и час потерянных данных, и сравнить со стоимостью защиты. Для этого ответьте на вопросы по каждой системе.

• Сколько денег проходит через систему в час в рабочее время? Для интернет-магазина — выручка, для CRM — сделки, которые нельзя провести.
• Можно ли восстановить потерянные данные вручную? Заказы из почты — да, частично; записи клиентов, сделанные онлайн, — нет.
• Что будет с репутацией, если клиенты не смогут записаться или оплатить несколько часов?
• Есть ли обязательства по договорам или закону — например, хранение документов и персональных данных?
• Работает ли бизнес круглосуточно или только днём?

Типовые значения для разных систем

Сколько стоит каждый уровень

Стоимость растёт нелинейно: перейти от RPO в сутки к RPO в час обычно недорого, а от часа к минутам — дорого. Ориентиры для небольшой CRM или магазина на одном сервере.

Пример расчёта для CRM с онлайн-записью

Условная сеть салонов: через CRM проходит 400 записей в день, средний чек 2 500 ₽, работа с 9 до 21 часа. Записи делаются онлайн и администраторами.

1. Цена часа данных: за час создаётся около 33 записей. Если они потеряны, часть клиентов не придёт, потому что не знает, что запись пропала. Допустим, теряется 30% — 10 визитов, 25 тыс. ₽ выручки.
2. Цена часа простоя: администраторы не видят расписание, онлайн-запись не работает. Допустим, теряется 20 записей в час — 50 тыс. ₽ выручки, плюс хаос на ресепшене.
3. Текущий уровень: ежедневная копия ночью, восстановление вручную — RPO до 24 часов, RTO около 8 часов. Худший сценарий сбоя в 20:00: потеря дня записей (около 250 тыс. ₽) плюс 8 часов простоя на следующий день (до 400 тыс. ₽).
4. Целевой уровень: RPO 15 минут, RTO 1 час. Худший сценарий: потеря 6 тыс. ₽ и 50 тыс. ₽ простоя.
5. Стоимость перехода: настройка — 60–120 тыс. ₽ разово, плюс 15 тыс. ₽ в месяц. Один предотвращённый крупный сбой окупает несколько лет такой защиты.

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

RPO и RTO в договоре с подрядчиком

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

Как проверить, что RTO — правда

Единственный способ — восстановить систему из копии на тестовом сервере и засечь время. На практике первая проверка почти всегда показывает сюрпризы: копия неполная, нет файлов, забыт ключ шифрования, инструкция устарела, восстановление базы на 30 ГБ занимает не час, а шесть. Лучше узнать это на учениях, чем во время аварии.

1. Раз в квартал восстанавливайте последнюю копию на отдельном сервере по инструкции, не подглядывая в память администратора.
2. Засекайте время от решения «восстанавливаем» до момента, когда сотрудник может работать.
3. Сверяйте данные: последние записи, файлы, вход пользователей.
4. Обновляйте инструкцию по итогам каждого прогона.
5. Если время не укладывается в RTO, решайте: менять архитектуру или пересматривать цель.

Правило 3-2-1 и где оно встречается с RPO

RPO отвечает на вопрос «как часто копировать», но не на вопрос «где хранить». Для этого есть известное правило 3-2-1: три копии данных, на двух разных типах носителей или в двух разных системах, одна из них — вне основной площадки. В 2026 году к нему часто добавляют ещё две цифры: одна копия неизменяемая или изолированная от сети, чтобы шифровальщик не смог её зашифровать, и ноль ошибок при проверке восстановления. Вместе это и даёт уверенность, что заявленный RPO сработает в реальной аварии, а не только на бумаге.

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

Облачная CRM: что спросить у поставщика

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

План аварийного восстановления на одной странице

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

Типичные ошибки

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

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

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

Если хотите определить RPO и RTO для своих систем и настроить резервное копирование с проверкой восстановления — напишите нам. Мы делаем это в рамках поддержки и услуг по кибербезопасности. Подобрать уровень защиты под свои цифры помогут калькулятор RPO и RTO и калькулятор SLA и аптайма.