RPO, RTO и Disaster Recovery: как спланировать восстановление
RPO и RTO — две ключевые метрики плана аварийного восстановления (Disaster Recovery, DR). **RPO (Recovery Point Objective)** — сколько данных вы готовы потерять, измеряется в «глубине» назад от инцидента: если бэкап раз в сутки, RPO ≈ 24 часа. **RTO (Recovery Time Objective)** — за сколько сервис должен вернуться в строй после сбоя. Чем ниже обе величины — тем дороже инфраструктура восстановления. **Если коротко:** DR-план начинается не с покупки железа, а с анализа влияния на бизнес (BIA) — он показывает, какие сервисы критичны и какие RPO/RTO для них допустимы. Дальше под эти цели подбирается уровень DR (от холодного резерва до горячего geo-репликации), пишется runbook и проводятся регулярные учения. Без тестирования DR-план — это документ, а не способность восстановиться. Сравнить поставщиков резервного копирования по подтверждённым сигналам можно в [рейтинге СРК](/rating/backup-ransomware-resilience).
Бэкап ценен только после проверки восстановления
Защита от шифровальщиков опирается на изоляцию копий, immutable-хранилища и регулярные проверки RPO/RTO.
Рейтинги подрядчиков по теме исследования
Если после чтения нужен короткий список исполнителей, начните с профильных рейтингов cyber-index.ru: в них видны компании, кейсы, интервью, категории экспертизы и доверительный индекс.
Как проверять выводы исследования
Используйте материал как основу для shortlist: сопоставьте выводы с профилями компаний, связанными рейтингами, кейсами, интервью клиентов и источниками. Если в статье есть список источников, начинайте проверку с него; если источников мало, дополнительно запросите у подрядчика методику, baseline и примеры работ.
Авторы и проверка материала
У каждого исследования есть персональные авторы, профиль экспертизы, дата публикации, список источников и редакционная проверка выводов.
author
Антон Смирнов
Старший редактор исследований ИБ-рынка
Ведет исследования по категориям ИБ, публичным источникам и критериям выбора поставщиков.
- 7 лет в SEO-аналитике и редакционных B2B-исследованиях
- Специализация: ИБ-категории, entity-based SEO и факторы E-E-A-T
author
Полина Лебедева
Исследователь рынка ИБ-поставщиков
Собирает и сравнивает данные по подрядчикам, услугам, публичным кейсам, ценовым диапазонам и рыночным сегментам.
- 5 лет в market research, digital-аналитике и конкурентных обзорах
- Специализация: ИБ-поставщики, сервисные категории, прайс-анализ и case review
Авторы закреплены по теме исследования и опираются на практические разборы страниц, кейсов, источников и рыночных выборок.
В профиле автора указаны зона экспертизы, роль в редакции, регалии и темы, за которые он отвечает.
Материалы связаны с методологией cyber-index.ru, внутренними рейтингами, карточками компаний и источниками.
Позиции не продаются, выводы отделены от рекламы, а проверяемые утверждения поддержаны источниками и датами обновления.
Что значат RPO и RTO простыми словами
Представьте сбой в 14:00. Две метрики отвечают на два разных вопроса.
**RPO** отвечает: «На какой момент мы сможем восстановить данные?» Если последняя консистентная резервная копия снята в 02:00, а инцидент в 14:00, то потеряно 12 часов работы — это и есть фактический RPO. Целевой RPO задаёт, как часто нужно делать бэкапы или реплицировать данные: RPO в 15 минут требует почти непрерывной репликации, RPO в сутки — достаточно ночного бэкапа.
**RTO** отвечает: «Как быстро сервис снова заработает?» Сюда входит всё: обнаружение инцидента, решение о переключении, развёртывание из копии или активация резервной площадки, проверка целостности и возврат пользователей. RTO в 1 час и RTO в 3 дня — это принципиально разные архитектуры и бюджеты.
Важно: RPO и RTO задаются **для каждого сервиса отдельно**. Биллинг и ДБО могут требовать RTO в минуты, а корпоративный файловый архив — спокойно жить с RTO в сутки.
RPO и RTO: коротко в цифрах
«Глубина» назад до последней пригодной копии
От сбоя до возврата сервиса в строй
Анализ влияния на бизнес задаёт целевые RPO/RTO
3 копии, 2 носителя, 1 вне площадки
DR-план без тестов — документ, а не способность
С чего начинается DR-план: BIA
Анализ влияния на бизнес (Business Impact Analysis, BIA) — фундамент всего плана. Его задача — перевести разговор из «нам нужно надёжно» в измеримые цели по каждому сервису:
- **Каталог сервисов и зависимостей.** Какие системы есть, что от чего зависит (приложение не поднимется без БД, БД — без сети и каталога пользователей). - **Критичность и стоимость простоя.** Сколько компания теряет за час недоступности — деньгами, клиентами, штрафами, репутацией. - **Целевые RPO и RTO.** Для каждого сервиса фиксируются допустимая потеря данных и допустимое время восстановления — отсюда растёт вся архитектура DR. - **Приоритеты восстановления.** В каком порядке поднимать сервисы: сначала аутентификация и сеть, затем ядро бизнеса, затем вспомогательное.
Без BIA легко переплатить за «горячий» DR там, где хватило бы суточного бэкапа, — или, наоборот, недозащитить критичный сервис.
Уровни DR: связь RPO/RTO и стоимости
| Уровень DR | Типичный RPO | Типичный RTO | Относительная стоимость |
|---|---|---|---|
| Backup & Restore (холодный) | часы — сутки | часы — дни | низкая |
| Pilot Light | минуты — часы | десятки минут — часы | средняя |
| Warm Standby (тёплый резерв) | минуты | минуты — десятки минут | высокая |
| Hot Standby / Active-Active | секунды — около нуля | секунды — минуты | очень высокая |
Как растёт относительная стоимость DR при снижении RTO
Усреднённая редакционная оценка зависимости «стоимость от целевого RTO» по открытым данным. Это иллюстрация принципа, а не ценник конкретного решения.
Runbook: что должно быть в плане восстановления
Runbook — это пошаговая инструкция действий при аварии, написанная так, чтобы по ней мог действовать и дежурный, а не только автор системы. В нём обычно фиксируют:
- **Триггеры и роли.** Что считается аварией, кто объявляет DR, кто за что отвечает, контакты и эскалация. - **Порядок восстановления.** Конкретные шаги для каждого сервиса с учётом зависимостей и приоритетов из BIA. - **Где данные и копии.** Расположение бэкапов, ключей шифрования, учётных данных; проверка правила 3-2-1 и неизменяемости копий. - **Критерии готовности.** Как понять, что сервис восстановлен корректно (проверки целостности, дымовые тесты, согласование с владельцем). - **Возврат в норму.** Процедура обратного переключения на основную площадку и пост-инцидентный разбор.
Чек-лист зрелости DR-плана
Как разработать DR-план: 6 шагов
-
01
Анализ влияния (BIA)
Соберите каталог сервисов и зависимостей, оцените стоимость простоя, зафиксируйте критичность.
-
02
Цели RPO/RTO
Для каждого критичного сервиса согласуйте с владельцами допустимую потерю данных и время восстановления.
-
03
Выбор уровня DR
Под цели подберите архитектуру: от холодного восстановления из бэкапа до горячего резерва с репликацией.
-
04
Реализация и копии
Настройте бэкап/репликацию, правило 3-2-1 и неизменяемые копии, разверните резервные мощности.
-
05
Runbook и роли
Опишите пошаговые процедуры, назначьте ответственных, эскалацию и каналы связи; держите офлайн-копию.
-
06
Тестирование и пересмотр
Проводите учения, измеряйте фактические RPO/RTO, устраняйте разрывы и обновляйте план после изменений.
Тестирование: почему без него DR не работает
Самая частая ошибка — считать DR-план готовым после того, как он написан. На практике расхождение между **целевыми** и **фактическими** RPO/RTO выясняется только на учениях: бэкап оказывается повреждённым, восстановление упирается в забытую зависимость, ключи шифрования недоступны, а реальное время cutover в разы больше плана.
Поэтому учения проводят регулярно и по нарастающей: от «настольных» разборов сценария до полного восстановления критичного сервиса на резервной площадке. После каждого теста фиксируют фактические метрики, закрывают найденные разрывы и обновляют runbook. Отдельно проверяют защиту копий от шифровальщиков — см. [immutable backup и правило 3-2-1](/research/immutable-backup-zashchita-ransomware).
Как мы оцениваем поставщиков
cyber-index.ru не продаёт места в рейтинге. Поставщики систем резервного копирования сравниваются по проверяемым сигналам: подтверждённые внедрения и кейсы, отзывы клиентов, внешняя репутация, специализация, прозрачность и свежесть данных. Поэтому статью стоит читать в связке с [рейтингом СРК](/rating/backup-ransomware-resilience): здесь — метрики и методология DR, там — сравнение конкретных решений по подтверждённым фактам.
Следующий шаг
Определились с целями RPO/RTO — переходите к выбору инструментов резервного копирования: **[рейтинг систем резервного копирования →](/rating/backup-ransomware-resilience)**. Полезно прочитать рядом: [рейтинг российских СРК 2026](/research/reyting-srk-rossiya-2026), [чем заменить Veeam, Commvault и Acronis](/research/zamena-veeam-commvault-acronis) и [immutable backup и правило 3-2-1](/research/immutable-backup-zashchita-ransomware).
Частые вопросы
Чем RPO отличается от RTO?
RPO — это допустимая потеря данных (как далеко назад придётся откатиться к последней копии), а RTO — допустимое время простоя (как быстро сервис вернётся в строй). RPO влияет на частоту бэкапов и репликации, RTO — на архитектуру восстановления.
Какие RPO и RTO «правильные»?
Универсальных значений нет — они задаются под каждый сервис по итогам BIA, исходя из стоимости простоя и потери данных. Для критичных систем (ДБО, биллинг) цели жёстче и дороже, для архивов — мягче. Конкретные цифры считаются под вашу инфраструктуру.
Чем DR отличается от обычного резервного копирования?
Бэкап — это копии данных; DR — это способность восстановить работу сервиса в целом (данные, инфраструктура, процедуры, роли). Бэкап входит в DR как один из элементов, но сам по себе не гарантирует возврата в строй за нужное время.
Зачем нужны DR-учения, если план уже написан?
Только тест показывает фактические RPO/RTO и вскрывает скрытые проблемы: повреждённые копии, забытые зависимости, недоступные ключи. Без регулярных учений DR-план остаётся документом, а не реальной способностью восстановиться.
Где сравнить поставщиков систем резервного копирования?
В рейтинге систем резервного копирования — там решения ранжированы по подтверждённым сигналам, а не по рекламе.
Источники и метод проверки
RPO и RTO — две ключевые метрики плана аварийного восстановления (Disaster Recovery, DR). **RPO (Recovery Point Objective)** — сколько данных вы готовы потерять, измеряется в «глубине» назад от инцидента: если бэкап раз в сутки, RPO ≈ 24 часа. **RTO (Recovery Time Objective)** — за сколько сервис должен вернуться в строй после сбоя. Чем ниже обе величины — тем дороже инфраструктура восстановления. **Если коротко:** DR-план начинается не с покупки железа, а с анализа влияния на бизнес (BIA) — он показывает, какие сервисы критичны и какие RPO/RTO для них допустимы. Дальше под эти цели подбирается уровень DR (от холодного резерва до горячего geo-репликации), пишется runbook и проводятся регулярные учения. Без тестирования DR-план — это документ, а не способность восстановиться. Сравнить поставщиков резервного копирования по подтверждённым сигналам можно в [рейтинге СРК](/rating/backup-ransomware-resilience).