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

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

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

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

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

Это не единичный случай. На нашей практике: в компаниях до 50 рабочих мест, которые никогда не тестировали восстановление, рабочий бэкап с первой попытки получается примерно в 60% случаев. Остальные 40% — пустышка, частичное восстановление или архив, который вообще не открывается нужной версией программы.

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

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

Настоящий тест — это разворачивание копии в отдельной изолированной среде и реальная проверка того, ради чего копия вообще делалась. Для базы 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 Sheets: дата теста, что проверялось, результат, кто проверял. Без журнала через полгода никто честно не ответит, было тестирование или нет. На нашей практике мы ведём такой журнал для каждого клиента. Раз в квартал отправляем короткий отчёт: бэкапы 1С — ок, файловый сервер — ок, почта — нашли проблему с вложениями, исправили тогда-то.

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

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

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

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

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

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