DPM 1801: Защита DAG Exchange Server 2016

В этой статье мы рассмотрим особенности резервного копирования Exchange Server с помощью System Center Data Protection Manager 1801, настроим резервное копирование группы доступности Exchange 2016 и выполним пробное восстановление. В рассматриваемом примере у нас имеется 2 сервера Exchange 2016, объединённых в DAG. Активные/пассивные копии баз данных распределены равномерно между двумя серверами для балансировки нагрузки.

Как и в прошлых версиях, DPM не может восстанавливать отдельные ящики и элементы сразу в рабочую базу данных Exchange, как делают многие конкурирующие продукты резервного копирования. Вся процедура восстановления проходит только через базу восстановления (Recovery Database).

Это обстоятельство, на мой взгляд, является существенным недостатком DPM. Причины этого в том, что Exchange Server имеет свои инструменты восстановления, которые Microsoft рекомендует использовать. Поэтому разработчики DPM и Windows Server Backup следуют рекомендованной процедуре восстановления с использованием базы восстановления. В итоге имеем то, что имеем: DPM восстанавливает базу в базу восстановления на сервере Exchange или в сетевую папку, затем с помощью командлета New-MailboxRestoreRequest или с помощью сторонних инструментов, таких как Veeam Explorer for Microsoft Exchange мы восстанавливаем отдельные элементы или отдельные ящики. Если посмотреть на проблему с другой стороны, то при корректной настройке политик хранения удалённых элементов и удалённых ящиков в базах Exchange, вероятность возникновения необходимости восстанавливать такие элементы заметно снижается, а с восстановлением баз данных целиком DPM справляется прекрасно.

Официальная документация по резервному копированию Exchange c помощью DPM

Особенности работы DPM с группами доступности DAG

  • Разные узлы DAG можно защищать с разных серверов DPM. Это позволяет гибко планировать схемы резервного копирования и поддерживать большие объемы защищаемых данных.
  • DPM умеет копировать как активные базы данных, так и пассивные.
  • Один DPM сервер может защитить 10 000 ящиков. Если количество п/я больше, необходимо использовать несколько DPM серверов. Также следует учесть ограничение на размер пула хранения в 120 ТБ на один DPM сервер.
  • DPM сервер не умеет определять какая копия базы активная, а какая пассивная, что также, на мой взгляд, является существенным недостатком. Тот же Veritas Backup Exec умеет выполнять резервное копирование из пассивной копии, а если она не доступна — из активной. С DPM же нам необходимо знать заранее какие копии на каких серверах находятся, если мы хотим выбрать определённые копии для защиты.
  • База данных на Exchange сервере может быть переведена из активной в пассивную и наоборот, DPM всё равно будет продолжать её резервное копирование, пока доступен сервер Exchange.
  • Т.к. DPM не понимает какие копии активные, какие пассивные, то отсюда вытекает рекомендация защищать две копии базы данных. Если мы будем бэкапить только одну копию, то при выходе её из строя, DPM не будет выполнять защиту данных, пока мы не восстановим вышедшую из строя БД или пока не настроим его на резервное копирование другой копии БД. А раз защита не будет выполнятся на время перенастройки/восстановления, то мы можем нарушить RPO (recovery point objective) — максимальный период времени, за который могут быть потеряны данные в результате инцидента.
  • Только одна копия базы данных в группе доступности DAG должна бэкапиться с усечением журналов транзакций, остальные копии, необходимо бэкапить с помощью копирующей архивации.

Подготовка к созданию группы защиты Exchange

  • Перед созданием группы защиты для Exchange Server нам понадобится скопировать файлы eseutil.exe и ese.dll из каталога установки Exchange Server (Program Files\Microsoft\Exchange Server\V15\Bin) в папку исполняемых файлов DPM (Program Files\Microsoft System Center\DPM\DPM\bin)
  • Выясняем текущую картину приоритетов активации и распределения активных/пассивных баз данных Exchange:
[PS] C:\Windows\system32>Get-MailboxDatabase | ft Identity,ActivationPreference -auto

