DR-план есть у многих компаний. Лежит где-нибудь в корпоративной вики или в папке на сетевом диске, чтобы аудитору показать в случае проверки. В плане расписаны определенные действия на случай аварии. Но когда авария действительно случается, выясняется, что по этому документу ничего сделать нельзя. Доступы не работают, контакты устарели, а последовательность шагов ведёт в тупик. С такой ситуацией сталкивалось множество ИТ-команд. И каждый раз это заканчивается одинаково: паника, хаос, простой, потеря данных и денег.

Поговорим о структуре документа, о том, какие сценарии аварий нужно отработать, как выбирать резервную площадку и тестировать план. Информация актуальна для ИТ-директоров, которые отвечают за непрерывность бизнеса, и инженеров, которые будут этот план исполнять.

План аварийного восстановления (disaster recovery plan, DRP) — это документ, который фиксирует, что и в каком порядке нужно делать, чтобы вернуть ИТ-системы к жизни после серьёзного сбоя. В нём прописаны ситуации, от которых защищаемся, приоритеты восстановления сервисов, ответственные люди, доступы, целевые сроки и критерий, по которому аварию считают закрытой.

Здесь мы будем говорить про DR-план, описывающий только ИТ-контур: серверы, базы данных, сеть, приложения и инфраструктуру. Если упал интернет-магазин, DR-план отвечает на вопрос «как поднять сайт и базу заказчиков». А вот что делать с условным колл-центром, который остался без рабочих мест , — это уже более широкий вопрос, который мы в этой статье не затрагиваем.

Резервное копирование в облако и DR часто путают. Бэкап отвечает за наличие копии данных. DR-план отвечает за восстановление работающего сервиса в заданный срок с заданным процентом потери данных.

Разницу легко понять на примере.

У компании есть резервные копии всех баз. Они лежат на отдельном хранилище, регулярно обновляются. Всё хорошо. Но в один день дата-центр становится недоступным из-за аварии на подстанции, а ИБП и ДГУ не справились с нагрузкой. Серверы выключены, доступ к ним потерян. Копии есть, но развернуть их негде — резервной площадки нет. А даже если она есть, никто не отрабатывал их восстановление, а потому доподлинно не знает, в какой последовательности поднимать сервисы, кто за что отвечает, какие пароли использовать и т.п.. Копии есть, а работающего сервиса нет. DR-план как раз и закрывает эту проблему: он описывает, как из копий собрать работающую систему в нужный срок.

BCP (business continuity plan) — это план непрерывности бизнеса. Он описывает, как компания будет работать в кризисной ситуации в целом: куда переедет офис, как сотрудники будут связываться друг с другом, как выполнять ключевые бизнес-функции без привычных инструментов. DR-план — это часть BCP, его ИТ-составляющая.

Порядок разработки обычно такой: сначала проводится бизнес-анализ (BIA — business impact analysis) и составляется перечень критичных бизнес-процессов. Для каждого процесса определяют, какие ИТ-системы его обеспечивают. И уже под эти системы пишут DR-план. Не наоборот. Нельзя взять и описать восстановление всех систем подряд — нужно понимать, какой сервис для чего нужен и сколько компания готова за него заплатить.

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

В июне 2026 года на Cnews были опубликованы результаты CX-исследования, проведённого на основе глубинных интервью со 180 заказчиками. У 39% компаний за последний год стоимость часа простоя значительно выросла. Ещё 35% сказали, что она осталась на прежнем уровне. 14% отметили снижение благодаря внедрению резервных систем и процедур.

Рост стоимости простоя связан с несколькими факторами:

• бизнес сильнее зависит от бесперебойной работы цифровых сервисов;
• оборудование стареет, восстановление после сбоев усложняется;
• инфраструктура становится неоднородной — сложнее понять, как всё связано;
• вендорская поддержка сокращается, особенно по зарубежному оборудованию и ПО.

58% респондентов назвали главным вызовом на ближайшие два года высокие затраты на замену устаревших систем. Речь не только о закупке нового оборудования, но и о перестройке архитектуры, проверке совместимости, миграции, обновлении регламентов и обучении команд.

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

