Привет, на связи Дмитрий Бессольцев, руководитель ALP ITSM. За последние годы я много раз видел, как компании теряют миллионы не из‑за «отсутствия бэкапов», а из‑за отсутствия плана действий при аварии. В статье «Восстановление ИТ‑инфраструктуры: цена простоя для бизнеса» мы уже разбирали, сколько реально стоит простой и как считать RTO/RPO для ключевых систем. В этом материале — следующий шаг: разберёмся, чем живой план аварийного восстановления (DRP) отличается от набора копий «на всякий случай» и какие вопросы собственник должен задать ИТ‑службе, чтобы не остаться без бизнеса в момент сбоя.

Если нет времени читать всю статью, важно понять три вещи. Бэкапы сами по себе не спасают бизнес — это только сырьё, а не гарантия работы систем. Опасны четыре типичные ситуации:

• копии лежат рядом с «боевыми» данными и сгорают/шифруются вместе с ними;
• восстановить данные просто некуда — нет облака или резервного сервера;
• даже при наличии копий подъём 1С, почты и других систем занимает дни, а не часы;
• бэкапы никогда не проверялись на реальное восстановление, только на «успешное копирование».

Рабочий DRP отвечает не на технический, а на бизнес‑вопрос: через сколько времени после аварии компания снова сможет принимать платежи и отгружать товар. А чтобы понять, насколько вы далеки от этой точки, сначала нужно честно посмотреть в лицо реальным ИТ‑рискам — с этого и начнём.

Реальность ИТ-рисков: почему бэкапов недостаточно

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

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

• Резервное копирование (Backup) — это сохранность данных (файлов).
• Аварийное восстановление (Disaster Recovery, DR) — это комплекс мер и технологий, позволяющий развернуть эти данные в работающую систему за определенное время.

Наличие «запасного колеса» (бэкапа) бесполезно, если отсутствуют инструменты для его установки или навыки персонала.

Почему фраза «У нас есть бэкапы» — это самообман

Давайте раз и навсегда разделим два понятия: Резервное копирование (Backup) и Аварийное восстановление (Disaster Recovery). Путать их — фатальная ошибка для предпринимателя.

Представьте, что вы едете на важную встречу на автомобиле.

• Бэкап — это запасное колесо в багажнике. Оно у вас есть. Вы спокойны.
• DRP (План восстановления) — это домкрат, баллонный ключ и, главное, ваше умение поменять колесо под проливным дождем на оживленной трассе за 15 минут, чтобы не опоздать.

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

С ИТ-инфраструктурой то же самое.

Классический сценарий провала, или «Бэкап есть, но...»

По нашему опыту в большинстве случаев, когда бизнес теряет данные или простаивает неделями, у компании БЫЛИ бэкапы. Почему они не спасли?

1. «Восстанавливать некуда». Сервер сгорел физически (скачок напряжения, пожар, вода). Данные сохранены на внешнем диске. Но чтобы запустить работу, нужно купить новый сервер. А их нет в наличии, доставка — 2 недели. Всё это время бизнес стоит, хотя данные в сохранности.
2. «Бэкап поврежден или пуст». Программа резервного копирования годами слала отчеты: «Копирование выполнено успешно». Но копировала она, например, пустую папку или битый файл базы данных. Никто ни разу не проверил, что внутри архива.
3. «Восстанавливать слишком долго». У вас есть копия всех файлов. Но чтобы вернуть 1С к жизни, админу нужно: найти «железо», установить Windows, поставить SQL-сервер, настроить платформу 1С, залить туда файлы, прописать пользователей, настроить права... Это 2-3 дня работы авральном режиме. Готов ли ваш бизнес стоять 3 дня?
4. «Бэкап тоже умер». Современные вирусы-шифровальщики очень умные. Попадая в сеть, они первым делом ищут резервные копии и удаляют или шифруют их. Если ваши бэкапы лежат на том же сервере или в той же локальной сети — вы потеряете всё и сразу.

Вывод: Бэкап — это лишь сырье. Продукт, который нужен бизнесу — это восстановленный сервис (работающая 1С, сайт, почта) за конкретное, заранее оговоренное время. И именно за этот результат отвечает План аварийного восстановления.

Технический аудит: 5 ключевых вопросов для оценки рисков

Вам не нужно быть экспертом в ИТ, чтобы найти критические уязвимости в безопасности своей компании. Достаточно задать своему ИТ-директору или системному администратору правильные вопросы.

Сделайте это на ближайшей планерке. Ответы (или их отсутствие) скажут вам о состоянии дел больше, чем любые отчеты.

Вопрос № 1: «Где физически лежат наши копии?»

Этот вопрос проверяет, защищены ли вы от физической потери данных (пожар, кража, изъятие серверов).

Надежно: «Мы соблюдаем правило 3-2-1. У нас есть 3 копии данных, на 2 разных носителях, и одна копия обязательно хранится вне офиса (в облаке или другом дата-центре)».

Рискованно: «На том же сервере, просто на диске D», «На внешнем диске, который лежит на сервере», «В соседнем кабинете». Если сгорит офис или зашифрует вирус — вы потеряете и оригинал, и копию.

