Бэкап есть, а восстановится ли он: зачем регулярно репетировать аварийное восстановление

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

Бэкап — это лотерейный билет, а не страховка

Года три назад я пришёл на аудит к небольшой юрфирме на Пресне. У них Veeam исправно бэкапил сервер каждую ночь, архивы лежали на NAS, всё по учебнику. Спрашиваю: а восстанавливали хоть раз? Тишина. Через неделю у них полетел RAID-контроллер на основном сервере. Восстанавливаем — и упираемся в то, что бэкап делался с открытой базой 1С, без снятия блокировок. Файл битый. Полгода бухгалтерии как не бывало.

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

Я специально говорю клиентам грубо: бэкап, который никогда не восстанавливали — это не бэкап. Это файл. Может, полезный, а может, мусор. Пока не проверили — не знаете.

Что обычно ломается при восстановлении — и почему это выясняется в самый неподходящий момент

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

Второе — лицензии 1С и HASP-ключи. У одного клиента, производственной компании в Домодедово, программная лицензия 1С была активирована на MAC-адрес сетевой карты. Восстановили сервер на новом железе — 1С не запускается, просит новую активацию, а старая привязка висит и её нужно снимать через техподдержку фирмы «1С», это ещё сутки простоя.

Третье — порядок восстановления. Люди почему-то думают, что достаточно поднять один сервер с базой данных. А у вас там контроллер домена, DNS, доступ по RDP через определённые группы безопасности, сертификаты для терминального сервера. Поднимаете базу — а войти в неё десять человек не могут, потому что сломалась авторизация через Active Directory, которого ещё нет.

Как мы устраиваем учения по восстановлению у клиентов

Раз в квартал, для критичных инфраструктур — раз в месяц, мы поднимаем полную копию продакшена в изолированной тестовой среде. Отдельный VLAN, без доступа в интернет и без пересечения с боевой сетью — чтобы, не дай бог, не устроить конфликт IP-адресов или дублирование контроллера домена. На отдельном ESXi-хосте или в Hyper-V разворачиваем всё: сервер 1С, терминальный сервер, файловый сервер, домен-контроллер, если он есть.

Дальше — секундомер. Засекаем время от команды «восстанавливаем» до момента, когда бухгалтер реально может войти в базу и провести документ. Это и есть RTO на практике, а не цифра из презентации подрядчика. У одного клиента, стоматологической клиники на 40 рабочих мест, первое такое учение показало результат в 14 часов вместо ожидаемых двух. Причина — забыли, что регистратура работает через отдельную медицинскую систему с привязкой лицензии к железу, и про неё в плане восстановления просто не было ни слова.

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

Реальный случай: как учения спасли бухгалтерскую фирму от штрафа

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

Но за два месяца до этого мы прогнали у них плановые учения — и как раз выяснили, что бэкап базы 1С не включал каталог с внешними обработками и настройками обмена с банк-клиентом. Починили тогда же, добавили в резервное копирование недостающие 6 гигабайт данных. В мае восстановление заняло 3 часа 40 минут вместо потенциальных суток простоя, а без исправления после учений — там бы ещё и обмен с банком пришлось настраивать с нуля, а это ещё день-два переговоров с банком.

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

RTO и RPO по-человечески, а не по методичке

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

RPO — это сколько данных вы готовы потерять. Если бэкап делается раз в сутки ночью, а сервер упал в 17:00 — вы теряете весь рабочий день: все документы, все проводки, все звонки клиентов, занесённые в CRM. Для юрфирмы, где счёт идёт на процессуальные сроки, потеря даже нескольких часов может означать пропущенный срок подачи иска.

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

С чего начать, если вы ни разу не проверяли свой бэкап

Первое — заведите отдельную тестовую площадку, пусть скромную. Один сервер под Hyper-V или ESXi с 3-4 виртуальными машинами хватит, чтобы прогонять восстановление 1С, терминального сервера и контроллера домена. У большинства наших клиентов на это уходит один недорогой сервер за 150-250 тысяч рублей — разово, и дальше он служит годами.

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

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

Сколько это стоит и почему это дешевле простоя

Учения по восстановлению для типовой компании на 20-40 рабочих мест у нас занимают от 8 до 16 часов работы инженера, это порядка 15-30 тысяч рублей за один прогон при квартальной периодичности. Годовой бюджет на регулярные тренировки — обычно в районе 100-150 тысяч рублей.

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

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

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

Как часто нужно проверять восстановление из бэкапа?
Для критичных систем — 1С, терминальный сервер, база данных — рекомендую раз в квартал. Для менее критичных участков, вроде файлового архива, достаточно раз в полгода. Главное правило простое: если систему меняли — обновили 1С, добавили новый модуль, сменили сервер — учения нужно повторить сразу после этого, не дожидаясь плановой даты.

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

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

Учения нужны только крупным компаниям или и небольшому бизнесу тоже?
Наоборот, малому бизнесу они нужнее. У крупной компании обычно есть штат айтишников и запас прочности на пару дней простоя. У фирмы на 15-30 человек часто вся инфраструктура держится на одном сервере, и его потеря без отработанного плана восстановления способна остановить работу на неделю.