Identity ActivationPreference
-------- --------------------
DB01 {[EX1, 1], [EX2, 2]}
DB02 {[EX2, 1], [EX1, 2]}
DB03 {[EX1, 1], [EX2, 2]}
DB04 {[EX2, 1], [EX1, 2]}
DB05 {[EX1, 1], [EX2, 2]}
DB06 {[EX2, 1], [EX1, 2]}
ADB01 {[EX1, 1], [EX2, 2]}
ADB02 {[EX2, 1], [EX1, 2]}
ADB03 {[EX1, 1], [EX2, 2]}
ADB04 {[EX2, 1], [EX1, 2]}
ADB05 {[EX1, 1], [EX2, 2]}
ADB06 {[EX2, 1], [EX1, 2]}

[PS] C:\Windows\system32>Get-MailboxDatabaseCopyStatus * | ft -auto

Name Status CopyQueueLength ReplayQueueLength LastInspectedLogTime ContentIndexState
---- ------ --------------- ----------------- -------------------- -----------------
DB01\EX1 Mounted 0 0 Healthy
DB02\EX1 Healthy 0 0 18.07.2018 12:48:35 Healthy
DB03\EX1 Mounted 0 0 Healthy
DB04\EX1 Healthy 0 0 18.07.2018 12:48:38 Healthy
DB05\EX1 Mounted 0 0 Healthy
DB06\EX1 Healthy 0 0 18.07.2018 12:48:38 Healthy
ADB01\EX1 Mounted 0 0 Healthy
ADB03\EX1 Mounted 0 0 Healthy
ADB02\EX1 Healthy 0 0 18.07.2018 12:37:21 Healthy
ADB04\EX1 Healthy 0 0 18.07.2018 12:46:55 Healthy
ADB05\EX1 Mounted 0 0 Healthy
ADB06\EX1 Healthy 0 0 18.07.2018 12:39:26 Healthy
DB01\EX2 Healthy 0 0 18.07.2018 12:48:23 Healthy
DB02\EX2 Mounted 0 0 Healthy
DB03\EX2 Healthy 0 0 18.07.2018 12:48:01 Healthy
DB04\EX2 Mounted 0 0 Healthy
DB05\EX2 Healthy 0 0 18.07.2018 12:48:33 Healthy
DB06\EX2 Mounted 0 0 Healthy
ADB02\EX2 Mounted 0 0 Healthy
ADB04\EX2 Mounted 0 0 Healthy
ADB01\EX2 Healthy 0 0 18.07.2018 12:42:04 Healthy
ADB03\EX2 Healthy 0 0 18.07.2018 12:48:39 Healthy
ADB06\EX2 Mounted 0 0 Healthy
ADB05\EX2 Healthy 0 0 18.07.2018 12:48:15 Healthy

В моём примере активные и пассивные базы равномерно распределены между двумя серверами.

Создание группы защиты

В консоли DPM открываем мастер создания группы защиты:

В мастере указываем тип создаваемой группы Серверы:

Далее выберем интересующие нас копии баз данных Exchange. В рассматриваемом примере существует лишь 2 копии каждой базы, поэтому согласно рекомендациям и заданному RPO 1 час мы выбираем по две копии каждой базы. Конечно, это не обязательное требование, здесь вы должны исходить из ваших RPO, имеющихся возможностей и требований к хранению резервных копий. Может быть, для вашего случая будет вполне допустимо выполнять резервное копирование одной копии базы данных.

Далее выбираем методы резервного копирования. В этом примере мы будем делать только оперативное копирование на дисковый пул DPM:

Далее выбираем параметры проверки резервной копии. Включаем Запустить программу Eseutil для проверки целостности данных (Run Eseutil to check data integrity), чтобы выполнять проверку целостности баз данных Exchange на стороне DPM сервера, а не Exchange. Это исключит лишние операции ввода-вывода на Exchange Server во время резервного копирования. Для DAG рекомендуется выполнять проверку только для файлов журнала. Если файлы eseutil.exe и ese.dll не были скопированы ранее, возникнет ошибка.

Далее нам необходимо выбрать какие копии БД мы будем бэкапить с помощью полного резервного копирования (Full Backup), а какие с помощью копирующего (Copy Backup). Полное резервное копирование можно выполнять только одной копии БД, т.к. полное резервное копирование происходит с усечением журналов транзакций. В описываемом примере мы выбрали для полного копирования все активные копии баз, а для копирующего — пассивные.

Далее указываем Диапазон хранения (Retention Range) — как долго требуется хранить данные на диске. В поле Частота синхронизации (Synchronization frequency) указываем насколько часто необходимо выполнять добавочное резервное копирование. Если ваш RPO не требует частой синхронизации, можно установить переключатель в параметр «Непосредственно перед точкой восстановления«, чтобы диспетчер DPM выполнял быструю полную архивацию непосредственно перед каждой запланированной точкой восстановления. 