Вопрос № 2: «Мы делаем копии файлов или образы всей системы?»

Этот вопрос про скорость восстановления (RTO).

Надежно: «Мы делаем полные образы критичных серверов. Если сервер упадет, мы просто развернем этот образ на любом другом железе за пару часов».

Рискованно: «Просто копируем файлы 1С и документы». Это значит, что в случае аварии админу придется вручную устанавливать Windows, драйверы, программы, настраивать сеть и безопасность. Это 2-3 дня простоя вместо пары часов.

Вопрос № 3: «Есть ли у нас резервное железо (Warm Standby)?»

Представим худшее: ваш основной сервер вышел из строя окончательно. Куда вы будете разворачивать ваши (даже идеальные) бэкапы?

Надежно: «У нас есть арендованный ресурс в облаке / старый, но рабочий сервер в запасе. Он слабее основного, но потянет критические процессы, пока мы ищем замену».

Рискованно: «Ну... побежим покупать новый». В текущих реалиях логистики поставка серверного оборудования может занять недели.

Вопрос № 4: «Как наши бэкапы защищены от шифровальщиков?»

Вирусы-вымогатели — угроза № 1 для малого и среднего бизнеса.

Надежно: «У нас используются неизменяемые хранилища или оффлайн-копии (диски, которые физически отключаются от сети после записи)».

Рискованно: «Они лежат в папке „Backups“ в общей сети». Вирус найдет эту папку за секунду и зашифрует её вместе с базой данных.

Вопрос № 5: «Когда мы последний раз реально пробовали восстановиться?»

Самый главный вопрос.

Надежно: «Тесты проводятся регулярно (раз в квартал), проверяется работоспособность сервисов, а не просто наличие файлов.»

Рискованно: «Бэкапы делаются каждую ночь, ошибки не приходят». Отсутствие ошибок записи не гарантирует, что данные внутри целы.

«Тревожный чемоданчик» руководителя (Организационная часть DRP)

В момент кризиса админ может быть недоступен, интернет в офисе отключен, а сотрудники паникуют. Чтобы бизнес не встал, у вас должен быть заранее подготовленный «Аварийный комплект». В идеале — в бумажном виде в сейфе.

Вот что в нем должно быть:

• Схема эскалации: Контакты провайдеров, хостинга, разработчиков ПО и альтернативных подрядчиков.
• Мастер-пароли: Актуальные данные для доступа к управлению серверами, регистратору доменных имен и корпоративной сети (учетные записи уровня Administrator/Root).
• Реестр приоритетов: Четкий список систем, подлежащих восстановлению в первую очередь (обычно это ERP, почта, телефония), и сервисов, восстановление которых может быть отложено.

Закрепите этот список письменно. Это сэкономит драгоценные часы при аварии, направив ресурсы на спасение денег, а не комфорта.

Регулярные учения как стандарт безопасности

Наличие резервной копии без проверки ее работоспособности создает ложное чувство защищенности. Файл может иметь корректную дату создания, но содержать ошибки внутри структуры базы данных.

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

1. Периодическое тестовое восстановление критических систем в изолированной среде («песочнице»).
2. Проверка работоспособности бизнес-функций (например, формирование бухгалтерского отчета), а не просто запуск сервера.
3. Фиксация времени, затраченного на восстановление, и сравнение его с допустимым временем простоя.

Только после этого вы можете быть уверены, что ваш «страховой полис» настоящий, а не нарисованный.

Заключение: ИТ-безопасность как бизнес-процесс

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

Что сделать прямо сейчас?

1. Проведите 15-минутный аудит. Задайте ИТ-отделу те самые 5 вопросов из этой статьи.
2. Проверьте «конверт». Убедитесь, что у вас есть доступ к собственным серверам и доменам без участия текущего админа.
3. Назначьте дату учений. Поставьте в календарь задачу: «Тестовое восстановление 1С из бэкапа» и проконтролируйте результат.

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

Что почитать и куда заглянуть дальше

Если тема аварийного восстановления откликается и хочется посмотреть на риски шире, можно продолжить с других историй:

1. Про цену простоя и восстановление инфраструктуры — разбор, сколько на самом деле стоит каждая часовая остановка ИТ и как считать RTO/RPO для ключевых систем. «Восстановление ИТ‑инфраструктуры: как защитить бизнес от сбоев»
2. Про выбор подрядчика и организацию ИТ‑поддержки так, чтобы в критический момент был «к кому бежать», а не только «с кого спросить». «Админ или ИТ‑аутсорсинг: как выбрать подрядчика и не переплатить».
3. Про ИТ‑аудит как способ заранее найти слабые места в инфраструктуре, прежде чем они проявятся в виде аварий. «ИТ‑аудит: как бизнесу перестать терять деньги на сбоях в ИТ»

А если удобнее следить за такими разборами в живом формате, можно заглянуть в телеграм‑канал ALP ITSM: там регулярно выходят кейсы и полезные материалы по непрерывности бизнеса.