Инцидент происходит не «если», а «когда». Шифровальщик, отказ СХД, ошибка администратора, пожар в ЦОД – любой из сценариев останавливает бизнес. Свежий пример – атака на оператора Colonial Pipeline, о которой мы писали недавно: простой трубопровода обошёлся дороже любого выкупа. Разница между компаниями, которые переживают такой удар, и теми, кто закрывается, – это не наличие бэкапов, а проверенный план восстановления. Резервная копия, из которой никто ни разу не восстанавливался, – это не страховка, а иллюзия.

Бэкап и DRP – это не одно и то же

Резервное копирование отвечает на вопрос «как вернуть данные». План аварийного восстановления (Disaster Recovery Plan) отвечает на вопрос «как вернуть работающий бизнес-процесс». Это разные задачи, и вторая шире первой.

DRP описывает порядок действий: кто принимает решение об активации, в какой последовательности поднимаются системы, куда переключается трафик, как оповещают клиентов и регулятора. Для госсектора и финансовых организаций такой план – не пожелание, а требование: положение Банка России 716-П и стандарты СТО БР ИББС прямо обязывают документировать процедуры обеспечения непрерывности.

Две метрики задают всю архитектуру:

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

Сначала бизнес называет цифры RPO и RTO для каждой системы, потом под них проектируется технология – а не наоборот.

Архитектура копий: правило 3-2-1 и защита от шифровальщика

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

Практические выводы для проекта:

  • Храните офлайн- или WORM-копию, недоступную из продакшен-сети. Атакующий, получивший доступ к домену, до неё не дотянется.
  • Разделяйте контуры аутентификации бэкап-системы и основной инфраструктуры.
  • Шифруйте копии и контролируйте, где физически лежат данные – для ГИС и персональных данных хранение обязано оставаться в РФ согласно 152-ФЗ.
  • Распределённые системы требуют согласованных копий: при микросервисной архитектуре важно восстанавливать не отдельный сервис, а связное состояние данных и очередей.

Проверка восстановления – главная и самая пропускаемая часть

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

Фиксируйте результат, обновляйте план, повторяйте. Только так RTO из строчки в документе превращается в реальный срок, на который можно опереться при отчёте руководству и регулятору.

Вывод

Восстановление бизнеса после инцидента – это инженерная дисциплина, а не разовая закупка ПО. Сформулируйте RPO и RTO, постройте копии по правилу 3-2-1 с иммутабельным звеном, документируйте DRP и регулярно проверяйте восстановление на практике. Под требования регуляторов всё это собирается в отказоустойчивую ИТ-инфраструктуру – от резервного копирования до распределённых площадок. Решения окупаются предсказуемо: грамотно оформленные ИТ-затраты ещё и учитываются при налогообложении.