Немного о резервном копировании в Exchange 2016

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

По истечении срока хранения отключенного почтового ящика такой ящик удаляется безвозвратно.

Подключение отключенного ящика:

ECP — recipients — mailboxes — нажать три точки — Connect a mailbox

Открывшаяся страница показывает отключенные почтовые ящики по конкретному серверу.

Отключенного почтового ящика может не быть в списке в двух случаях:

  1. Если отключили почтовый ящик, в который никто никогда не заходил и в который не отправляли почту. Пустые ящики в Disconnected mailbox не хранятся.
  2. Часто случается ситуация, что с момента отключения ящика до момента, когда он появится в списке отключенных проходит какое-то время — это связано с обновлением кэша в БД. Чтобы не ждать, существует специальный скрипт:
Get-MailboxStatistics
-Database “DBName” | ForEach
{Update-StoreMailboxState -Database $_.Database -Identity $_.MailboxGuid
-Confirm:$False}

Так же в свойствах БД есть отдельная опция «Хранить удалённые элементы до тех пор, пока не создана резервная копия»: вкладка limits — Don’t permanently delete items until the database is backed up.

Если поставить эту галку — удалённые элементы и почтовые ящики не удалятся автоматически, даже если срок хранения прошёл, до тех пор, пока не будет сделан бэкап БД. Т.е. пока Exchange не увидит, что копия БД сделана — он не будет удалять элементы.

Базы данных.

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

Существует множество приложений для организации резервного копирования. Родным приложением для Exchange Server является приложение Windows Server Backup, которое входит в состав Windows Server.
Основным недостатком Windows Server Backup является то, что при восстановлении придётся выполнять большое количество операция в PowerShell’е, а аналоги позволяют делать это в GUI.
Но, в принципе, WSB хватает для резервного копирования.
Если сервер один — рекомендуется делать резервные копии БД раз в 2-3 дня. Если серверов несколько и собран кластер — бэкап можно делать раз в 10-12 дней. Это связано с тем что, по-умолчанию, срок хранения удалённых элементов 14 дней и резервные копии необходимо делать чаще, чем срок хранения.
WSB умеет сохранять резервные копии либо на локальный диск, либо на сетевую шару. На кассеты не умеет.

При использовании Windows Server Backup есть тонкий момент: при резервном копировании БД Exchange необходимо выбирать весь диск целиком, а не папку с БД.
Если необходимо чтобы усекались транзакционные логи — тогда в разделе «Advanced Settings» мастера создания резервной копии WSB необходимо выбрать пункт VSS Settings — VSS full Backup. Если оставить пункт VSS copy Backup — резервные копии выполняться будут, но транзакционные логи усекаться не будут.
Узнать, проводилось резервное копирование базы данных или нет, можно простой командой в PowerShell:

Get-MailboxDatabase -"MailboxDB" -Status | Format-List *backup*

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

Восстановление БД из резервной копии довольно тривиальная операция.

В WSB выбрать пункт Recovery, выбрать в открывшемся календаре дату, на которую хотим восстановить БД (при условии, что в эту дату была резервная копия. Доступные даты выделены полужирным шрифтом).

Далее важный момент — восстанавливаем приложение (Applications), не файлы и папки, а приложение.

Далее выбираем куда восстанавливаем и жмём восстановить.

Dial Tone Recovery

Существует ещё один сценарий восстановления, называется Dial Tone Recovery — это восстановление работы сервиса до того, как мы восстановим данные.

К примеру: в 9 утра упала БД объёмом 1 ТБ. Понятно, что БД в 1 терабайт быстро не восстановить, надо подготовить диски, надо вспомнить как это делается и само восстановление 1 ТБ информации быстро не выполняется. Dial Tone Recovery позволяет нам восстановить работу сервиса без восстановления информации.

Один из вариантов: создать новую БД и перекинуть туда пользователей. Пока восстанавливаем БД. У пользователей будут пустые ящики, но они смогут работать.
После восстановления потерянной БД мы перекидываем пользователей обратно и выполняем слияние баз данных.

Как это делается:

Создаём новую БД:

New-MailboxDatabase -Name TempDB -EdbFilePath "D:\TempDB\TempDB.edb" -LogFolderPath "D:\TempDB" -Server "MailSRV"

Ждём пока БД создастся и примонтируется.
Но у пользователей в конфигурации прописано что их почтовые ящики находятся в  БД, которая сейчас недоступна. Переместить почтовые ящики из одной БД в другую мы не можем, т.к. исходная БД с ящиками не доступна.

Как прописать в конфигурации пользователей что их ящики находятся в другой БД:
Выбираем все почтовые ящики, находящиеся в исходной БД, которая потеряна и  для каждого почтового ящика правим параметр Database, указав новую базу данных.

Get-Mailbox -Database "MailboxDB" | Set-Mailbox -Database "TempDB"

В этом случае, с точки зрения конфигурации, Exchange пройдётся по всем почтовым ящикам из потерянной БД (MailboxDB) и заменит в них информацию о местонахождении почтового ящика на новую базу данных (TempDB).
Клиенты смогут подключиться к ящикам. Да, там будет пусто, но они смогут работать.

К слову, командлет Get-Mailbox -Database «TempDB» — покажет какие почтовые ящики находятся в БД TempDB1, но это информация из конфигурации.
Get-MailboxStatistics — Database «TempDB» — показывает какие почтовые ящики есть в БД TempDB реально.

