Модуль 6. Восстановление данных

На мой взгляд, это самая важная часть всей серии, потому что возможности, простота и скорость восстановления — то главное, что должно быть в продукте СРК (хотя автоматическую проверку резервных копий тоже можно отнести к главному). В этом модуле разбираем механику восстановления всего, что мы забекапили в 3 и 4 модулях:

• VM
• Active Directory
• SQL Server
• Exchange

Также обсудим, что такое in-place и out-of-place, гранулярное и Point-in-Time восстановление.

В этой статье вы узнаете:

• как работает Browse & Restore и откуда Commvault знает, что восстанавливать
• в чём разница между restore in-place и out-of-place и когда какой вариант выбирать
• как восстановить удалённого пользователя, группу или GPO в Active Directory, и почему для этого важен AD Recycle Bin
• как выполняется Point-in-Time Recovery для SQL Server
• как восстановить отдельное письмо Exchange, не поднимая весь почтовый ящик целиком
• как работает Live VM Browse и почему для Linux-VM без FREL восстановление файлов не заработает

1. Browse & Restore — как это работает

1.1 Откуда Commvault знает, что восстанавливать

Когда администратор открывает Restore для клиента, Commvault не читает данные из хранилища напрямую: сначала он обращается к индексу. Индекс — это каталог всех объектов (файлов, писем, таблиц), защищённых конкретным заданием, с указанием, в каком чанке хранилища физически лежит нужный блок. Поэтому Browse работает быстро даже для больших объёмов данных: система не сканирует Disk Library заново при каждом запросе, а читает готовую структуру индекса.

Browse можно выполнить на разные точки во времени, не только на последний бэкап. Commvault хранит историю заданий и при выборе конкретной даты показывает состояние данных на этот момент, автоматически учитывая нужную комбинацию Full и последующих Incremental копий.

1.2 Restore in-place и out-of-place

In-place (восстановление на то же место): данные возвращаются в исходное расположение, с исходным именем, перезаписывая текущее состояние (или создавая объект заново, если он был удалён). Это стандартный сценарий при потере данных: файл случайно удалили, восстановили туда же.

Out-of-place (восстановление в другое место): данные восстанавливаются с изменёнными параметрами — другое имя, другой путь, другой клиент, другой сервер. Типичные причины использовать out-of-place:

• Нужно проверить содержимое бэкапа, не трогая продуктив
• Нужно создать копию продуктивной базы данных на тестовом сервере
• Исходный сервер недоступен или уничтожен, восстанавливаем на новое железо
• Нужно сравнить восстановленную версию с текущей, не заменяя её

При out-of-place восстановлении Commvault запрашивает дополнительные параметры: целевой клиент (Destination Client), целевой путь, а для баз данных — целевой инстанс. Для большинства агентов в форме восстановления достаточно снять флажок «Restore to same folder» или «In Place» и указать новое назначение.

1.3 Восстановление через staging location

Для некоторых типов данных Commvault сначала восстанавливает данные во временную staging-папку и только потом применяет их к целевому расположению. Например, так устроен Instant Clone для SQL Server. Staging location указывается явно в параметрах восстановления.

2. Гранулярное восстановление Active Directory

2.1 Два разных механизма восстановления AD — не путать между собой

В Commvault есть два принципиально разных пути восстановления Active Directory, и их легко перепутать:

Active Directory Agent (гранулярное восстановление объектов) восстанавливает только отдельные объекты (пользователи, группы, OU, GPO) обратно в живой, работающий AD. Этот агент не может восстановить AD целиком в аварийной ситуации, когда домен-контроллер недоступен: он рассчитан исключительно на точечное восстановление вида «случайно удалили пользователя или группу».

System State (File System Agent): резервная копия самого контроллера домена, включающая базу AD (ntds.dit), SYSVOL и системные файлы. Именно System State нужен для полного восстановления DC при катастрофе, через Non-Authoritative или Authoritative Restore, как мы разбирали в Модуле 4.

На практике оба агента используются вместе: System State — страховка на случай полной аварии, Active Directory Agent — инструмент на каждый день для точечных восстановлений без даунтайма всего домена.

