Проверка резервных копий: как проводить тестовое восстановление

Зелёное задание — ещё не проверка: критерии успеха

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

Поэтому у проверки свои критерии — и полезно зафиксировать их до того, как планировать тесты:

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

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

Четыре уровня проверки: файл → база → система → площадка

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

Частоты в таблице — стартовые ориентиры этой статьи, согласованные с ориентиром хаба рубрики для критичных систем («например, ежеквартально или после существенных изменений»); точная настройка выводится из целей и критичности конкретных систем — по той же логике, по которой выбирались целевые RPO и RTO.

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

Уровень 1. Файл: быстрый и автоматизируемый

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

Такой тест может выявить пустые или оборванные копии, незаметно сломавшееся задание для отдельной папки, деградацию носителя, забытый пароль шифрования и истёкшие права доступа к хранилищу копий. Это полезный ранний сигнал: проблему обнаруживают на плановой проверке, а не во время аварии.

Именно уровень 1 проще всего автоматизировать: восстановление контрольного набора по расписанию со сверкой контрольных сумм. Автоматизация здесь уместна и безопасна — при условии, что результат доходит до журнала: лог, который никто не читает, проверкой не считается; контроль заданий и оповещений — тема хаба о мониторинге ИТ-инфраструктуры.

Уровень 2. База данных: восстановление плюс целостность

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

Про быстрые проверки важно понимать их границы. У SQL Server есть RESTORE VERIFYONLY — команда, которая по документации Microsoft «проверяет резервную копию, не восстанавливая её»: что резервный набор полон, все тома читаются, сходятся отдельные поля заголовков страниц и контрольные суммы, если они записаны на носитель. Но там же зафиксирована граница: команда «не пытается проверять структуру данных, содержащихся в резервных томах». Успешный VERIFYONLY — это «копия полна и читается», а не «база восстановится целой»; на снапшоты баз данных команда не работает вовсе.

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

Практический вывод: быстрая верификация — полезный частый слой (дёшево ловит нечитаемые и оборванные копии), но тестом восстановления она не является. Полный тест уровня 2 — это именно восстановление с проверкой целостности и прикладной проверкой; для учётных систем это означает открыть восстановленную базу в приложении и сверить последние документы — не останавливаясь на сообщении об успехе.

Уровень 3. Система или ВМ целиком

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

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

На этом уровне впервые осмысленно измерять время восстановления системы целиком — от старта до проверенного сервиса.

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

Уровень 4. Площадка: катастрофический сценарий

Последний уровень отвечает на вопрос, который не проверяется по частям: если основная площадка недоступна — пожар, затопление, шифровальщик, добравшийся до всего сегмента, — поднимется ли критичный набор систем из офсайт-копии. Это тот сценарий, ради которого офсайт-слой вообще существует в архитектуре копий по правилу 3-2-1 — как он строится, разобрано в статье о правиле 3-2-1.

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

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

Фактический RTO: секундомер против цели

Каждый тест уровня 2–4 — это ещё и замер. Секундомер включается в момент условной «аварии» — решения о восстановлении — и выключается, когда сервис проверен и работает, а не когда скопировались файлы. Между этими точками лежит весь критический путь: диагностика и выбор точки восстановления, подготовка площадки, само восстановление, запуск, проверка данных и зависимостей. Последовательные этапы складываются, параллельные учитываются по самой длинной ветке — так же, как считался целевой RTO.

Чтобы динамика от теста к тесту имела смысл, точки старта и финиша фиксируются в регламенте одинаково для всех прогонов: одинаковый момент «аварии», одинаковое определение «сервис работает». Иначе сравнение превращается в спор об условиях замера.

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

Вместе со временем фиксируется и фактическая свежесть: какой давности точка реально восстановилась. Если тест показал, что пригодной оказалась копия не вчерашняя, а недельная, — это расхождение по RPO, и оно важнее многих «зелёных» отчётов: где-то в цепочке свежие копии создаются, но не годятся.

Журнал проверки: шаблон на одну страницу

Журнал превращает «мы вроде проверяем» в проверяемую историю: когда, что, из какой копии, сколько заняло, что разошлось с целью. Формат не важен — таблица в вики, файл рядом с таблицей целей, печатная страница; важен состав полей:

Такой журнал занимает страницу, а работает сразу на три задачи: дисциплина (пропущенные прогоны видны), доказуемость (при аудите и при смене подрядчика история проверок — документ) и планирование (динамика фактического времени подсказывает, когда схема перестанет укладываться в цель).

«0» в 3-2-1-1-0: автоматическая верификация и её границы

В расширении правила 3-2-1 до 3-2-1-1-0 последний ноль — это «ноль ошибок при проверке восстановления»: по формулировке Veeam, восстановимость копий подтверждается автоматической верификацией. Архитектурная часть правила — сколько копий, какие носители, офсайт и изолированный слой — разобрана в статье о правиле 3-2-1; ноль — её эксплуатационное замыкание: архитектура без проверки остаётся чертежом.

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

Границы у автоматики те же, что у любой быстрой проверки — она подтверждает то, что умеет проверять, как VERIFYONLY на уровне баз. В зависимости от продукта автоматические прогоны могут закрывать часть рутины первого, второго и третьего уровней, но прикладную проверку («документы на месте, операции проходят») и катастрофический сценарий площадки они не заменяют. Рабочая связка — автоматика по расписанию, люди по регламенту; и то и другое пишет в один журнал.

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