Приоритет смещается в сторону мер, которые снижают риск отказов и сокращают время восстановления. Наиболее эффективными респонденты назвали создание запасной инсталляционной базы на всех уровнях инфраструктуры (46%) и разработку детальных планов и регламентов аварийного восстановления (32%).

Ещё один способ снижать потери от недоступности ИТ-систем — страхование в облаке: решение, которое помогает управлять рисками и рационально распределять финансовые потоки. Провайдер Linx Cloud предлагает собственную инфраструктуру на базе двух сертифицированных ЦОД уровня TIER III в Москве и Санкт‑Петербурге, что позволяет строить катастрофоустойчивые архитектуры с гарантированным уровнем доступности.

RTO (Recovery Time Objective) — это время, за которое система должна быть восстановлена после аварии. Считается от момента, когда принято решение о переключении на резерв, до момента, когда сервис снова доступен пользователям.

RPO (Recovery Point Objective) — это допустимый объём потери данных. Показывает, на сколько часов (или минут) можно откатить систему назад. Если RPO = 1 час, значит, при аварии допустима потеря данных, созданные не более чем за последний час. Всё, что было раньше, должно сохраниться.

Показатели назначаются на каждый сервис отдельно. Нельзя поставить один RTO на всю инфраструктуру — у платежной системы и внутреннего чата для сотрудников требования к восстановлению будут разными.

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

Пример.

Интернет-магазин с выручкой 5 млн руб. в сутки. В пиковые часы (10:00–22:00) это около 300–400 тысяч в час. Допустим, бизнес готов терпеть простой не больше двух часов — иначе убытки (денежные и репутационные) становятся критическими. Значит, RTO = 2 часа. Потеря данных за час — это потеря заказов, которые могли бы быть оформлены. Если за час через сайт проходит 30 заказов на сумму 50 тыс. руб., бизнес может с этим смириться. RPO = 1 час. Если такая потеря неприемлема, нужно снижать RPO до 15–30 минут и использовать более частую репликацию.

Все сервисы делятся на классы в зависимости от того, как долго они могут простаивать и сколько данных можно потерять. Каждому классу соответствует своя схема резервирования. Верхнеуровнево матрица может выглядеть так:

1. RTO назначает ИТ-отдел без согласования с бизнесом. Инженеры берут цифры «с потолка», исходя из того, что им кажется разумным или на что хватает существующих ресурсов. Бизнес потом удивляется, почему платёжная система простаивала четыре часа, хотя каждый час простоя стоит миллион. RTO должен утверждаться на уровне топ-менеджмента — это бизнес-решение, а не техническое. Часто после оценки стоимости обеспечения RTO со стороны ИТ, бизнесу приходится корректировать свои аппетиты и пересматривать метрику. Но в конечном итоге она точно должна согласовываться бизнесом.
2. Один общий показатель на все системы. Платёжный шлюз и система для внутренних отчётов не могут восстанавливаться за одно и то же время. Это просто-напросто сжигание бюджета расфокусировка ИТ команды. Разные уровни критичности систем — разные RTO и RPO.
3. В RTO не заложено время на принятие решения и проверку данных. В плане написано «восстановить за 2 часа», но забыли, что сначала нужно созвониться, принять решение о переключении,. Реальное время может оказаться в два раза больше, если процесс инициации восстановления не описан и не отработан..
4. Показатели ни разу не подтверждались измерением на реальном восстановлении. RTO и RPO, которые никто не проверял, — это просто цифры в документе. Без тестов они не имеют никакой ценности.

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