2.2 Восстановление удалённого объекта — пользователя, группы, OU

1. Protect → Active Directory → выбрать AD-сервер
2. На странице сервера найти дерево объектов (Browse). Доступна как обычная навигация по OU/CN, так и поиск по имени
3. Найти нужный объект. Если он был удалён, Commvault покажет его на момент последнего бэкапа, где объект ещё существовал
4. Выбрать объект(ы) → Restore
5. Запустить восстановление

Важное архитектурное ограничение: восстановление выполняется только in-place, то есть объект возвращается туда же, откуда был удалён, с теми же атрибутами. Восстановить объект AD «в другое место» этим агентом нельзя. Это осмысленное ограничение: перемещение пользователя или группы в другой домен как отдельного объекта без контекста было бы бессмысленным.

2.3 AD Recycle Bin — обязательное условие для сохранения SID

Чтобы восстановленный объект сохранил исходный контекст безопасности (тот же SID — Security Identifier, права доступа и членство в группах), на контроллере домена должна быть включена функция AD Recycle Bin.

Без включённого Recycle Bin Commvault всё равно восстановит объект, но создаст его заново с новым SID. Значит, все права доступа, назначенные на старый SID (доступ к файлам, членство в группах, разрешения на ресурсы), не подхватятся автоматически. Пользователь формально «вернётся», но будет восприниматься системой как совершенно новая учётная запись.

2.4 Восстановление паролей вместе с учётной записью

Если требуется восстанавливать не только саму учётную запись, но и её пароль, на контроллере домена нужно заранее разрешить резервное копирование атрибута пароля через утилиту adLdapTool.exe. Она настраивает нужные searchFlags для атрибутов Unicode-Pwd и SID-History.

Без этой настройки Commvault не сохраняет пароль в бэкапе, и Point-in-Time восстановление пароля недоступно: восстанавливается только сам объект.

2.5 Восстановление GPO

Групповые политики (Group Policy Objects) восстанавливаются отдельным механизмом, немного отличающимся от обычных объектов:

1. Protect → Active Directory → выбрать AD-сервер → Restore GPO
2. Появится список доступных для восстановления GPO
3. Выбрать нужные → Restore
4. Указать, как обработать связи (links) GPO с контейнерами (доменами, OU). Доступны три варианта:
   • Revert all links to their original state in the backup: восстановить ссылки ровно в том виде, что были на момент бэкапа. Если после бэкапа были созданы новые ссылки этой GPO, они будут удалены
   • Restore links from backup and merge with existing links: восстановить ссылки из бэкапа, но не трогать те, что были созданы после бэкапа
   • Do not restore any links from backup: восстановить саму GPO без восстановления каких-либо ссылок

3. Point-in-Time Recovery для SQL Server

Point-in-Time Recovery — восстановление базы на любой момент времени, с точностью до секунды.

3.1 Как формируется точка восстановления

Point-in-Time Recovery для SQL Server работает на основе трёх типов копий: Full, Differential и Transaction Log (мы разбирали их настройку в Модуле 4). Когда администратор выбирает конкретный момент времени для восстановления, Commvault автоматически определяет нужную комбинацию:

1. Последний Full backup до указанного момента
2. Последний Differential после этого Full (если есть)
3. Все Transaction Log копии от Differential (или Full) до точно указанного момента времени

База восстанавливается в этой последовательности, и транзакции из логов применяются вплоть до заданной секунды.

3.2 Обязательное условие — Full Recovery Model

Как я писал при настройке резервного копирования MSSQL, Point-in-Time Recovery работает только если база данных находится в Full Recovery Model. В Simple Recovery Model журналы транзакций не сохраняются между бэкапами, и восстановить состояние «на 14:32» физически не из чего: доступны только точки на момент завершения Full или Differential бэкапов.

3.3 Восстановление через Command Center

1. Protect → Databases → SQL Server → выбрать инстанс
2. Restore → Point in time
3. Указать точную дату и время восстановления

1. Выбрать in-place или out-of-place
2. Запустить restore

3.4 Instant Clone — доступ к копии базы без полного восстановления