Синхронизация по указанному времени (от 15 минут до 24 часов) относится только к базам данных, которые мы выбрали для полного резервного копирования (Full Backup). Базы данных, которые мы определили в копирующее резервное копирование (Copy Backup) будут попадать в бэкап по расписанию, настроенному для Express Full Backup.

Назначаем хранилища для каждого источника, если необходимо.  Проверяем пространство на диске, выделенное для этой группы защиты. В поле Общий размер данных (Total data size) показан размер данных для резервного копирования, а в поле Место на диске выделенное в DPM (Disk storage to be provisioned on DPM) — объем дискового пространства, выделяемый DPM для группы защиты.

На странице мастера Выбор метода создания реплики (Choose replica creation method) указываем способ выполнения начальной полной репликации данных. Если выбрать репликацию по сети, то рекомендуется выбрать время с наименьшей нагрузкой. Для больших объемов данных или если используется сеть с низкой пропускной способностью можно рассмотреть возможность репликации данных с помощью съемного носителя

Выбираем способ автоматизации проверки согласованности. Проверка согласованности — это процесс с помощью которого DPM проверяет и корректирует несоответствия между защищенным источником данных и его репликой.
DPM может выполнять проверку, когда данные реплики становятся несогласованными или по расписанию. Проверка по расписанию будет выполняться только при обнаружении несоответствий во время синхронизации. Рекомендуется использовать этот параметр для больших рабочих нагрузок или для данных, резервное копирование которых выполняется через WAN. Реплика может стать несогласованной, например из-за непредвиденного завершения работы защищенного компьютера. Проверку можно выполнить вручную в любое время, щелкнув правой кнопкой мыши группу защиты и выбрав команду Выполнить проверку согласованности.

Проверяем итоговые настройки и здесь же мы можем настроить параметры производительности, щёлкнув ссылку Optimize performance:

В открывшемся окне можно настроить смещение времени начала синхронизаций для оптимизации производительности, чтобы они не запускались одновременноСмещение времени запуска синхронизации также может применяться для того, чтобы разные DPM серверы не пересекались между собой по времени начала синхронизации. Также можно включить сжатие данных.

Далее нажимаем кнопку создать группу и дожидаемся завершения создания группы:

Проверяем текущий статус резервных копий баз данных Exchange в консоли DPM:

Процедура восстановления элементов

Восстановление данных в Exchange из резервной копии DPM всегда выполняется через базу данных восстановления (Recovery Mailbox Database), поэтому для начала нам необходимо создать такую база на нашем сервере Exchange. Перед созданием базы данных восстановления необходимо убедиться, что у вас достаточно свободного места на диске, либо выделить отдельный диск под базу восстановления.

Создание базы данных восстановления

Подробнее о базах восстановления см. в официальной документации https://docs.microsoft.com/en-us/Exchange/high-availability/disaster-recovery/recovery-databases

Для создания базы восстановления воспользуемся командлетом New-MailboxDatabase:

New-MailboxDatabase -Server EX1 -Name RDB -Recovery -EdbFilePath "R:\RDB\RDB.edb" -LogFolderPath "R:\RDB"

Также включаем возможность перезаписи этой базы данных:

Set-MailboxDatabase -Identity RDB -AllowFileRestore $true

Если вы проверите папки, которые вы выбрали для размещения базы восстановления, вы заметите, что они пусты. Это нормально, в них мы восстановим файлы базы данных из DPM.

Восстановление базы данных

Восстановление всех элементов Exchange в DPM выполняется только через базу восстановления.

Для восстановления базы данных в консоли DPM открываем раздел «Восстановление» (Recovery), выбираем сервер, который держит нужную копию базы данных и встаём на раздел All Protected Exchange Data. В правой панели выбираем нужную базу данных и находим нужную точку восстановления, после чего нажимаем кнопку Recover:

Для копий баз данных, которые мы распределили по типам резервного копирования Full Backup и Copy Backup будут доступны разные точки восстановления. Для Full Backup доступны точки согласно расписанию синхронизации, для Copy Backup доступны только точки полного резервного копирования (Express Full Backup). На скриншоте выше выбрана база, входящая в Full Backup, а на следующем скриншоте выбрана та же база (пассивная копия) на втором сервере Exchange, которая включена в копирующую архивацию Copy Backup:

В открывшемся мастере восстановления доступны 5 вариантов:

  • Восстановить базу данных в исходное местоположение  — перезаписать существующую копию базы данных Exchange. Для этого у базы данных должен быть включен параметр, разрешающий перезапись.
  • Восстановить базу данных в другую базу данных на сервере Exchange.
  • Восстановить в базу данных восстановления.
  • Восстановить в папку — восстановление базы данных в сетевую или локальную папку.
  • Копирование на ленту — создаёт копию базы данных на ленте.

Для примера я восстановлю базу данных в сетевую папку и открою её с помощью Veeam Explorer for Microsoft Exchange

На сервере, на котором находится сетевая папка должен стоять агент DPM

Далее мастер предложит пометить базу данных как корректно выключенную (это нам не нужно, т.к. мы восстанавливаем не на сервер Exchange). Применим настройки доступа к базе данных, которые установлены для папки, в которую мы восстанавливаем базу данных. Включим ограничение на пропускную способность, если необходимо:

Проверяем все настройки на итоговой странице мастера и нажимаем кнопку Восстановить (Recover).

После успешного восстановления открываем Veeam Explorer for Microsoft Exchange и добавляем восстановленную базу данных для просмотра:

Указываем путь к .edb файлу и папке с журналами транзакций:

Все редакции Veeam поддерживают восстановление объектов Exchange с последующим сохранением, пересылкой по электронной почте или экспортом в архив PST. Редакции Enterprise и Enterprise Plus также позволяют восстанавливать объекты в исходный почтовый ящик.

Восстановление почтового ящика

В консоли DPM открываем раздел «Восстановление» (Recovery), выбираем сервер, который держит нужную копию базы данных. Затем выбираем базу данных для восстановления. Справа появится календарь, на котором жирным цветом отмечены доступные точки восстановления, а справа от календаря выпадающий список с доступными точками по времени выбранного дня. Для копии базы данных, которая бэкапится с помощью копирующей архивации (Copy Backup) доступны только точки последнего полного бэкапа (Express Full Backup).

При выборе базы данных мы увидим входящие в неё почтовые ящики.

Обратите внимание, на скриншоте выше я выбрал архивную базу данных, в которой расположены только архивные почтовые ящики пользователей и DPM ничего, кроме ящиков HealthMailbox, в ней «не видит». Таким образом, если вам необходимо найти архивный п/я пользователя, то это придётся сделать на стороне Exchange сервера, затем восстановить нужную базу в базу данных восстановления и с помощью New-MailboxRestoreRequest восстанавливать архивный ящик.

Щёлкаем на нужном почтовом ящике и нажимаем кнопку восстановить (Recover). При выборе самой последней точки восстановления мы получаем ошибку:

Что же, выбираем предыдущую точку восстановления, раз DPM не в состоянии восстановить из последней.

В открывшемся мастере на начальной странице просмотрим информацию о выбранном объекте и нажимаем далее:

Выбираем вариант восстановления. Для примера я восстановлю базу в базу данных восстановления Recovery Database:

Выбираем сервер назначения и указываем название базы данных восстановления:

Включаем, если необходимо, ограничения по пропускной способности сети и включаем уведомление. Ограничения по пропускной способности сети здесь очень кстати, если восстановление проходит в рабочее время на рабочий сервер.

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

Проверяем корректность введённых данных и нажимаем Восстановить (Recover):

Все задания синхронизации на сервере назначения будут отменены на момент восстановления.

После восстановления база данных будет автоматически смонтирована:

[PS] C:\Windows\system32>Get-MailboxDatabase rdb | ft

Name Server Recovery ReplicationType
---- ------ -------- ---------------
RDB   EX1    True      None

С помощью командлета Get-MailboxStatistics можно посмотреть все доступные ящики в базе восстановления:

Get-MailboxStatistics -Database rdb | Format-Table -auto

Далее помощью командлета New-MailboxRestoreRequest мы можем восстановить почтовый ящик или элементы из базы данных восстановления в рабочий п/я. В работе командлета New-MailboxRestoreRequest есть главная особенность: почтовый ящик в базе восстановления должен идентифицироваться одним из трех значений: DisplayNameMailboxGUID или LegacyExchangeDN, а ящик назначения (куда копируем данные) идентифицируется с помощью его GUID, Alias, LegacyExchangeDN, Domain\Account Name или SMTP адреса.