1. Область действия и перечень охваченных систем. Чётко указать, какие сервисы, площадки и компоненты инфраструктуры входят в план, а какие — нет. Если какой-то сервис не охвачен, это должно быть написано явно.
2. Карта сервисов и зависимостей. Схема, которая показывает, как сервисы связаны друг с другом и с внешними системами. Если упадёт база данных, какие приложения перестанут работать? Если откажет внешний API, что сломается внутри? Без этой карты восстановление существенно усложняется.
3. Целевые RTO и RPO по каждому сервису. Таблица с показателями для каждого сервиса из перечня. Цифры должны быть согласованы с бизнесом и утверждены.
4. Роли, зоны ответственности, матрица эскалации. Кто принимает решение о переключении на резерв. Кто выполняет технические действия. Кто проверяет целостность данных. Кто связывается с подрядчиками. Кто информирует руководство и пользователей. Если ответственный недоступен, кто его заменяет. Схема связи при недоступности корпоративных каналов — телефоны, мессенджеры, резервная почта.
5. Критерии активации плана и лица, принимающие решения. План не активируется автоматически при любом сбое. Должны быть чёткие критерии: время недоступности, характер отказа, оценка ущерба. И конкретный человек (или группа), который принимает решение и даёт команду «переключаемся на резерв».
6. Пошаговые сценарии восстановления (runbook). Самая объёмная часть. Для каждого сценария — последовательность команд, скриншоты интерфейсов, порядок проверок. Runbook должен быть настолько подробным, чтобы по нему можно было восстановить систему даже в 3 ночи в выходной.
7. Доступы, учётные записи, ключи шифрования, места хранения резервных копий. Где лежат пароли, как получить доступ к резервным копиям, если основная площадка недоступна, какие ключи нужны для расшифровки данных. Вся эта информация хранится отдельно от основного документа, в защищённом месте, но в плане должно быть описано, как до неё добраться.
8. Процедура проверки целостности данных после восстановления. После того как системы подняты, нужно убедиться, что данные не повреждены и доступны для использования информационными системами и конечными пользователями Эта процедура прописывается для каждого типа систем отдельно.
9. Критерии завершения аварии и порядок возврата на основную площадку. Авария считается закрытой, когда все критичные сервисы работают на резервной площадке и пользователи получили доступ. Но рано или поздно нужно вернуться на основную площадку — в плане указано, как это делается, в какой последовательности и с какими проверками.
10. Контакты подрядчиков, провайдеров, вендоров с номерами договоров и SLA. Когда падает оборудование, нужно звонить поставщику, когда отказывает облако — провайдеру. В плане должны быть актуальные контакты, номера договоров и согласованные SLA по времени реакции и решения инцидентов.
11. Журнал версий и ответственный за актуализацию. DR-план — живой документ. В нём фиксируется, кто и когда вносил изменения, какая версия сейчас действует, кто отвечает за его обновление.

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

Отказ отдельного узла или дискового массива. Самый частый сценарий. Отказал один сервер или СХД . Признак: сервер недоступен, ошибки в логах хранилища. Первое действие: переключить нагрузку на другой узел в том же ЦОД. Целевой RTO: 15–30 минут. Восстановление происходит в пределах одной площадки, без переключения на резервный ЦОД.

Полная потеря площадки. Авария в ЦОД — пожар, затопление, отключение электричества, обрыв кабеля на входе. Признак: все сервисы на площадке недоступны одновременно. Первое действие: активировать резервную площадку, переключить DNS. Целевой RTO: от 1 до 4 часов в зависимости от класса сервиса.

Шифровальщик и повреждение данных. Злоумышленники зашифровали данные, включая резервные копии, если они были доступны. Это самый опасный сценарий. Признак: файлы переименованы, зашифрованы, появились записки с требованием выкупа.

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

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

Ошибка администратора или неудачное обновление. Кто-то запустил скрипт не на той системе, обновление нарушило совместимость. Признак: после конкретного действия система перестала работать. Первое действие: откатить изменения, восстановить систему из снапшота. Это самый простой сценарий, который обычно закладывается в рамках процесса управления изменениями.

Недоступность вендорской поддержки и невозможность закупки запчастей. Оборудование сломалось, а поставщик не отвечает или запчасти закончились. Это не техническая авария, а организационная. Признак: оборудование в отказе, поставщик не может помочь в срок. Первое действие: переключить нагрузку на резервное оборудование или облачную площадку. В плане должны быть прописаны альтернативные поставщики и сроки ожидания.

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

DRaaS (Disaster Recovery as a Service) — модель, при которой резервная площадка арендуется у провайдера. Компания не строит собственный резервный ЦОД, а использует облачную инфраструктуру провайдера.

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

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

До подписания договора задайте провайдеру несколько вопросов:

• Какой RPO может обеспечить сервис?
• Как часто можно проводить тестовые переключения без дополнительной оплаты?
• Где физически размещены данные — в каком регионе, в каком ЦОД?
• Кто выполняет переключение — команда провайдера/ собственная команда заказчика/совместно?
• Как организована поддержка в нерабочее время и в выходные?

