В данной инструкции мы рассмотрим восстановление базы данных почтового сервера Exchange в случае сбоя.
- Windows 2012 R2
- Microsoft Exchange server 2016 (Exchange Management Shell)
В случае корректного отключения базы данных вся информация из журналов и временной базы попадет в основную базу данных. Ее состояние будет обозначено как Clean Shutdown:
После этого информация из журналов транзакций будет повторяться с основной базой, так что они вам уже не понадобятся. Единственный сценарий, в котором они могут пригодиться – это восстановление поврежденной базы данных. Так что вручную удалять их не следует.
В том случае, когда база данных отключена аварийно, она перейдет в состояние Dirty Shutdown:
Такое состояние значит, что база данные не согласована, поэтому нужно к ней применить недостающие транзакции, зафиксированные во время сбоя исключительно в журналах.
Существует несколько вариантов решения данной проблемы:
Чтобы его провести, сначала нужно убедиться, что соблюдены исходные условия для восстановления:
- Файл базы данных исправен;
- Все необходимые журналы транзакций существуют и тоже исправны.
При использовании этого метода вся поврежденная информация будет удалена из базы. Проблема в том, что вы не можете заранее знать, какой именно объем информации поврежден, так что может возникнуть ситуация, когда проще будет восстановить базу из бэкапа, если он, естественно, в наличии.
Мягкое восстановление
Все действия мы будем проводить в Exchange Management Shell.
- Укажем рабочий каталог с базой, чтобы не прописывать каждый раз в команде полный путь.
Set-Location "E:Exbasedata"
- Для просмотра служебной информации базы данных необходимо выполнить команду:
eseutil.exe /mh test_base.edb
Вот такой вывод получится в результате:
Вся нужная нам информация представляется в свойствах:
- State — состояние. Как мы уже отмечали в начале инструкции, база данных может быть в состоянии Clean Shutdown и Dirty Shutdown;
- Log Required — требуются ли файлы журналов, необходимые базе, чтобы перейти в согласованное состояние. Если база размонтирована корректно, то это значение будет равняться 0.
На скриншоте выше мы видим, что наша база данных в несогласованном состоянии. В Dirty Shutdown база может перейти, например, после того, как была осуществлена аварийная перезагрузка сервера. Это может случиться в результате сбоя операционной системы или после грубого отключения питания сервера. После загрузки высока вероятность, что сервер самостоятельно, без помощи системного администратора, смонтирует и переведет в согласованное состояние базу.
Теперь нужно проверить, есть ли у нас все нужные логи и исправны ли они. Для анализа файлов журналов используйте Eseutil. Обращаем ваше внимание, что логи могут храниться в отдельном каталоге, тогда предварительно надо перейти в него. Для проверки имеющихся логов необходимо ввести лишь префикс базы данных, а потом использовать ключ /ml:
eseutil.exe /ml E00
На этом скриншоте видно, что логи базы в полном порядке, так что у нас есть все шансы на то, чтобы успешно провести мягкое восстановление.
Чтобы запустить мягкое восстановление, используем ключ /r утилиты eseutil и задаем префикс базы данных:
eseutil.exe /r E00
Для указания пути к логам и базе данных необходимо использовать ключи /l и /d соответственно.
Если все прошло успешно, вы должны увидеть вот такой результат:
Теперь необходимо удостовериться, что наша база данных приняла согласованное состояние. Для этого выполняем:
eseutil.exe /mh test_base.edb
Если отображается статус State: Clean Shutdown, значит, восстановление закончилось успешно, и можно монтировать базу данных.
В противном случае переходим к попытке грубого восстановления.
Грубое восстановление почтовой базы
Hard Recovery может выполнить восстановление данных только низкого уровня – сканируются указатели и страницы данных, а при обнаружении повреждений – удаляются поврежденные страницы. Последующая потеря данных зависит от того, где находилась удаляемая страница.
Hard Recovery может помочь, если файл базы данных неисправен. Или когда нет необходимых журналов транзакций. Вот здесь, например, нет лог-файлов, которые требуются для корректной работы:
Чтобы провести восстановление, выполняем команду:
eseutil.exe /p test_base.edb
После ее выполнения вы получите предупреждение, ведь этот процесс невозможно обратить, а его результатом так или иначе станет потеря некоторой части данных:
После завершения операции, вы должны увидеть такое сообщение:
Далее проверяем, что база находится в исправном состоянии:
eseutil.exe /mh test_base.edb
Если мы видим состояние Clean Shutdown то восстановление закончено, но монтировать ее еще рано.
Теперь нужно запустить оффлайн-дефрагментацию, поскольку после восстановления мы не можем знать, какую часть данных удалили из базы. Если был потерян большой объем данных, то может сильно снизиться производительность.
- При дефрагментации будет создана новая база, в которую будут перемещаться все исправные данные. Поэтому нужен запас свободного места не меньше, чем 110% от размера текущей базы, для которой проводится дефрагментация.
- Как только дефрагментация завершится, оригинальный файл базы данных будет удален.
Запускаем команду:
eseutil.exe /d test_base.edb
Если операция завершилась успешно, то мы увидим:
После окончания дефрагментации, нужно запустить проверку логической целостности.
Базу данных необходимо смонтировать, иначе не получится провести проверку. После всех наших действий в каталоге с базой могло остаться множество файлов: журналы транзакций и прочие временные файлы. Больше они не нужны, так что можно смело удалить все файлы из каталога базы, кроме самой базы.
Mount-Database test_base
Теперь запускаем проверку всей базы данных. При необходимости вы можете выполнить проверку отдельных ящиков, она также доступна:
New-MailboxRepairRequest -Database test_base -CorruptionType
SearchFolder,AggregateCounts,ProvisionedFolder,FolderView
Чтобы указать тип проверки, используем ключ -CorruptionType. В одной команде можно выполнить сразу все проверки, которые доступны. Выше так и сделано. Чтобы отследить прогресс операции, используем команду:
Get-MailboxRepairRequest -Database test_base
Процесс восстановления базы данных Exchange Server завершен.