Отдельная возможность, которую часто упускают: вместо полноценного восстановления базы можно создать Instant Clone — смонтированную, сразу готовую к работе копию базы данных, созданную из существующего бэкапа (обычного или IntelliSnap).

Зачем это нужно:

• Тестовое окружение для отладки проблем, найденных в продуктиве
• Быстрый доступ к данным для отчётов и запросов, не занимая места
• Восстановление отдельных таблиц: сначала создаётся Instant Clone, а затем из него уже выбираются нужные таблицы для точечного восстановления. Так устроен Table-Level Restore для SQL Server в Commvault

Как это работает:

1. Databases → SQL Server → заходим в базу
2. В блоке под Recovery points нажимаем Clone
3. В появившемся мастере выбираем целевой сервер, точку восстановления и дополнительные параметры клона

Для баз крупнее 1 TB Commvault рекомендует включить instant file initialization на стороне SQL Server. Иначе восстановление может занять заметно больше времени, чем ожидается, потому что SQL Server обнуляет файлы данных перед их использованием.

Instant Clone нельзя запустить на том же сервере, с которого была снята резервная копия — только на другом.

3.5 Table-Level Restore — восстановление отдельных таблиц

Восстановить одну повреждённую или случайно изменённую таблицу, не поднимая всю базу целиком, в Commvault можно только через Instant Clone.

Предварительное условие, о котором легко забыть: субклиент должен выполнять block-level backup, и в его настройках заранее должен быть включён переключатель Optimize for table level restore. Без этой настройки, сделанной до бэкапа, таблицы из этого бэкапа для восстановления будут недоступны — задним числом это не включить.

1. Protect → Databases → Instances → выбрать SQL-инстанс → вкладка Subclients
2. Открыть нужный subclient → раздел Settings → включить Optimize for table level restore
3. Выполнить полный бэкап
4. Protect → Databases → Instant clones → создать клон из этого бэкапа
5. Открыть страницу созданного клона → Restore tables
6. Выбрать нужную таблицу → Restore

Совет из документации: при восстановлении таблицы с внешними ключами включай в список на восстановление и зависимые таблицы, иначе связи (foreign key) могут нарушиться после восстановления.

4. Гранулярное восстановление Microsoft Exchange

4.1 Восстановление отдельного письма

Гранулярное восстановление в Exchange работает через Recovery Point — смонтированную копию почтового ящика на конкретный момент времени. Процесс восстановления:

1. Protect → Applications → Exchange → выбрать mailbox
2. Restore → Browse mailbox
3. В дереве папок почтового ящика найти нужное письмо, папку или контакт
4. Выбрать объект(ы) для восстановления
5. Указать назначение: в исходный ящик, в другой ящик, или экспорт в PST-файл

4.2 Восстановление на другой почтовый сервер / ящик

Out-of-place восстановление для Exchange поддерживает восстановление письма или всего ящика в другой почтовый ящик. Полезно, если нужно передать содержимое пользователю с другим адресом (например, при переименовании учётной записи) или создать копию для юридического аудита без риска повлиять на оригинальный ящик.

4.3 Поиск письма по содержимому

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

Для точного поиска по ключевому слову (а не по совпадению части текста) используется специальный префикс dq: перед запросом — exact keyword matching. Эта функция требует, чтобы для Exchange был настроен content indexing: без индексации доступен только поиск по метаданным, а не по содержимому самих писем.

4.4 Экспорт в PST-файл

Кроме восстановления обратно в почтовый ящик, письма можно выгрузить в файл PST. Так удобно передавать данные пользователю без доступа к Exchange, либо архивировать переписку для внешнего хранения.

При экспорте в PST доступны дополнительные опции:

• Include deleted items: включить в выгрузку удалённые (но ещё не устаревшие по retention) элементы
• Limit PST size to: ограничить максимальный размер одного PST-файла. Если данных больше указанного лимита, Commvault автоматически разобьёт выгрузку на несколько PST-файлов

В этом разделе нет скриншотов, и этому есть интересное объяснение:

Checked internally and found this issue is a DEFECT within Commvault. The Exchange standalone database is not yet supported by the Command Center.

