План аварийного восстановления на одну страницу: что делать, если сервер физически сгорел

За пятнадцать лет в IT-аутсорсинге я видел два сгоревших сервера в буквальном смысле — с дымом из корпуса и запахом горелой изоляции. И десяток «условно сгоревших»: умер рейд-контроллер, посыпались диски, материнку убило скачком напряжения после отключения света. Каждый раз директор задаёт один и тот же вопрос: а у нас есть план? Обычно ответа нет. Или есть — на сорок страниц, лежит в файле на том самом сервере, который только что превратился в кусок оплавленного пластика.

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

Классический DRP-документ, который продают консалтинговые конторы, выглядит внушительно. Сорок страниц, таблицы RTO и RPO, матрицы ответственности, приложения с диаграммами. Заказчик его подписывает, платит, кладёт в папку «Регламенты» на файловом сервере — и забывает. Я сам когда-то писал такие документы, гордился ими. Потом понял: чем толще регламент, тем меньше шансов, что его откроют в момент, когда действительно горит.

У одного клиента, бухгалтерской фирмы на 18 рабочих мест, был именно такой документ. Сорок с лишним страниц, составлен серьёзным консультантом три года назад. Когда рейд на основном сервере с 1С посыпался в пятницу вечером, документ искали сорок минут. Нашли — на сетевом диске, который был расшарен с того же сервера. Круг замкнулся, план восстановления оказался недоступен именно тогда, когда был нужен. Бухгалтерия встала на два дня, а не на четыре часа, как обещал контракт с интегратором.

Что вообще должно случиться, чтобы план понадобился

Физический пожар — редкость, слава богу. Но сценариев, требующих такого же быстрого реагирования, десятки. Скачок напряжения после аварии на подстанции сжигает блок питания и материнку. Затопление после прорыва трубы этажом выше заливает серверную стойку. Кража системного блока из офиса — да, было и такое, в маленькой юрфирме увели системник прямо с ресепшен за выходные. Шифровальщик, который за ночь превращает базу 1С и файловый архив в нечитаемую кашу — тоже, по сути, «сервер сгорел», только программно.

Объединяет все эти случаи одно: железо или данные исчезли внезапно, а бизнес должен работать завтра утром. Клиника не может сказать пациентам «извините, вернёмся через неделю». Торговая компания теряет заказы каждый час простоя кассы и склада. И вот тут выясняется: план, если он есть, нужен не для того, чтобы красиво выглядеть в аудите, а чтобы за десять минут ответить на вопрос «что делать прямо сейчас».

Что реально помещается на одну страницу

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

Дальше — три-пять критичных систем в порядке приоритета. Не «вся инфраструктура», а конкретно: 1С Бухгалтерия и база на SQL, сервер терминалов с рабочими местами менеджеров, почта, если она локальная, система контроля доступа на проходной. У медицинской клиники, с которой я работал, приоритет номер один — не 1С, а МИС с расписанием приёма, потому что без неё регистратура физически не может записывать пациентов.

И последний блок — три конкретных шага для первого часа. Где физически лежат бэкапы (Veeam, NAS, облако — с указанием, где именно и как туда попасть). Где хранятся пароли администратора — не в голове у эникейщика, который в отпуске, а в менеджере паролей с доступом минимум у двух человек. И что можно арендовать или купить прямо сейчас, если своего железа больше нет — у нас в компании есть список поставщиков, у которых сервер конфигурации «под 1С» можно получить за сутки, с ценником и телефоном менеджера прямо в документе.

Как это выглядит в реальном инциденте — история одного четверга

В прошлом году у клиента, производственной компании на 35 человек, замкнуло проводку в серверной после грозы. Не картинно сгорело, но материнку и блок питания убило намертво, диски физически уцелели. Директор позвонил мне в 9 утра, паника в голосе понятная — производство встаёт, отгрузки по накладным без 1С не сделать.

У них как раз лежал одностраничный план, который мы собрали полгода назад. Пять минут — и я уже знал, что бэкапы базы льются каждую ночь в Veeam на отдельный NAS в другом углу здания, плюс копия в облако раз в неделю. Ещё пять минут — заказали временный сервер у партнёра, с которым в документе прямо был указан контакт и примерная цена, порядка 45 тысяч рублей за развёртывание конфигурации «под ключ» на арендованном железе. К 15:00 того же дня 1С уже работала на временной машине, диски с производственного сервера отдали на диагностику отдельно. Три дня простоя вместо потенциальной недели — и то основную часть времени съело ожидание доставки нового блока питания, а не восстановление данных.

Разница с сорокастраничным регламентом простая: никто не листал документ в поисках нужного раздела. Всё, что нужно, было на одном листе, а лист лежал не на сервере, а в телефоне директора и у меня в почте.

Где хранить этот листок, чтобы он не сгорел вместе с сервером

Звучит очевидно, но именно это правило нарушают чаще всего. Документ, описывающий, что делать при потере сервера, нельзя хранить только на этом сервере. Распечатанная копия в сейфе директора — не архаизм, а разумная страховка на случай, если сгорит вообще всё, включая интернет и электричество в здании. Электронная копия — в облаке (Google Диск, Яндекс.Диск, что угодно вне вашей локальной сети) и у обслуживающей IT-компании.

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

Бэкапы — это не пункт плана, это его фундамент

Одностраничный DRP работает только если за ним стоит нормальная схема резервного копирования. Без неё документ превращается в красивый список телефонов, по которым можно позвонить и услышать «данные не восстановить». Классика, которую мы ставим клиентам — Veeam Backup с копированием в двух местах: локально на NAS для быстрого восстановления и в облако или на другую площадку для защиты от пожара, потопа и шифровальщика одновременно. Правило 3-2-1 звучит скучно, но именно оно спасает: три копии данных, на двух разных носителях, одна за пределами офиса.

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

Сколько это стоит и с чего начать в понедельник

Составление такого документа для компании на 15-50 рабочих мест — это не месяц консалтинга. Это один рабочий день с айтишником: инвентаризация систем, разговор с директором про приоритеты, проверка, что бэкапы реально работают, а не просто настроены когда-то и забыты. У нас такая работа в рамках абонентского обслуживания занимает 4-6 часов и обычно уже включена в тариф, если клиент на постоянном сопровождении.

Если своей IT-компании нет, можно собрать план и самостоятельно, без бюджета вообще — просто сесть и честно ответить на три вопроса. Без какой системы бизнес не может работать больше суток? Где лежит последняя рабочая копия данных этой системы и когда её последний раз проверяли восстановлением, а не просто «галочка стоит, значит бэкапится»? И кому звонить в 7 утра в субботу, если что-то случится. Ответы на эти три вопроса, записанные на листе А4 и распечатанные в трёх экземплярах — это уже больше, чем есть у половины компаний, с которыми я разговаривал за последние годы.

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

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

Нужно ли держать в офисе резервный сервер на всякий случай?
Для компании до 50 рабочих мест это редко оправдано экономически — простаивающее железо стоит денег и всё равно стареет. Разумнее договориться заранее с поставщиком о быстрой аренде или покупке под конфигурацию 1С, и держать этот контакт прямо в плане восстановления, с примерной ценой и сроком поставки.

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

Как часто нужно обновлять план и проверять, что он вообще работает?
Мы рекомендуем ревизию дважды в год, приурочивая её к тестовому восстановлению из резервной копии — это заодно проверяет, что бэкапы не битые. Внепланово план стоит пересматривать при смене IT-подрядчика, переезде сервера или смене схемы резервного копирования.