Тестирование резервных копий: как убедиться, что бэкап реально работает

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

Бэкап без проверки — это просто файл на диске

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

У одного клиента, торговая компания на 30 рабочих мест, бэкап 1С делался каждую ночь на NAS. Красиво, по расписанию, лог зелёный. Когда сервер умер после скачка напряжения, выяснилось: файл выгрузки .dt весил 4 килобайта. Просто заголовок, без данных. Программа резервного копирования исправно создавала файл — а сама база к этому моменту уже полгода была недоступна из-за смены пароля сервисной учётной записи. Никто не смотрел внутрь.

Это не редкость. По моей практике, в компаниях до 50 РМ, которые никогда не тестировали восстановление, шанс получить рабочий бэкап с первой попытки — процентов шестьдесят. Остальные сорок — это или пустышка, или частичное восстановление, или архив, который вообще не открывается нужной версией программы.

Что значит «протестировать» бэкап на самом деле

Тест — это не «открыл папку, файл есть, размер нормальный». Размер файла ни о чём не говорит. Битый архив с повреждённым концом может весить столько же, сколько целый.

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

Звучит как лишняя работа. На деле — это час-полтора в месяц против риска потерять неделю работы всей компании. Я считаю именно так, и клиентам объясняю точно так же: сравнение несопоставимое.

Пошаговая проверка бэкапа 1С

Первый шаг — восстановить .dt или .1CD файл не поверх рабочей базы, а на отдельный тестовый сервер или даже виртуалку. Никогда не тестируйте восстановление, затирая продакшн — если копия окажется битой, вы потеряете и оригинал.

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

Третий шаг, который почти все пропускают — проверить внешние связи. Обмен с банком через КриптоПро, обмен с кассами, интеграция с сайтом. Восстановленная база может открываться и даже работать, но сертификат КриптоПро привязан к железу старого сервера, и на новом обмен с банком просто не поднимется, пока не перевыпустишь сертификат. Это отдельная головная боль, и лучше узнать о ней на плановом тесте, а не в день, когда нужно срочно отправить платёжку.

Проверка файлового сервера и почты

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

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

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

Полное восстановление сервера — раз в год минимум

Отдельная история — не файлы, а целая система. Если у вас Windows Server с Veeam или встроенным Windows Server Backup, раз в год стоит проверять полное восстановление — bare metal recovery — на запасное железо или в виртуальную машину.

Это самый дорогой по времени тест, но и самый показательный. Именно тут всплывают вещи вроде несовместимости драйверов, отсутствия лицензии на новом железе, забытых паролей от RDP на восстановленной машине, потому что политики домена подтянулись не полностью. У производственной компании, где мы разворачивали такой тест впервые, восстановление образа заняло 11 часов вместо ожидаемых трёх — потому что резервная копия хранилась на медленном USB-диске, а не на нормальном NAS. Узнать это на тесте — нормально. Узнать в момент реальной аварии, когда простой стоит 150 тысяч рублей в день — совсем другое дело.

Здесь же проверяется восстановление контроллера домена, если он у вас единственный. Отдельный кошмар — потерять единственный DC без протестированного плана восстановления. Пароли, права доступа, структура сети — всё висит на этой одной машине.

Типичные причины, почему бэкап оказывается нерабочим

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

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

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

Как выстроить регламент, а не разовую проверку

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

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

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

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

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

Сколько времени и денег занимает такая проверка?
Ежемесячная проверка базы 1С и файлов занимает час-полтора работы администратора. Полное восстановление сервера — от трёх до десяти часов в зависимости от объёма данных и скорости хранилища. По деньгам это несравнимо дешевле простоя компании на день-два при реальной аварии с нерабочим бэкапом.

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

Что делать, если тест восстановления показал, что бэкап нерабочий?
Первым делом — не паниковать и проверить, есть ли более старая, но целая копия, чтобы не остаться совсем без защиты на время исправления. Затем разобраться в причине: заполненный диск, битые настройки задания, проблема с правами доступа. И перенастроить процесс так, чтобы следующий тест прошёл успешно, с обязательной повторной проверкой в течение недели.