Статус задания «Completed» в Job Controller не означает, что данные из этого бэкапа реально восстановятся. Непроверенная резервная копия ничего не гарантирует. Я давно пропагандирую идею о необходимости проверки резервных копий. Это должно быть неотъемлемым процессом резервного копирования.
В этом модуле разбираем, какими механизмами Commvault проверяет резервные копии: от простой проверки читаемости данных на диске до полноценного запуска приложения внутри тестовой копии VM.
1. Три уровня проверки резервных копий
Прежде чем настраивать конкретные механизмы, полезно понимать, что проверка резервной копии подразумевает не одну операцию, а три принципиально разных уровня, и каждый ловит свой класс проблем.
Физический уровень. Данные на диске читаемы и не повреждены. Это проверяет Data Verification через контрольные суммы (CRC). Такая проверка не знает, что внутри нашей резервной копии, она проверяет только целостность файла бекапа.
Структурный уровень. Проверяет не просто целостность резервной копии, а что внутри этого бекапа лежит корректно оформленный mdf/ndf/ldf, такой, какой ожидает увидеть наш сервер БД. Когда Commvault делает бэкап SQL Server, он копирует эти файлы в виде потока данных, не как обычные файлы на диске, поэтому такая проверка необходима. За это отвечает Restore Verify Only. Важно: она не запускает SQL Server и не открывает базу, она просто убеждается, что файл в принципе можно открыть. Похожий, но более глубокий уровень для дедуплицированного хранилища обеспечивает DDB Verification, которую мы разбирали в Модуле 5: она проверяет, что блоки, на которые ссылается DDB, физически присутствуют и не повреждены.
Логический уровень. Приложение запускается и работает на восстановленных данных. Это наиболее сложная, но самая честная проверка: VM загружается и проходит собственный скрипт валидации, а база данных запускается и содержит наши данные. За это отвечает Backup Validation.
Каждый из этих уровней может найти проблему с нашими резервными копиями. Но они не исключают друг друга. Физическая проверка не заметит логическую ошибку в структуре базы. Структурная проверка не заметит, что служба внутри VM не стартует из-за конфликта версий.
2. Data Verification: проверка целостности на уровне блоков
2.1 CRC на сети и на носителе
Commvault генерирует контрольную сумму (Cyclic Redundancy Check) для проверки данных на двух этапах:
CRC на сети. Контрольная сумма считается на клиенте до передачи данных и сверяется с суммой, полученной MediaAgent сразу после приёма. Это позволяет отслеживать повреждение данных при передаче, например из-за проблем на сетевом оборудовании между клиентом и MediaAgent. Проверка работает в обе стороны: и при бэкапе, и при восстановлении.
CRC на носителе. При записи данных на хранилище контрольная сумма сохраняется вместе с самими данными. Data Verification job впоследствии перечитывает данные, пересчитывает CRC и сравнивает с сохранённым значением. Если суммы не совпадают, задание сообщает об ошибке с указанием конкретного повреждённого блока.
2.2 Как включить и запустить проверку
Включить автоматическую проверку (по расписанию или сразу после каждого бэкапа) можно только через CommCell Console (Java). Через Command Center можно выполнять проверку только в ручном режиме:
Storage → Disk→ выбрать пул- Кнопка
Run → Ddb verification - Выбрать тип: Quick Verification или Complete Verification
В Command Center так проверяется всё хранилище целиком или конкретная копия, но не отдельное задание резервного копирования, для точечной проверки одного задания нужен CommCell Console.
Проверка поддерживается для всех типов storage policy copy и для всех агентов.
2.3 Что делать, если проверка нашла повреждение
Data Verification находит повреждённые данные, но не исправляет их. Если контрольная сумма не совпала, конкретное задание помечается как проблемное с указанием кода ошибки, и с этого момента система знает, что восстанавливаться из него не стоит. Дальнейшие шаги зависят от того, есть ли у повреждённых данных резервная копия на другой storage policy copy (тогда восстановление можно сделать оттуда) и не истекло ли хранение исходных данных на источнике (тогда можно переснять full backup). Чтобы не узнавать о повреждении только в момент аварии, на событие «Data Verification Failed» стоит настроить отдельный алертинг. Про систему алертов и мониторинг заданий поговорим в следующем модуле.
3. SQL Server: Restore Verify Only
3.1 Что это за проверка и чем она отличается от полного restore
Restore Verify Only — специальный тип задания для SQL Server, который проверяет пригодность резервной копии к восстановлению, не выполняя полноценное восстановление и не создавая рабочую копию базы. Задание проверяет:
- Достаточно ли прав у используемой учётной записи на восстановление файлов базы данных
- Присутствуют ли и корректны ли заголовки страниц базы данных (page headers)
Это быстрее и дешевле с точки зрения потребляемых ресурсов, нежели полноценное тестовое восстановление, потому что не требует ни создания рабочей копии, ни развёртывания всех файлов данных: по сути, это аналог команды SQL Server RESTORE VERIFYONLY, но управляемый и планируемый через Commvault.
3.2 Как запустить проверку
Protect → Databases → Instances→ выбрать нужный SQL Server instance- Открыть Restore, выбрать точку восстановления
- В Advanced restore options включить чекбокс Verify Only
- Запустить задание: вместо реального восстановления выполнится только проверка прав и заголовков страниц
Там же можно задать расписание для данной операции, для регулярного выполнения.
3.3 Что эта проверка не покрывает
Restore Verify Only подтверждает, что файлы можно физически восстановить и что структура страниц не повреждена, но не проверяет логическую целостность самой базы данных и не проверяет, что SQL Server сможет реально подключить эту базу. Для более глубокой проверки нужно либо полноценное восстановление с последующим запуском DBCC CHECKDB уже на восстановленной копии, либо Backup Validation через Instant Clone (мы разбирали его в Модуле 6, в разделе про Instant Clone), где база реально монтируется как рабочая.
4. Backup Validation для VM: проверка на уровне приложения
4.1 Что делает эта функция
Backup Validation — механизм для VMware VM, который автоматически запускает VM из резервной копии через live mount и, опционально, выполняет скрипт, проверяющий работоспособность конкретного приложения внутри неё. Это ближе всего к реальной аварийной ситуации: проверка подтверждает, что VM загружается, а приложение внутри VM начинает работать корректно.
4.2 Настройка
Protect → Virtualization→ вкладка VM groups- Открыть нужную VM group → вкладка Configuration
- В разделе Backup validation включить Validate VM Backups
4.3 Какие приложения поддерживаются из коробки
Готовые скрипты валидации, которые поставляются вместе с Virtual Server Agent, есть для двух приложений:
SQL Server. Скрипт логинится, проверяет, что нужные службы запущены, и выполняет SQL-запросы для перечисления баз данных.
Oracle. Скрипт CVGetOracleDBStatus.bat или CVGetOracleDBStatus.sh в зависимости от типа операционной системы. Проверяет, что инстансы Oracle находятся в корректном состоянии (Open Mode или ReadWrite). Если инстанс не в нужном состоянии, скрипт сам пытается перевести базу в OPEN MODE.
Для любого другого приложения (Exchange, PostgreSQL, MySQL и так далее) готового скрипта нет. Но механизм расширяемый: можно написать собственный скрипт и указать его в конфигурации VM group, если он доступен с access node по UNC-пути. Я по той же логике писал несколько скриптов для проверки Exchange и NAS под Veeam.
Если у VM вообще нет обнаруженного приложения (или скрипт не задан), Commvault не пропускает проверку целиком: вместо запуска скрипта он проверяет статус самой VM: дожидается загрузки и проверяет состояние VMware Tools. Это менее содержательная проверка, чем полноценная валидация приложения, но всё же подтверждает, что VM в принципе загружается и остаётся управляемой.
Практическая рекомендация: создавайте отдельную VM group для каждого типа приложения, например одну для VM с SQL Server, другую для VM с Oracle. Так к каждой группе можно прикрепить подходящий именно ей скрипт валидации, вместо того чтобы городить один универсальный скрипт на все случаи.
4.4 Что происходит с VM после проверки
По умолчанию VM, поднятая для валидации, отключается и удаляется после завершения проверки. Это временная операция, а не постоянное развёртывание. Если нужно оставить смонтированную VM для дальнейшего анализа (например, чтобы вручную посмотреть, что пошло не так при провале валидации), в настройках есть опция сохранить провалидированную VM вместо автоматической очистки.
5. Recovery Target и Virtual Lab: изолированная среда для проверки
5.1 Зачем нужна изоляция
Тестовый запуск VM из резервной копии создаёт копию машины с теми же именами, тем же IP-адресом и той же ролью в домене, что и у оригинала. Если запустить такую VM в продуктивной сети как есть, возникнет конфликт: два компьютера с одинаковым именем и IP, а если это контроллер домена, ещё и конфликт репликации AD. Recovery Target с изолированной сетью решает эту проблему, позволяя запустить копию VM отдельно от продуктива.
5.2 Recovery Target
Recovery Target — сохранённая конфигурация назначения для операций восстановления и валидации (какой гипервизор, какой access node, какой датастор использовать). Настраивается один раз и переиспользуется для разных операций: Backup Validation, Live Mount и т. д.
При настройке Recovery Target для изолированной сети нужно скачать шаблон шлюза и указать его в конфигурации. Это шаблон, обеспечивающий сетевой доступ к изолированному сегменту без прямого моста в продуктивную сеть.
5.3 Virtual Lab
Virtual Lab — режим, при котором все VM из VM group поднимаются одновременно в изолированной сети как связанное окружение, а не по одной. Полезно, когда приложение распределено по нескольким VM (например, отдельно сервер приложений и отдельно база данных или сервис, требующий для своей работы доступ к AD) и для полноценной проверки нужно поднять их вместе, сохранив связи между ними.
5.4 Как настроить
Создание Recovery Target:
Auto recovery → Targets→ кнопка Add- Выбрать тип назначения: VMware vCenter
- Заполнить основные параметры: Target name, гипервизор в Destination, Access node, Datastore, Destination network
- В разделе Test Failover Options включить переключатель Configure gateway, если нужна изолированная сеть
- Указать Gateway template (кнопка Browse) и Gateway network
1 комментарий для “Commvault часть 7. Проверка резервных копий”