Облачная инфраструктура IaaS — модель аренды виртуальных сервисов и других ресурсов, при которой компании платят только за фактическое использование мощностей. Такой подход даёт гибкость и прозрачность расходов, но многое зависит от надёжности платформы. Компания Linx Cloud строит IaaS на базе собственных ЦОД — это даёт предсказуемую отказоустойчивость и возможность географически распределять нагрузки без оглядки на сторонние площадки. Плюс платформа работает на OpenStack, что упрощает интеграцию с существующей инфраструктурой и автоматизацию.

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

Каналы связи между площадками нужно резервировать. Если основной канал оборвётся, репликация остановится, и RPO будет нарушено. В плане должно быть описано, как и кем переключаются DNS и публичные IP-адреса при переключении на резервную площадку.

Вариант размещения оборудования в ЦОД — colocation, то есть использование сторонних площадок для своих ресурсов. Задействуются виртуальные частные сети — выделенные каналы связи L2VPN.

Для многих компаний DR-план — юридическое требование.

Основные нормативные акты, которые обязывают иметь план аварийного восстановления и проверяют его наличие.

152-ФЗ о персональных данных. Операторы персональных данных обязаны обеспечивать восстановление данных, изменённых или уничтоженных вследствие несанкционированного доступа. Требования детализированы в постановлении Правительства № 1119 и приказе ФСТЭК № 21. Приказ ФСТЭК № 21 содержит группу мер по обеспечению доступности, включая резервирование и восстановление. Актуальная редакция приказа — от 14 мая 2020 года. С 1 сентября 2026 года вступают в силу новые меры, в том числе защита от современных угроз.

187-ФЗ о безопасности критической информационной инфраструктуры. Для значимых объектов КИИ (ЗОКИИ) предусмотрены меры по реагированию на инциденты и действиям в нештатных ситуациях, включая планирование восстановления. Поправки к закону вступили в силу 1 сентября 2025 года.

26 февраля 2026 года Правительство РФ утвердило распоряжением № 360-р единый перечень типовых отраслевых объектов КИИ. Документ насчитывает 397 типовых объектов по отраслям: банки и финансовые рынки, наука, здравоохранение, энергетика, транспорт, связь, оборонная и ракетно-космическая промышленность.

Для отдельных отраслей приняты отраслевые особенности категорирования: для атомной энергии (постановление № 4 от 16.01.2026), для банковской сферы (постановление № 92 от 06.02.2026), для науки (постановление от 07.03.2026).

Приказ ФСТЭК № 117. С 1 марта 2026 года вступил в силу приказ ФСТЭК № 117 от 11.04.2025, который обновил требования к защите информации в государственных информационных системах (ГИС). Документ распространяется не только на ГИС, но и на иные информационные системы государственных органов, государственных унитарных предприятий и государственных учреждений. Требования включают политику информационной безопасности, подразделения защиты, цикл Деминга и новый показатель защищённости КЗИ.

ГОСТ Р 53647 (менеджмент непрерывности бизнеса). Серия стандартов, которые задают методическую рамку для управления непрерывностью. Включает практическое руководство, управление человеческими ресурсами, управление организацией в условиях кризиса. Документы действуют в настоящий момент.

ГОСТ Р 57580.1 для финансовых организаций. Стандарт содержит более 400 организационных и технических мер защиты информации для банков, страховых, клиринговых компаний и финтех-стартапов. В ноябре 2025 года Банк России разослал финансовым организациям письма, обязывающие требовать от поставщиков ИТ- и ИБ-услуг соответствия стандарту. В феврале 2026 года проведены первые проверки крупнейших финансовых организаций.

Для организаций, работающих с персональными данными, важно выбирать соответствующую инфраструктуру — облако, аттестованное по 152-ФЗ. Вариант для государственных информационных систем — частное облако для ГИС.

Документ без проверки на реальном восстановлении ничего не стоит. Тестирование — единственный способ убедиться, что план работает, а не просто красиво выглядит на бумаге.

Разные уровни сложности — от простых до максимально реалистичных.

1. Разбор сценария на бумаге (tabletop exercise). Участники собираются и проходят сценарий устно: «что делаем, если упала база?», «кто кому звонит?», «какие команды выполняет?». Проверяются логика, последовательность действий, понимание ролей. Риска для продуктивной среды нет.
2. Восстановление одной системы на изолированном стенде. Берётся отдельный сервис и восстанавливается из бэкапов на тестовой среде. Проверяется, что бэкапы читаются, данные консистентны , восстановление проходит без ошибок.
3. Тестовое переключение группы связанных сервисов. Несколько сервисов, которые зависят друг от друга, переключаются на резервную площадку в тестовом режиме. Проверяются зависимости, порядок запуска, работа интеграций.
4. Полномасштабное учение с переводом продуктивной нагрузки. Самый сложный и рискованный вариант. Реальная нагрузка переключается на резервную площадку, пользователи работают с резервной средой. Проверяется всё: от инфраструктуры до пользовательского опыта. Риск — если что-то пойдёт не так, бизнес пострадает. Поэтому такие учения планируют на периоды низкой нагрузки и с полным планом отката.

Полный пересмотр и проверка плана — не реже раза в полгода. Частичные проверки типа восстановления отдельной системы можно делать чаще — раз в месяц или после каждого значимого изменения инфраструктуры.

Критерии успешного теста:

• сервис поднят и доступен пользователям;
• данные прошли проверку целостности;
• фактическое время восстановления уложилось в целевой RTO;
• потеря данных не превысила целевой RPO.

В протоколе теста фиксируется фактическое время каждого шага. Не «восстановили за 2 часа», а «базу подняли за 35 минут, веб-серверы за 50 минут, проверка данных заняла 20 минут, итого 1 час 45 минут».

После каждого теста составляется протокол с расхождениями между планом и реальностью. Например, в плане написано, что доступ к бэкапам получают за 10 минут, а на практике заняло 25, потому что ключи лежали не там. Или ответственный не взял трубку, и пришлось звонить его заместителю.

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

DR-план стареет быстро. Инфраструктура меняется, люди уходят, появляются новые сервисы. Если не обновлять документ, через полгода и даже раньше он перестанет соответствовать реальности.

Внеплановый пересмотр нужен в следующих случаях:

• ввод нового сервиса или интеграции;
• изменение архитектуры, миграция на новую платформу;
• смена ответственных сотрудников, увольнение ключевых специалистов;
• смена провайдера или изменение условий SLA;
• изменение нормативных требований;
• ротация ключей и доступов.

Организационная часть: у документа должен быть владелец, который отвечает за его актуальность. Место хранения — доступное, но защищённое. Обязательно наличие офлайн-копии (бумажной или на отдельном носителе) на случай, если корпоративные системы недоступны. Новые сотрудники, которые могут участвовать в восстановлении, должны быть ознакомлены с планом в рамках онбординга.

Комплексный аудит инфраструктуры и проектирование помогают выявлять точки, которые нужно отразить в DR-плане.

Пройдите по пунктам и отметьте, что уже сделано, а что ещё нет:

☐ Перечень всех ИТ-систем, которые должны восстанавливаться, составлен и утверждён.

☐ Для каждой системы назначены RTO и RPO, согласованные с бизнесом.

☐ По каждому сервису назначен ответственный за восстановление и его заместитель.

☐ Критерии активации плана записаны, лицо, принимающее решение о переключении, определено.

☐ Доступы, пароли, ключи шифрования хранятся в защищённом месте, порядок доступа к ним описан.

☐ Порядок действий при недоступности основной площадки прописан и проверен.

☐ Дата последних учений и их результат зафиксированы в протоколе.

☐ Дата последнего обновления плана — не старше 6 месяцев.

☐ Офлайн-копия плана существует и хранится отдельно от корпоративных систем.

☐ Контакты подрядчиков, провайдеров и вендоров актуальны, номера договоров и SLA записаны.

DR-план — это постоянный рабочий процесс. Документ написали, протестировали, обновили, снова протестировали. Без тестирования и регулярной актуализации план — просто текст. С тестированием и актуализацией — инструмент, который реально помогает в аварии.

Если собственной резервной площадки нет или строить её дорого, стоит обратить внимание на сервис аренды резервной инфраструктуры от DRaaS от Linx Cloud. Ресурсы компании позволяют снять вопросы с оборудованием, каналами и поддержкой, оставляя заказчику только настройку и управление процессом.