Проверка бэкапа восстановлением: почему резервная копия, которую никогда не разворачивали, — не бэкап

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

Зелёная галочка в отчёте — это не гарантия

Была у меня клиентка, юрфирма на 18 человек в центре Москвы. Сервер 1С, документооборот, почта — всё крутилось на одной машине с Veeam Agent, который каждую ночь в 2:00 копировал систему на NAS. Отчёты шли исправно: задача выполнена, ошибок нет, объём такой-то гигабайт. Восемь месяцев подряд зелёным цветом.

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

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

Что чаще всего ломается в бэкапах, о которых никто не знает

Проблема редко в том, что бэкап вообще не делается. Обычно всё хуже: он делается, но частично, и это незаметно снаружи. Самый частый сценарий — заблокированный файл базы 1С в момент копирования. Если снапшот снят некорректно, копия базы формально есть, но при восстановлении СУБД пишет «база повреждена, требуется восстановление» и открывается с потерянными транзакциями за последние сутки.

Второй классический случай — КриптоПро и лицензии. Восстановили сервер, база встала, а токен электронной подписи или сетевая лицензия 1С физически прописаны на старое железо. Формально данные целы, а работать нельзя, пока не переоформишь лицензирование, а это уже не пять минут, а звонки в 1С и ожидание.

Третий — банальная забывчивость. Завели новую базу или новую папку с документами, а в задание резервного копирования её добавить забыли. Бэкап идёт, отчёт зелёный, но копируется только половина того, что нужно. У одного клиента из медицинской сферы так полгода не бэкапилась база с изображениями снимков — сама медкарта копировалась, а файлы снимков лежали в отдельной шаре, про которую забыли.

Почему просто «проверить архив» недостаточно

Многие администраторы на этом успокаиваются: открыл архив, посмотрел контрольную сумму, файлы на месте — значит, всё в порядке. Но контрольная сумма проверяет только то, что архив не побился при передаче или хранении. Она не скажет, откроется ли база 1С, стартанёт ли служба, поднимется ли RDP-сервер со всеми профилями и правами.

Реальная проверка — это когда вы берёте копию, разворачиваете её на отдельной машине или в виртуалке, поднимаете сервис и смотрите на данные глазами. Открывается ли база в 1С без ошибок. Совпадают ли остатки на складе с тем, что помнит бухгалтер. Стартует ли терминальный сервер и заходят ли в него реальные пользователи со своими профилями, а не только administrator.

Это дольше, чем сверить хэш-сумму, — иногда час, иногда полдня. Но именно это отделяет бэкап-который-работает от бэкап-который-выглядит-рабочим. Я всегда говорю клиентам: пока вы не восстановили резервную копию хотя бы один раз, вы не знаете, есть ли у вас бэкап. У вас есть файл, который на это претендует.

Как выглядит регламент тестового восстановления у нас

Для критичных систем — базы 1С, почта, документооборот — тестовое восстановление делаем раз в месяц на отдельной тестовой виртуалке, которая не видна в основной сети и не может случайно затронуть прод. Разворачиваем последнюю ночную копию, поднимаем СУБД, открываем базу, проверяем контрольные отчёты: остатки, обороты, последние документы за вчера.

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

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

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

Тестовое восстановление раз в месяц для базы 1С — это в среднем 1,5–2 часа времени администратора. При наших расценках на аутсорс это укладывается в 3–5 тысяч рублей в месяц, если делать это регулярной, а не разовой историей. Полная квартальная проверка сервера с поднятием на резервном железе — уже часа четыре, но раз в три месяца это не деньги.

Теперь сравним с ценой простоя. У клиники на 40 сотрудников один день простоя записи и медкарт — это минимум 200–300 тысяч рублей недополученной выручки плюс раздражённые пациенты, которые звонят в регистратуру и уходят к конкурентам. У бухгалтерской компании в разгар сдачи отчётности сутки простоя базы 1С — это реальный риск не успеть с декларациями и получить штрафы от налоговой на пустом месте.

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

RTO и RPO — не абстрактные буквы, а конкретные часы простоя

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

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

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

Что сделать в первую очередь, если у вас нет такого регламента

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

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

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

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

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

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

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

Сколько времени занимает полное тестовое восстановление базы 1С?
У наших клиентов это обычно от сорока минут до полутора часов в зависимости от объёма базы и мощности тестового сервера. Первая проверка почти всегда идёт дольше, потому что вылезают мелкие нестыковки в настройках — дальше время стабилизируется и становится предсказуемым показателем вашего реального RTO.