Восстановление в исходный ящик

Можно восстановить весь почтовый ящик пользователя в исходный п/я. При этом произойдёт слияние резервной копии всего почтового ящика с имеющимся в данный момент почтовым ящиком:

New-MailboxRestoreRequest -SourceDatabase "RDB" -SourceStoreMailbox "Pavel Antipov" -TargetMailbox ant

В параметре -SourceStoreMailbox я использовал Display Name, а в параметре -TargetMailbox я использовал Alias. Если в базе данных существует несколько ящиков с одинаковым Display Name, что возможно, то необходимо использовать MailboxGuid для идентификации.
Получить список ящиков с их GUID по Display Name можно так:

Get-MailboxStatistics -Database RDB | ?{$_.DisplayName -like 'Pavel Antipov*'} | fl DisplayName,MailboxGuid,DisconnectDate

Восстановление в отдельную папку

New-MailboxRestoreRequest -SourceDatabase "RDB" -SourceStoreMailbox "Pavel Antipov" -TargetMailbox ant -TargetRootFolder "Mailbox Restore"

Восстановление отдельных папок из почтового ящика

Для восстановления только отдельных папок необходимо использовать параметр -IncludeFolders, который может принимать список папок. Если имя папки стандартное, например «Входящие», то оно должно быть заключено в ##. Если мы восстанавливаем папку, созданную пользователем, то её имя должно быть заключено в «»

New-MailboxRestoreRequest -SourceDatabase "RDB" -SourceStoreMailbox "Pavel Antipov" -TargetMailbox ant -IncludeFolders "#Inbox#"

New-MailboxRestoreRequest -SourceDatabase "RDB" -SourceStoreMailbox "Pavel Antipov" -TargetMailbox ant -IncludeFolders "Проект"

Список стандартных папок:

  • Inbox
  • SentItems
  • DeletedItems
  • Calendar
  • Contacts
  • Drafts
  • Journal
  • Tasks
  • Notes
  • JunkEmail
  • CommunicationHistory
  • Voicemail
  • Fax
  • Conflicts
  • SyncIssues
  • LocalFailures
  • ServerFailures

Исключение определённых папок из восстановления

Можно также исключить определённые папки из процесса восстановления с помощью параметра -ExcludeFolders

New-MailboxRestoreRequest -SourceDatabase "RDB" -SourceStoreMailbox "Pavel Antipov" -TargetMailbox ant -ExcludeFolders "#Inbox#","#DeletedItems#"

Будут восстановлены все папки, кроме Входящие и Удалённые.

Восстановление в архивный почтовый ящик

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

New-MailboxRestoreRequest -SourceDatabase "RDB" -SourceStoreMailbox "Pavel Antipov" -TargetMailbox ant -TargetRootFolder "Mailbox Restore" -TargetIsArchive

Восстановление в любой другой п/я

По умолчанию командлет New-MailboxRestoreRequest ищет совпадающие LegacyExchangeDN, если же нам нужно восстановить данные в другой ящик, то необходимо использовать параметр -AllowLegacyDNMismatch:

New-MailboxRestoreRequest -SourceDatabase "RDB" -SourceStoreMailbox "Pavel Antipov" -TargetMailbox test.mailbox -TargetRootFolder "Restored Pavel Antipov Mailbox" -AllowLegacyDNMismatch

Мониторинг процесса восстановления:

Вывод всех текущих запросов на восстановление:

Get-MailboxRestoreRequest

Просмотр детальной статистики по запросу:

Get-MailboxRestoreRequest -Name "Pavel Antipov Recovery" | Get-MailboxRestoreRequestStatistics

После завершения не забываем удалять запросы на восстановление:

Get-MailboxRestoreRequest | Where Status -eq Completed | Remove-MailboxRestoreRequest

Удаление базы данных восстановления

После окончания процедуры восстановления можно удалить базу данных восстановления. Базу можно и оставить, если это не противоречит политикам. При следующем восстановлении нужно будет разрешить её перезапись.

Сначала размонтируем базу:

Dismount-Database RDB

Затем удалим базу данных:

Remove-MailboxDatabase RDB

Теперь можно удалить файлы базы восстановления с диска.

Добавить комментарий