После того, как перепрописали в конфигурации местонахождение почтовых ящиков на сервере необходимо перезапустить службу Microsoft Exchange Information Store. Иначе пользователи будут по-прежнему пытаться подключиться к старой БД:

Restart-Service MSExchangeIS

Теперь восстанавливаем упавшую базу данных.

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

Get-Mailbox -Database "TempDB1" | Set-Mailbox -Database "MailboxDB"

Не забываем перезапустить службу Mailbox Information Store.

Если почтовые ящики всё равно не доступны (иногда бывает) — необходимо перезапустить web-сервер — можно сделать командой  iisreset — это необходимо делать потому, что web-сервер запомнил кто куда подключался и по-прежнему пытается подключиться к старой БД.

Слияние баз данных

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

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

Для переноса новых писем в основную БД нам необходим только сам файл с базой данных (DBName.edb).
Далее необходимо создать специальную служебную базу данных Recovery. Такая БД нужна исключительно для того, чтобы из неё что-то достать:

New-MailboxDatabase -Name RecoveryDB -EdbFilePath
"d:\TempDB\TempDB.edb" -LogFolderPath
"D:\TempDB" -Server MailSRV -Recovery

Путь должен быть к реальному файлу БД, из которой мы хотим достать письма или ящики. Далее мы её монтируем.
Командлет Get-MailboxDatabse покажет нам что в поле Recovery напротив этой нашей БД стоит ключ True — это значит что в этой базе создать почтовый ящик не получится, эта БД исключительно для восстановления.

Восстанавливаем с помощью специального командлета:

 New-MailboxRestoreRequest -SourceDatabase "RecoveryDB" -SourceStoreMailbox "MailboxName" -TargetMailbox "MailboxName@domain.com"

Отслеживание информации по восстановлению:

Get-MailboxRestoreRequest —выводит статус запроса

Get-MailboxRestoreRequest |Get-MailboxRestoreRequestStatistics — выводит более подробную информацию по всем запросам на восстановление с процентом выполнения.

Иногда случается так. Что процесс восстановления зависает. В таком случае достаточно перезапустить процесс Microsoft Exchange Mailbox Replication.

После восстановления всех писем БД Recovery можно отмонтировать и удалить, она больше не нужна.

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

Восстановление сервера

Делать резервную копию сервера целиком не обязательно, т.к. конфигурация сервера хранится в AD. Т.е. если помер сервер — конфигурация сохраняется в целости.
Ещё на сервере есть БД, но их бекапим отдельно.
Т.е. если упадёт сервер мы теряем:

  • Сертификат
  • Логи (транспортные и системные, прочие)

Для восстановления сервера после падения существует специальная процедура — Восстановление сервера. Выполнить процедуру можно примерно за час + время на восстановление баз данных.

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

Процедуру восстановления сервера можно проводить на любом оборудовании, не обязательно чтобы сервер был идентичен старому. Но версия операционной системы должна быть та же самая, что и на старом сервере!

Порядок восстановления сервера Exchange

  • Подготовка нового сервера или виртуальной машины (после установки ОС сервер не включаем в домен и ставим все необходимые пререквезиты, обновления), так же серверу необходимо дать то же имя, что и у старого сервера и, желательно, тот же IP-адрес (опционально, так удобнее);
  • Пока ставится ОС — выполняем сброс объекта компьютера сервера Exchange (в AD находим объект компьютера сервера Exchange — ПКМ — reset account), теперь можно вводить новый сервер в домен. Если не сбрасывать объект и сразу ввести компьютер в домен — старый объект будет перезаписан новым с новым SID’ом и восстановить сервер уже не получится;
  • Восстановление файлов баз данных (файлы БД должны находиться по тем же путям, что и на старом сервере)
  • Запуск процесс установки Exchange в режиме Recovery (важно чтобы дистрибутив был той же версии, что и на старом сервере, вплоть до накопительных обновлений, т.е. если был Exchange Server 2016 CU1, то и восстанавливать надо такой же). Запуск установки с ключом Recovery установит Exchange Server, взяв конфигурацию упавшего сервера из AD ;
  • Восстановление сертификата Exchange, либо установка нового сертификата;
  • Проверка работоспособности;

Пререквезиты можно взять на technet’е Microsoft по запросу Exchange Server 2016 iis prereq
Так же необходимо заранее установить Unified Communications Managed API (качается по названию с офф.сайта)

Ещё раз: необходимо обязательно сбросить УЗ компьютера в AD перед вводом нового сервера в домен! Иначе придётся строить сервер Exchange с нуля.

Для  установки сервера Exchange в режиме восстановления нам необходимо в PowerShell попасть на диск с дистрибутивом и запустить установку:

setup
/m:RecoverServer /IAcceptExchangeServerLicenseTerms

Теперь установщик инсталлирует нам сервер Exchange ровно в той конфигурации, которая была на старом сервере. Это возможно за счёт того, что мы подготовили сервер с тем же именем и сбросили УЗ компьютера в AD.
Процедура Recovery, при условии, что всё сделано правильно, достаточно безопасна и не ведёт к потере данных.

Первое подключение к ecp достаточно долгое, т.к. в iis идёт инициализация пулов…

Т.к. коннекторы отправки/получения при восстановлении создались такие же, как были на упавшем сервере и, при условии, что IP-адрес не менялся — почта должна ходить нормально.

Резервное копирование Active Directory — обязательная часть резервного копирования почтовой системы! Вся информация о пользователях, базах данных и сервере хранится в AD!

При безвозвратной потере данных из AD восстановить сервер невозможно!

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