RPO и RTO: сколько данных и времени компания может позволить себе потерять
После атаки шифровальщика первый вопрос, который задаёт руководство, звучит не «как это случилось», а «когда всё снова заработает» и «что мы потеряли». Ответ на оба вопроса должен был существовать ещё до атаки — в виде двух простых на первый взгляд метрик: RPO и RTO. Мы уже упоминали кейс производственной компании, которая всерьёз занялась бэкапами после атаки на конкурента. Так вот, первым шагом там было вовсе не разворачивание Veeam, а разговор с руководством цехов и бухгалтерией — сколько часов работы они готовы потерять и сколько часов простоя способны пережить без остановки производства.
Без этих двух чисел любая стратегия резервного копирования строится наугад: можно поставить дорогое оборудование и настроить бэкапы каждые пять минут там, где хватило бы раза в сутки, а критичную систему оставить с ежедневным бэкапом, хотя простой в час стоит компании миллион рублей. Разберём, что это за метрики, как их считать и как они превращаются в конкретные настройки заданий на сервере srv-backup01.
Что такое RPO
RPO (Recovery Point Objective) — это допустимый объём потерянных данных, измеряемый во времени. Если RPO для базы 1С равен 4 часам, это значит: в худшем случае компания готова смириться с потерей данных за последние 4 часа работы — то есть с тем, что придётся заново вносить документы, оформленные за это время. RPO напрямую определяет, как часто нужно снимать резервные копии или реплицировать данные.
Как RPO влияет на расписание бэкапов
Если для системы установлен RPO = 4 часа, задание резервного копирования (или как минимум задание инкрементального бэкапа / CDP-репликации) должно выполняться не реже, чем раз в 4 часа. Для критичных баз данных с RPO в несколько минут одного классического бэкапа недостаточно — нужна непрерывная защита данных (CDP, Continuous Data Protection), которая в Veeam Backup & Replication реализована отдельным типом задания и пишет журнал транзакций практически в реальном времени.
RPO = 24 часа -> ежедневный полный/инкрементальный бэкап
RPO = 4 часа -> инкрементальный бэкап каждые 4 часа
RPO = 15 минут -> CDP-репликация или журналирование транзакций СУБД
RPO = 0 -> синхронная репликация (кластер, storage replication)
Что такое RTO
RTO (Recovery Time Objective) — это допустимое время простоя, то есть сколько часов или минут может пройти с момента сбоя до момента, когда сервис снова доступен пользователям. Если RTO для файлового сервера равен 8 часам, у администратора есть рабочий день на восстановление, прежде чем это станет критичной проблемой для бизнеса. Если RTO для интернет-магазина равен 15 минутам, ни о каком ручном восстановлении из ленты речи быть не может — нужна готовая реплика, которую можно включить одной кнопкой.
Как RTO влияет на архитектуру восстановления
Короткий RTO почти всегда стоит дороже, потому что требует не просто наличия резервной копии, а готовой инфраструктуры для быстрого переключения. Veeam предлагает для этого несколько механизмов разной стоимости и скорости:
- Instant VM Recovery — виртуальная машина запускается прямо из файла бэкапа за несколько минут, без предварительного восстановления на постоянное хранилище. Подходит для RTO в пределах 15-30 минут.
- Replication Job — на резервной площадке (например, на esxi-host01 в другом сегменте сети или в облаке) постоянно поддерживается актуальная реплика VM, включаемая почти мгновенно через failover-план. Это вариант для RTO в единицы минут.
- Классическое восстановление из бэкапа на постоянное хранилище — самый медленный вариант, RTO измеряется часами и зависит от объёма данных и скорости канала до srv-backup01.
Как считать RPO и RTO на практике
Это не техническое, а управленческое упражнение — Business Impact Analysis (BIA). Порядок действий:
Шаг 1. Составь реестр систем
Перечисли все ИТ-системы компании: домен и контроллер srv-dc01, базы 1С, почтовый сервер, файловые шары, ERP, сайт, системы АСУ ТП на производстве, если они есть. Для каждой укажи, на каком хосте она крутится — esxi-host01, srv-pve01, srv-hv01 или физическое железо.
Шаг 2. Оцени стоимость простоя для каждой системы
Спроси владельцев бизнес-процессов: что произойдёт, если система будет недоступна час? Сутки? Для производственной линии это может быть прямая остановка цеха и штрафы по контрактам, для внутреннего wiki-портала — просто неудобство. Разница в критичности систем определяет, что получит RTO в 30 минут, а что может подождать до следующего утра.
Шаг 3. Оцени допустимую потерю данных отдельно от простоя
Иногда простой некритичен, а потеря данных — критична, и наоборот. Например, система логирования может простаивать сутки без последствий, но не должна терять ни одной записи после восстановления (RPO близко к 0 за счёт архивирования логов на другой сервер), тогда как тестовый стенд разработчиков может как простаивать, так и терять данные без всякого ущерба бизнесу.
Шаг 4. Сведи всё в таблицу приоритетов
Система RPO RTO Метод защиты
--------------------------------------------------------------
Домен (srv-dc01) 24 часа 2 часа Backup + доп. DC
1С база данных 4 часа 1 час Инкрементал + Instant Recovery
Файловый сервер 24 часа 8 часов Ежедневный бэкап
ВМ на esxi-host01 1 час 15 минут Replication Job
Тестовые ВМ 7 дней 24 часа Еженедельный бэкап
Считаем стоимость простоя
Чтобы разговор с руководством о бюджете на резервное копирование был предметным, полезно перевести RTO в деньги. Простая формула для производственного участка: стоимость часа простоя = (упущенная выручка за час работы участка) + (зарплата простаивающих сотрудников за час) + (штрафы по контрактам за срыв сроков, если применимо) + (репутационные издержки, оцениваемые экспертно). Даже грубая оценка по этой формуле обычно быстро объясняет, почему инвестиция в Replication Job с RTO в 15 минут для конкретной линии окупается за один предотвращённый инцидент.
Пример расчёта для сборочной линии:
Выручка участка в смену (8 часов): 800 000 руб.
Стоимость часа простоя (выручка): 100 000 руб./час
Зарплата простаивающей смены (12 чел.): 18 000 руб./час
Штраф за срыв поставки (при простое >4ч): 250 000 руб.
--------------------------------------------------------
Итого при простое 1 час: 118 000 руб.
Итого при простое 5 часов: 840 000 руб. + штраф
Такой расчёт, сделанный один раз для каждой критичной системы, снимает большинство споров о том, «нужен ли нам дорогой Replication Job» — цифры говорят сами за себя.
CDP и другие способы приблизить RPO к нулю
Continuous Data Protection в Veeam Backup & Replication работает иначе, чем обычный периодический бэкап: вместо снятия точки восстановления по расписанию продукт устанавливает драйвер-фильтр ввода-вывода на уровне гипервизора и пишет короткие журналы изменений (обычно с интервалом в несколько секунд), из которых можно откатиться на любую точку в пределах заданного окна, а не только на момент последнего снапшота. Это отдельная технология от классических Backup Job и Replication Job, требующая дополнительных ресурсов на хосте, поэтому применяется точечно — для одной-двух по-настоящему критичных систем, а не для всей инфраструктуры разом.
Типичные интервью-вопросы для расчёта BIA
При разговоре с владельцем бизнес-процесса удобно опираться на конкретные вопросы, а не абстрактное «сколько вы готовы простаивать»:
- Что конкретно происходит через 15 минут простоя этой системы? Через час? Через сутки?
- Есть ли ручной обходной процесс на время простоя (бумажные накладные, звонки вместо CRM), и на сколько часов его хватит?
- Какие данные, введённые за последний час, будет физически невозможно восстановить вручную, если их потерять?
- Есть ли договорные или регуляторные обязательства со сроками (SLA перед клиентами, отчётность перед контролирующими органами)?
Частые ошибки и как их избежать
RPO и RTO придумывает сам ИТ-отдел, без бизнеса. Технический специалист склонен либо занижать требования («и раз в сутки нормально»), либо резервировать бюджет под завышенные цифры «на всякий случай». Правильные цифры получаются только в разговоре с владельцами процессов и первыми лицами компании.
Одна пара RPO/RTO на всю инфраструктуру. Домен и тестовый стенд разработчиков не могут иметь одинаковые требования — это либо переплата за избыточную защиту неважных систем, либо риск для критичных. Сегментируй системы минимум на 3 уровня критичности.
RTO не проверяется практикой. Заявленный RTO в 30 минут ничего не стоит, если последний раз восстановление тестировали два года назад. Реальное время восстановления нужно замерять на практике при плановых учениях disaster recovery — это единственный способ узнать настоящую цифру, а не ту, что записана в документе.
Разные RPO/RTO для разных типов сбоев
Полезная деталь, которую часто упускают: RPO и RTO не обязаны быть одним и тем же числом для всех типов инцидентов. Восстановление после случайного удаления файла сотрудником — это одна ситуация, восстановление после отказа диска на esxi-host01 — другая, а восстановление после атаки шифровальщика на весь сегмент 192.168.10.0/24 — принципиально третья, с совершенно другой логикой выбора точки восстановления.
RTO при массовой атаке отличается от RTO при локальном сбое
Если сгорел один диск на файловом сервере, время восстановления определяется в основном скоростью копирования данных из бэкапа. Если шифровальщик прошёлся по всей сети, время восстановления складывается из совершенно других этапов: локализация и остановка распространения, оценка масштаба компрометации, выбор безопасной точки восстановления (той, что предшествует моменту заражения, а не просто последней доступной), последовательное поднятие систем в правильном порядке — сначала домен и сетевая инфраструктура, затем базы данных, затем прикладные сервисы. Реалистичный RTO для второго сценария почти всегда в разы больше, чем для первого, и об этом стоит договариваться с руководством отдельно, чтобы не обещать невыполнимое.
Как выбрать безопасную точку восстановления после атаки
Одна из главных ошибок при восстановлении после шифровальщика — взять самую свежую точку восстановления, не проверив, не находится ли в ней уже полезная нагрузка атакующего (веб-шелл, заражённый сервисный аккаунт, изменённые GPO). Хорошая практика — при подозрении на длительное присутствие атакующего в сети восстанавливаться на точку, предшествующую первым индикаторам компрометации, даже если это означает потерю данных сверх привычного RPO. Это ещё один аргумент в пользу достаточно длинного окна хранения точек восстановления (retention), а не минимально необходимого для повседневных сбоев.
Что дальше
Стратегия бэкапов — это только начало, вот что логично изучить дальше в этой серии: