Обычное утро понедельника.

Бухгалтер открывает 1С — и ничего. Системный администратор смотрит на сервер: диски в порядке, питание есть, сеть доступна, но база не поднимается.

Оказывается, в пятницу запустили обновление. Оно прошло «успешно». А в воскресенье ночью фоновый процесс завершил начатое — и данные за последние три месяца исчезли.

Все смотрят на директора. Директор смотрит в телефон. В телефоне — контакт подрядчика, который сейчас в отпуске.

Что вы будете делать в первые 30 минут? Через час? Кого поднимать? Что восстанавливать первым? Где последняя рабочая копия? Кто проверял, что она вообще восстанавливается?

И главный вопрос: что делать, когда выяснится, что «мы делаем бэкапы» на практике означало «бэкапы настроены, но никто не проверял, можно ли из них поднять бизнес обратно»?

TL;DR — коротко о главном

Disaster Recovery Plan (DRP) — это не просто про бэкапы. Это про то, как быстро бизнес вернётся к работе после аварии, сколько данных потеряет и сколько денег сгорит за время простоя.

Хороший DRP отвечает на конкретные вопросы:

• какие системы критичны;
• сколько времени они могут не работать;
• сколько данных допустимо потерять;
• кто отвечает за восстановление;
• что делаем в первые 15–30 минут;
• где лежат бэкапы;
• как проверяем, что восстановление действительно работает.

В этой статье разберём, чем DRP отличается от резервного копирования, что такое RTO и RPO, какие бывают стратегии восстановления — холодный, тёплый и горячий резерв — и почему компания без плана всегда находится в зоне риска.

Disaster Recovery — это не про бэкапы. Это про время и деньги

Резервное копирование отвечает на вопрос: «Есть ли у нас копия?»

Disaster Recovery отвечает на другой: «Как быстро мы с её помощью вернёмся к работе?»

Это принципиальная разница.

Бэкап — это сейф. DRP — это инструкция, что делать, когда сейф нашли, но здание всё ещё горит.

Можно делать бэкапы каждый день и всё равно простоять несколько суток. Потому что никто не знает, кто восстанавливает систему, в каком порядке, на каком оборудовании, с какими доступами и сколько времени это займёт.

Можно иметь резервный сервер и всё равно не подняться вовремя. Потому что на нём старая версия базы, инструкция написана три года назад, а человек, который всё это настраивал, давно не работает в компании.

DRP нужен не для галочки. Он нужен, чтобы в момент аварии бизнес не импровизировал.

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

RPO (Recovery Point Objective) — это допустимый объём потери данных.

Проще: насколько далеко назад вы готовы откатиться.

Если последний бэкап был вчера в полночь, а авария случилась сегодня в 17:00, вы теряете весь рабочий день. Заказы, транзакции, документы, переписку, изменения в CRM, проведённые операции в 1С.

В этом случае RPO — 17 часов.

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

RTO: сколько времени бизнес может не работать

RTO (Recovery Time Objective) — это допустимое время восстановления.

Проще: сколько времени бизнес может не работать.

Пока система восстанавливается, бизнес стоит. Менеджеры не принимают заказы. Склад не отгружает. Бухгалтерия не закрывает период. Клиенты ждут или уходят. Поддержка объясняет, что «мы уже разбираемся».

RTO — это не техническая хотелка. Это финансовое решение.

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

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

Три стратегии аварийного восстановления: от эконом до премиум

Не существует одного правильного DRP для всех.

Есть уровни готовности. У каждого своя цена, своё время восстановления и свой допустимый риск.

Задача не в том, чтобы выбрать самое дорогое решение. Задача — выбрать то, которое соответствует цене простоя именно вашего бизнеса.

Холодный резерв

Холодный резерв — это минимальный уровень готовности.

Есть бэкапы на диске, в облаке или на отдельном хранилище. Если что-то случится, нужно найти или арендовать сервер, установить систему, настроить окружение, восстановить данные из резервной копии и проверить, что всё работает.

Срок восстановления: от 2 до 5 дней. Иногда больше — зависит от объёма данных, сложности инфраструктуры, скорости доступа к оборудованию и того, насколько хорошо описана процедура восстановления.

Плюс очевидный: это бюджетно.

Минус тоже очевидный: если бизнес не может позволить себе несколько дней простоя, холодный резерв не подходит.

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

Тёплый резерв

Тёплый резерв — это компромисс между ценой и скоростью восстановления.

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

Срок восстановления: обычно от 4 до 12 часов. RPO — от нескольких часов до суток, в зависимости от настроенной репликации и частоты синхронизации данных.

Для многих бизнесов это золотая середина.

Вложения уже заметные, но не такие, как у горячего резерва. При этом восстановление становится предсказуемым: команда понимает, куда переключаться, что запускать и в каком порядке.

Горячий резерв

Горячий резерв — это максимальный уровень готовности.

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

Пользователи могут вообще не заметить аварию.

Срок восстановления: секунды или минуты. RPO — близко к нулю.

Это дорого. Но для банков, страховых компаний, крупных e-commerce-проектов, платёжных систем и сервисов с жёсткими SLA это не роскошь, а нормальный уровень зрелости.

Если простой стоит бизнесу больше, чем поддержка горячего резерва, вопрос уже не в цене. Вопрос в том, почему он ещё не внедрён.

DRaaS: аварийное восстановление в облаке

Есть и облачный вариант — DRaaS (Disaster Recovery as a Service).

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

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

Но у DRaaS есть свои вопросы: каналы связи, безопасность, скорость восстановления, совместимость, стоимость хранения и запуска ресурсов. Поэтому его тоже нужно проектировать, а не покупать «на всякий случай».

DRP — это не расходы. Это паспорт зрелости бизнеса

DRP часто воспринимают как ещё одну статью затрат.

Пока ничего не случилось, кажется, что можно подождать. Бэкапы ведь есть. Серверы работают. Подрядчик на связи. Сисадмин всё помнит.

Но зрелость инфраструктуры проверяется не в спокойный день. Она проверяется в момент аварии.

Регуляторные требования

Для банков, страховых компаний, операторов связи, медицинских организаций и других регулируемых отраслей план аварийного восстановления IT-инфраструктуры может быть не рекомендацией, а требованием.

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

Нет плана — есть риск для лицензий, проверок, договоров и операционной устойчивости.

Тендеры и крупные заказчики

Крупные заказчики всё чаще спрашивают не только о цене и опыте, но и об устойчивости подрядчика.

Что будет, если у вас упадёт система? Как быстро вы восстановитесь? Есть ли DRP? Когда последний раз тестировали бэкапы? Кто отвечает за восстановление? Какой RTO и RPO?

Для заказчика компания без DRP — это риск. А риски в B2B любят перекладывать на других поставщиков.

Репутация

Клиенты не прощают простоев. Особенно если конкурент в это время работает.

Один громкий сбой в неподходящий момент — и часть аудитории формирует простую мысль: «у них нестабильно».

В B2B это особенно болезненно. Репутация надёжного партнёра собирается годами, а ломается одним инцидентом, если компания не может внятно объяснить, что произошло, как быстро восстановится и что сделает, чтобы это не повторилось.

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

Как мы разрабатываем и тестируем DRP

Процесс разработки DRP не начинается со слов «сейчас настроим бэкапы».

Он начинается с вопросов.

Какие системы критичны? Что должно восстановиться первым? Сколько времени бизнес может не работать? Какие данные нельзя потерять? Кто принимает решения в момент аварии? Какие подрядчики нужны? Где доступы? Где документация? Кто проверял, что всё это работает?

Без ответов на эти вопросы DRP превращается в документ ради документа.

Аудит

Сначала нужно понять, что есть сейчас.

Мы смотрим архитектуру, критичные системы, базы данных, серверы, облачные ресурсы, бэкапы, регламенты, доступы, зависимости между сервисами и текущие точки отказа.

Отдельно проверяем, работают ли бэкапы на самом деле.

Потому что фраза «бэкапы настроены» ничего не значит, пока из них хотя бы раз не восстановили систему.

Определение RTO и RPO

Дальше определяем RTO и RPO.

Это не технические вопросы. Это бизнес-решения.

Сколько часов простоя допустимо? Потерю данных за какой период компания переживёт? Какие системы нужно восстановить первыми? Что важнее: CRM, сайт, 1С, складская система, платёжный контур, клиентский портал?

Инженеры могут предложить варианты. Но допустимый риск определяет бизнес.

Именно от RTO и RPO зависит стратегия восстановления, бюджет и архитектура.

Проектирование стратегии

После аудита и определения целевых показателей выбирается стратегия.

Где достаточно холодного резерва? Где нужен тёплый? Где без горячего резерва бизнес рискует слишком сильно? Какие данные реплицируем? Как часто? Где храним копии? Как защищаем их от шифровальщика? Как переключаемся на резервную площадку?

