Обновлено: октябрь 2026
«У нас есть бэкап» и «наш бэкап восстановится» — два разных утверждения, и второе никогда не подтвердится само. Эта статья — порядок проверки: что смотреть раз в неделю, что — раз в квартал, как проходит тестовое восстановление и что писать в журнал. Интерактивная версия чек-листа — в нашем инструменте самопроверки резервного копирования.
Строка «задание выполнено успешно» в панели резервного копирования — это утверждение о том, что программа записала данные на носитель. О том, что эти данные можно будет прочитать и поднять, она не говорит ничего. Между одним и другим лежит целый пласт тихих отказов: хранилище переполнилось и копии молча перестали помещаться; внутри архива повреждение, которое проявится только при распаковке; агент на сервере устарел вместе с операционной системой; права на сетевую папку сменились, и задача пишет «успешно» — в никуда.
Вторая причина — копии стареют вместе с инфраструктурой. Схема, год назад покрывавшая всё, за год могла не заметить новую базу, второй офис и выросший втрое объём. Проверка — это способ обнаружить всё перечисленное в спокойном режиме, а не посреди аварии, когда восстанавливать уже надо, а нечему.
Проверки делятся на лёгкие — частые и быстрые, и тяжёлые — редкие, но настоящие. Лёгкие ловят остановившиеся процессы, тяжёлые отвечают на главный вопрос — о восстановимости.
Полная проверка каждой копии избыточна — достаточно трёх сценариев, закрывающих три типовых запроса к схеме. Каждый ловит свой класс проблем.
Один файл. Восстановить свежий документ в отдельную тестовую папку, открыть, сверить содержимое. Проверка занимает минуты и ловит повреждённые архивы, сбитые права и проблемы с длинными русскими именами файлов. Это минимальная регулярная проверка — её имеет смысл делать чаще квартала.
База данных. Восстановить копию учётной базы под тестовым именем на тестовый контур, открыть, сверить данные — остатки, обороты, количество документов за известный день. Этот сценарий лучше проходить вместе с тем, кто отвечает за саму базу: именно он скажет, что перед ним рабочие данные, а не пустая оболочка. Ловит проблему «горячих» копий — база копировалась на лету без согласования, и копия получилась несогласованной.
Вся виртуальная машина или сервер. Поднять копию машины на изолированном стенде — без доступа в рабочую сеть офиса. Убедиться, что система загружается, сервисы стартуют, программа запускается. Изолированность здесь не перестраховка: поднятая копия учётной системы в рабочей сети начнёт рассылать документы и обмениваться данными с боевым контуром. Сценарий ловит неполные копии и скрытые зависимости — от сети, лицензий, забытых внешних дисков.
Восстановление одного файла — минуты, и его можно вписать в любой рабочий день. Восстановление базы — от получаса до нескольких часов: время растёт с размером базы и зависит от скорости хранилища. Подъём виртуальной машины — часы: только передача копии в сотню гигабайт по гигабитной сети занимает десятки минут, дальше загрузка и проверка сервисов. Отсюда практический вывод: квартальная проверка всех сценариев — это половина рабочего дня с учётом оформления результатов, и её стоит планировать заранее, как любое другое обслуживание, а не делать «когда появится время».
Зато эти полдня дают точный ответ на вопрос, который при аварии станет главным: сколько времени занимает восстановление. Время тестового подъёма — лучшая из доступных оценок времени боевого.
Формат не важен — таблица, документ, задача в трекере. Важен состав записи. Минимальный набор полей:
Журнал превращает разовые проверки в историю, из которой видны тенденции: восстановление базы замедляется от квартала к кварталу — хранилище деградирует; ошибки кочуют из записи в запись — их никто не чинит. И он же отвечает на неудобный вопрос «а когда мы в последний раз что-то проверяли?» — точной датой, а не ощущением.
Пример записи, чтобы было проще начать: «14.10.2026, Иванов — восстановление базы из копии за 13.10 (ночная задача) на тестовый контур — успешно, остатки сверены, 40 минут». Пять таких строк в квартал — и у компании есть документ, а не воспоминания.
Частично. Средства резервного копирования умеют проверять целостность своих архивов, репозитории — сверять копии с контрольными суммами. Автоматика отвечает за целостность, но не за пригодность: откроется ли база и запустятся ли сервисы, показывает только восстановление руками. Оно не отменяется.
Это не провал проверки, а её результат — проблема найдена до аварии, в спокойной обстановке. Запись в журнал, разбор причин, исправление схемы, повторная проверка. Хуже выглядит не «неудачный тест», а отсутствие тестов.
Да, отдельным сценарием: доступность удалённого репозитория, наличие ключа, скорость восстановления через канал офиса. Копия, до которой при аварии не добраться за разумное время, существует лишь формально.
Начать со сценария «один файл» — он не требует стенда вовсе. Для базы и машины подойдёт виртуальная машина на любом незанятом хосте, поднимаемая на время проверки вне рабочих часов: стендом не обязательно владеть постоянно.
Тот, кто отвечает за инфраструктуру: штатный специалист или подрядчик на сопровождении. Сценарий с базой — вместе с тем, кто отвечает за учётную систему. Ключевое — не должность, а регулярность и записи в журнале.
Пройти чек-лист в форме вопросов с пояснениями можно в инструменте самопроверки резервного копирования. Если схема ещё не собрана — начните со статьи о правиле 3-2-1 в небольшой компании: она описывает, из чего складывается сама схема копий.
Постановка схемы, автоматизация и регулярные тестовые восстановления — направление резервного копирования и восстановления данных.