Currently, we can not view Exchange Stand Alone Servers in the Command Center. We only display DAGs.

То есть на текущий момент одиночный Exchange-сервер (не кластер) не поддерживается через Command Center (веб-интерфейс), а только через CommCell Console (старый Java-интерфейс). Но раз я с самого начала показываю работу с Commvault именно через Command Center, не вижу смысла сейчас переключаться на CommCell Console.

5. Восстановление виртуальных машин

5.1 Шесть типов восстановления VM

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

• Guest files: восстановление отдельных файлов и папок изнутри гостевой ОС VM без восстановления всей машины
• Virtual machine files: восстановление конфигурации VM и файлов VMDK
• Attach disk to VM: восстановление отдельных VMDK на датастор ESX-хоста и подключение их к уже существующей виртуальной машине
• Full virtual machine: восстановление одной или нескольких VM
• Live recovery: запуск VM прямо из бэкапа, пока полное восстановление выполняется в фоне. VM становится доступна практически сразу, а данные постепенно переносятся на целевое хранилище уже после того, как машина включена
• Live mount: запуск VM непосредственно из хранилища бэкапа, вообще без восстановления

5.2 Live Recovery и Live Mount — в чём разница

Оба механизма позволяют быстро получить рабочую VM без ожидания полного восстановления, но решают разные задачи.

Live Mount запускает VM прямо с хранилища бэкапа. Это вообще не операция восстановления в строгом смысле и обычно не требует доступа к каждому блоку данных бэкапа. Использование строго временное: VM живёт до истечения срока действия, заданного в lifecycle policy, а любые изменения, сделанные внутри неё за это время, не сохраняются после её отключения. Live Mount опирается на кэш на Backup Gateway, под него стоит заранее закладывать место.

Live Recovery создаёт полноценную VM, которая работает на постоянной основе, а не временно. Машина включается почти сразу после запуска операции, а блоки данных из бэкапа постепенно переносятся на целевое хранилище уже во время её работы. То есть VM реально доступна раньше, чем закончится перенос всех данных. ESX-хост, монтирующий NFS-датастор для этой операции, должен уметь разрешать имя MediaAgent: для этого может понадобиться явная запись в hosts-файле на стороне ESX. Также для Live Recovery нужна лицензия VMware на vMotion.

Простое практическое правило: для быстрой проверки работоспособности бэкапа или временного доступа к данным подходит Live Mount. Если нужно как можно быстрее вернуть VM в постоянную эксплуатацию, не дожидаясь полного восстановления, используй Live Recovery.

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

5.3 Live VM Browse — просмотр файлов без полного восстановления VM

Как это работает

Live VM Browse (функционал, который используется при восстановлении типа Guest files) позволяет заглянуть внутрь виртуальной машины в резервной копии и восстановить отдельные файлы, не поднимая VM целиком. Механика зависит от гостевой ОС:

Для Windows VM: снапшот монтируется как временный диск, и Commvault напрямую читает файловую систему NTFS.

Для Linux VM: требуется File Recovery Enabler for Linux (FREL), о котором я говорил в Модуле 3. Без настроенного FREL Windows-прокси физически не может прочитать файловые системы Linux.

Что нужно запомнить

• Browse работает через индекс, а не прямое сканирование хранилища, поэтому Commvault быстро показывает содержимое бэкапа на любую сохранённую дату.
• Out-of-place восстановление — не редкий сценарий, а рабочий инструмент: проверка бэкапов, тестовые копии баз, восстановление на новое железо.
• Point-in-Time для SQL Server автоматически собирает нужную цепочку Full + Differential + Transaction Log, вручную выбирать конкретные файлы логов не требуется.
• Active Directory Agent восстанавливает объекты только in-place и только в уже работающий домен. Для полной аварии контроллера домена нужен бэкап System State.
• AD Recycle Bin — обязательное условие, если восстановленный объект должен сохранить исходный SID и связанные с ним права доступа.
• Live VM Browse для Linux требует FREL.
• Instant Clone для SQL Server даёт быстрый доступ к рабочей копии базы без полноценного восстановления. Полезно для тестовых окружений, отчётов и как основа для Table-Level Restore.