Здесь важно не выбрать «что подешевле» или «что помощнее».

Важно выбрать то, что соответствует реальной цене простоя.

Если час простоя стоит бизнесу дорого, экономия на восстановлении может оказаться самой дорогой экономией в компании.

Внедрение

После проектирования начинается внедрение.

Настраивается резервное копирование, репликация, резервные площадки, процедуры переключения, доступы, мониторинг, алерты и документация.

Отдельно прописывается, кто что делает в первые минуты после аварии.

Кто принимает решение о переключении? Кто изолирует заражённые системы? Кто поднимает резерв? Кто проверяет данные? Кто сообщает бизнесу статус? Кто фиксирует инцидент?

Это важно, потому что в панике люди делают ошибки. Чёткий план убирает панику.

Тестирование

Тестирование — самая важная и самая редкая часть DRP.

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

Поэтому DRP нужно проверять регулярно.

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

Планы, которые не тестируются, не работают в реальности. Это закон.

Сценарий: как DRP помогает после атаки шифровальщика

Пятница, 23:40. Вирус-шифровальщик прошёлся по инфраструктуре.

К утру субботы серверы зашифрованы, данные недоступны, часть систем не отвечает. Команда собирается в экстренном чате. Бизнес ждёт ответ: когда заработаем?

Если плана нет

Компания начинает разбираться на месте.

Кто отвечает? Непонятно. Какие серверы заражены? Выясняем. Где чистые бэкапы? Ищем. Можно ли их восстановить? Никто не проверял. Кого звать? Подрядчик не отвечает. Платить выкуп или нет? Спорят.

Параллельно идут потери: простой, сорванные операции, остановленные продажи, нагрузка на поддержку, репутационные риски.

Восстановление может растянуться на дни и недели. И всё это время бизнес живёт в режиме ручного управления.

Если DRP есть

Заражённые серверы изолируются сразу. Команда действует по процедуре, а не по памяти.

Проверяется последняя чистая точка восстановления. Поднимается резервная инфраструктура. Данные восстанавливаются до допустимого RPO. Критичные системы возвращаются в работу в пределах согласованного RTO.

Бизнес понимает, что происходит, кто отвечает и когда ждать восстановления.

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

План есть?

Это не риторический вопрос.

Большинство компаний, которые приходят к теме DRP, уверены, что «у нас всё настроено». После аудита часто выясняется другое.

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

Хорошая новость: это всё исправляется.

Плохая: лучше исправить это до аварии.

Если вы не уверены, что сможете восстановить критичные системы в нужные сроки, начните с аудита. Мы проверим бэкапы, точки отказа, текущие RTO/RPO и покажем, какой DRP нужен вашей инфраструктуре не на бумаге, а в реальной аварии.

Частые вопросы

Что такое Disaster Recovery Plan?

Disaster Recovery Plan или DRP — это план аварийного восстановления IT-инфраструктуры после серьёзного сбоя, атаки, потери данных или другой катастрофы. Он описывает, какие системы нужно восстановить, в каком порядке, кто за это отвечает, какие ресурсы используются и за какое время бизнес должен вернуться к работе.

Чем DRP отличается от резервного копирования?

Резервное копирование отвечает на вопрос: «Есть ли у нас копия данных?» DRP отвечает на вопрос: «Как быстро мы сможем восстановить работу бизнеса с помощью этой копии?» Бэкапы — это только часть DRP. Без процедур, ответственных, тестирования и понятных RTO/RPO бэкапы не гарантируют быстрое восстановление.

Что такое RTO и RPO?

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

Какие бывают стратегии аварийного восстановления?

Основные стратегии — холодный, тёплый и горячий резерв. Холодный резерв дешевле, но восстановление может занять дни. Тёплый резерв позволяет восстановиться за часы. Горячий резерв обеспечивает переключение за секунды или минуты, но требует больших вложений. Также есть DRaaS — аварийное восстановление в облаке.

Кому нужен DRP?

DRP нужен компаниям, для которых простой IT-систем напрямую влияет на деньги, клиентов, операционные процессы или выполнение обязательств. Это e-commerce, финансы, страхование, ритейл, производство, медицина, логистика, B2B-сервисы и любые компании, где потеря данных или длительный простой создают серьёзный бизнес-риск.

Как часто нужно тестировать DRP?

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