Восстановление баз данных Exchange 2013 может потребоваться в разных ситуациях и в каждой из них сценарий действий может значительно отличаться в зависимости от состояния базы и наличия свежего бэкапа. В статье я рассмотрю порядок действий при некоторых наиболее часто встречающихся задачах.
Найти больше информации по настройке и администрированию Exchange 2013 на моем блоге вы сможете в основной статье тематики — Exchange 2013 — Установка, настройка, администрирование.
Содержание
Восстановление баз данных Exchange 2013
БД является конечным местом хранения данных, но в процессе работы может наблюдаться ситуация, когда часть информации занесена только в журналы транзакций, а в базу данных попасть ещё не успела. Все это приводит к тому, что база данных находится в несогласованном состоянии и это абсолютно нормально. Этот процесс очень хорошо показан на иллюстрации 1:
Зеленым цветом как раз обозначены данных, которые попали в журналы транзакций, но ещё не были применены к базе. Этот механизм работает автоматически, примененные транзакции отслеживаются с помощью файла контрольных точек (checkpoint file). Подробнее читайте в Хранилище Exchange 2013 — Принцип работы.
В процессе корректного отключения базы данных информация в журналах и во временной базе сбросится в основную БД, база размонтируется и будет находиться в состоянии Clean Shutdown:
Журналы транзакций после этого уже не нужны, ведь информация в них по сути будет дублироваться с основной базой. Они могут потребоваться лишь для сценариев восстановления поврежденной БД и вручную удалять их нельзя.
Если же работа сервера была завершена аварийно или произошло некорректное отключение БД, то состояние базы будет Dirty Shutdown:
Как минимум это означает, что база данных находится в несогласованном состоянии и для исправления этой ситуации необходимо применить к ней недостающие транзакции, которые на момент до сбоя были зафиксированы только в журналах транзакций (строчка Log Required явно намекает на это). Этот процесс называется мягкое восстановление (Soft Recovery) и подразумевает следующее:
- Файл базы данных находится в исправном состоянии;
- Существуют и находятся в исправном состоянии все необходимые журналы транзакций.
В противном случае необходимо проводить грубое восстановление (Hard Recovery), в процессе которого неминуемо будет потеря данных. Сколько именно информации не удастся восстановить, зависит от конкретной ситуации. Вполне возможно, что восстановить базу из резервной копии в этом случае будет более правильным решением. В любом случае ниже мы рассмотрим все возможные сценарии.
Мягкое восстановление
Как только вы обнаружили проблемы с базой данных, необходимо действовать в следующем порядке:
- Проверить состояние БД (Если в свойстве State видим Clean Shutdown, то все хорошо. Если Dirty Shutdown, двигаемся дальше);
- Убедиться, что присутствуют все журналы транзакций и что находятся они в исправном виде;
- Попытаться выполнить мягкое восстановление (Soft Recovery).
Для начала перейдем в каталог с базой данных, чтобы постоянно не прописывать полный путь до файлов:
|
1 |
Set-Location 'E:\DB\UserDatabase02' |
Ну а теперь посмотрим с чем имеем дело.
Анализ БД
Чтобы просмотреть служебную информацию о БД, выполните команду:
|
1 |
eseutil.exe /mh UserDatabase02.edb |
В результате вы получите достаточно много данных и не все они нам нужны. Стоит заострить внимание на секции Fields:
Полезную информацию для нас будут представлять свойства 2:
- DB Signature — запись, отражающая дату и время создания БД, а также случайное целочисленное значение, уникально идентифицирующее эту базу;
- cbDbPage — размер страницы (напоминаю, что для Exchange 2010, 2013 это 32КБ, для более ранних версий — 8КБ);
- Dbtime — количество изменений, примененных к БД;
- State — состояние. Как я и говорил ранее, бывает только два состояния БД — Clean Shutdown (согласованное) и Dirty Shutdown (несогласованное);
- Log Required — файлы журналов транзакций, которые необходимы базе данных для того, чтобы она находилась в согласованном состоянии. Для нормально размонтированной базы это значение всегда будет равно 0;
Судя по скриншоту выше, база находится в несогласованном состоянии и нужно произвести некоторые манипуляции, чтобы это положение дел удачно изменить.
Как только проблема с базой идентифицирована и вы видите, что для согласованного состояния ей не хватает некоторых журналов транзакций, можно двигаться дальше.
Анализ логов
На этом этапе необходимо убедиться, что мы имеем в наличии все необходимые логи и, более того, что все они находятся в исправном состоянии. Eseutil позволяет провести анализ как единичных файлов журналов, так и всех враз. Начнем с последнего варианта.
Чтобы проверить все имеющиеся логи, нужно ввести только префикс базы данных и воспользоваться ключом /ml:
|
1 |
eseutil.exe /ml E01 |
Как видно из моего примера, все логи базы в порядке и это дает все шансы на успешное выполнение мягкого восстановления. Если у вас возникнет интерес на детальный анализ какого-либо лог-файла, в команде выше вы можете определить его точное имя, например:
|
1 |
eseutil.exe /ml E0100000013.log |
Из заголовка файла можно получить полезную информацию, включая то, к какой базе он относится, включено ли циклическое ведение журнала и др. Если же файл поврежден, вы можете увидеть что-то подобное:
|
1 2 |
ERROR: Cannot read log file header. Error -501. Operation terminated with error -501 (JET_errLogFileCorrupt, Log file is corrupt) after 0.47 seconds. |
Есть очень полезная статья 3 на technet, в которой описаны все возможны ошибки, которые вы можете встретить при использовании eseutil.
На самом деле подробно анализировать лог-файлы в большинстве случаев нет никакого смысла, достаточно лишь общего анализа на предмет поиска поврежденных файлов.
Анализ контрольной точки
Помимо анализа заголовков БД и журналов транзакций, вы можете получить информации о состоянии файла контрольных точек (файл с расширением .chk). Для меня большая загадка в каких ситуациях это действительно может пригодиться, но все же я не могу не рассказать об этой возможности.
Для получения информации о заголовке файла выполните команду:
|
1 |
eseutil.exe /mk E01.chk |
Ну а теперь переходим к восстановлению.
Выполнение Soft Recovery
Для запуска мягкого восстановления необходимо воспользоваться ключом /r утилиты eseutil, а также задать префикс базы данных. В простейшем виде (на основе моего примера) команда будет выглядеть следующим образом:
|
1 |
eseutil.exe /r E01 |
Если необходимо вручную задать путь до логов и базы данных, воспользуйтесь ключами /l и /d соответственно.
При успешном выполнении вы получите результат как на скриншоте:
Далее нужно убедиться, что база перешла в согласованное состояние. Для этого выполним уже известную нам команду:
|
1 |
eseutil.exe /mh UserDatabase02.edb |
Если видим State: Clean Shutdown, значит все хорошо и базу можно монтировать.
Если чуда не случилось, читайте статью дальше.
Грубое восстановление
Eseutil в режиме Hard Recovery выполняет только низкоуровневое восстановление данных — сканирует страницы данных и указатели, и в случае обнаружения повреждений, просто удаляет указатели на поврежденные страницы. Учитывая тот факт, что страницы в иерархии B+tree могут занимать самые разные позиции (от корней до листьев дерева), то и потеря данных может сильно разниться.
На этом этапе вам есть смысл подумать над тем, чтобы восстановить базу из резервной копии, если таковая имеется, ведь Hard Recovery может занять много времени, а после него ещё необходимо выполнить дефрагментацию и провести логическую проверку данных. Если бэкапа нет и починить базу — это единственный шанс, то для начала стоит провести некоторые подготовительные действия, чтобы не сделать ещё хуже.
Подготовка
Есть несколько базовых рекомендаций:
- Первым делом скопируйте каталог с базой в другое расположение. Это необходимо для того, чтобы всегда иметь возможность вернуться к тому с чего начали, если в процессе восстановления что-то пойдет не так;
- Обеспечьте достаточный запас свободного места на диске, обычно хватает 20% от объема БД;
- Запаситесь терпением, ведь ремонт базы может занять значительное время и исчисляться даже сутками;
- Не прерывайте процесс, а если прервали, то начинайте с начала, удалив файлы существующей базы и скопировав на их место бэкап (см. пункт 1.);
Переходим к процессу восстановления.
Выполнение Hard Recovery
Необходимость в Hard Recovery может возникнуть в двух случаях: когда неисправен основной файл БД и когда повреждены/отсутствуют необходимые для логической целостности базы журналы транзакций. В моем случае были проблемы с лог-файлами:
Тем не менее помните, что процесс восстановления применяется к базе данных, но не к журналам. Просто может быть ситуация, когда базе данных для согласованного состояния необходимы некоторые лог-файлы, которые были безвозвратно утрачены (например как у меня).
Для восстановления выполним команду:
|
1 |
eseutil.exe /p UserDatabase02.edb |
Поскольку процесс необратим и в конечном счете приведет к потери той или иной части данных, вы получите предупреждение:
Имея бэкап всего каталога с базой данных, сделанный ранее, мы соглашаемся продолжить.
При успешном завершении операции вы получите сообщение:
Чтобы убедиться в нормальном состоянии базы, выполните упоминавшуюся ранее команду:
|
1 |
eseutil.exe /mh UserDatabase02.edb |
Если видите State: Clean Shutdown, значит все хорошо, но не спешите монтировать базу. На этом процесс восстановления базы закончен, но до здорового состояния данных внутри неё ещё очень далеко, поэтому переходим к следующему этапу.
Дефрагментация
На этом шаге необходимо запустить оффлайн-дефрагментацию базы данных. Строго говоря, это не является обязательным, но крайне рекомендуется. Фактически мы не знаем какая по объему часть данных была удалена, а какая осталась. При большой потери данных может наблюдаться падение производительности и потому важно выполнить дефрагментацию.
Вам необходимо помнить, что:
- В процессе выполнения дефрагментации создается новая база (и др. файлы), в которую копируются исправные данные. Именно поэтому нужно иметь достаточный запас свободного места на диске, которое должно быть не менее, чем 110% от текущего размера дефрагментируемой базы. Пример файлов, которые были созданы во время дефрагментации моей базы:
- После выполнения дефрагментации оригинальный файл БД удаляется.
Запускаем команду:
|
1 |
eseutil.exe /d UserDatabase02.edb |
При успешном завершении операции получаем:
Данные дефрагментированы и пора привести их к логической целостности.
Восстановление логической целостности данных
Для проверки логической целостности данных ранее использовался инструмент isinteg 4, но уже к Exchange 2010 он значительно устарел и по сути не поддерживался. Тогда в Exchange 2010 SP1 было добавлено новое средство 5, а именно командлеты:
В таком же виде они переехали и в последующие версии Exchange Server. Именно ими и воспользуемся.
К этому моменту, вероятнее всего, ваша база находится в размонтированном состоянии и это нужно исправить, иначе выполнить проверку не получится. В каталоге с БД осталось много файлов — журналы транзакций, файл контрольной точки и др. На данный момент необходимости в них нет, ведь база находится в согласованном состоянии и лишние логи её буду только смущать, поэтому смело удаляем все файлы из каталога с базой, кроме самой базы.
Ну а дальше монтируем базу командой:
|
1 |
Mount-Database UserDatabase02 |
После этого выполняем полную проверку всей базы (также доступна проверка отдельных ящиков):
|
1 |
New-MailboxRepairRequest -Database UserDatabase02 -CorruptionType SearchFolder,AggregateCounts,ProvisionedFolder,FolderView |
Для указания типа проверки используется ключ -CorruptionType. В одной команде есть возможность выполнять сразу все доступные проверки, как это и сделано в моем примере. Просматривать прогресс выполнения задачи можно командой:
|
1 |
Get-MailboxRepairRequest -Database UserDatabase02 |
На этом, казалось бы, мучительное восстановление базы подошло к концу, но нет… Рекомендуется выполнить ещё одну задачу, на этот раз уже последнюю.
Перенос данных в новую базу
И вот теперь пришло время окончательно избавиться от старого наследия в виде некогда поломанной базы данных и перетащить всю нужную информацию, а именно почтовые ящики, в свежую базу.
Для этого создадим новую БД, пусть она лежит бок о бок со старой на том же диске. Благо в моем случае свободное место это сделать позволяет:
|
1 |
New-MailboxDatabase -Name UserDatabase03 -Server exch02 -EdbFilePath "E:\DB\UserDatabase03\UserDatabase03.edb" -LogFolderPath "E:\DB\UserDatabase03" -OfflineAddressBook "Default Offline Address Book" |
Перезапускаем службу банка данных:
|
1 |
Restart-Service MSExchangeIS |
Монтируем базу:
|
1 |
Mount-Database UserDatabase03 |
А теперь необходимо перенести ящики из старой базы в новую:
|
1 |
Get-Mailbox -Database UserDatabase02 | New-MoveRequest -TargetDatabase UserDatabase03 -BatchName "from db02 to db03" |
В базе UserDatabase02 у меня был всего лишь один ящик, поэтому и вывод командлета весьма скромный:
Поскольку в продакшене в каждой базе содержится обычно больше ящиков, процесс экспорта может затянуться надолго. Проверить состояние запроса на перемещение вы можете командой:
|
1 |
Get-MoveRequest -BatchName "from db02 to db03" | Get-MoveRequestStatistics |
Подробнее о переносе почтовых ящиков вы сможете прочитать в моей статье — Перемещение почтовых ящиков Exchange 2013, а также в других источниках 8. Про лучшие практики администрирования баз данных читайте в статье Базы данных Exchange 2013.
На этом шаге процесс извлечения данных из поврежденной базы заканчивается. Пришло время рассмотреть более надежный и проверенный способ восстановления данных — восстановление из резервных копий.
Восстановление из резервной копии
Предположим, что после развертывания и внедрения Exchange 2013 вы добросовестно настроили регулярное резервное копирование баз данных на уровне приложения (читайте Резервное копирование баз данных Exchange 2013). В случае необратимой поломки БД, у вас всегда будет возможность восстановить базу из резервной копии, но сценарии восстановления могут различаться. Ниже рассмотрим два варианта.
Восстановление на уровне приложения
WSB на уровне приложения позволяет восстановить целиком либо все базы на сервере враз, либо ни одну. Если у вас одна единственная база, то сценарий восстановления очевиден — заходим в оснастку wbadmin, нажимаем правой кнопкой мышки на Локальная архивация слева и далее по скриншотам:
База должна восстановиться и смонтироваться без лишнего вмешательства администратора.
Восстановление отдельных баз
Если на вашем сервере десятки баз данных, то вариант восстанавливать все враз, имея лишь пару поврежденных, не самый лучший. В этой ситуации больше всего подходит восстановление лишь поврежденных БД. В этом случае надо учитывать, что мы лишаемся всех преимуществ восстановления на уровне приложений, поэтому восстановленные базы возможно придется «приводить в чувства» вручную.
Итак, восстановление одиночной БД в то же самое расположение от сценария выше начнет отличаться с третьего шага:
После восстановления необходимо вручную смонтировать базу. Надо отметить, что это у вас может не получиться и тогда необходимо выполнить мягкое восстановление (см. выше в статье).
На это обзор вариантов восстановления работоспособности баз данных Exchange 2013 заканчивается. На самом деле есть и другие сценарии, но я рассмотрю их в отдельных статьях. Успехов вам и всегда делайте бэкапы!
Notes:
- Pro Exchange 2013 SP1 PowerShell Administration: For Exchange On-Premises and Office 365 by Jaap Wesselius and Michel de Rooij ↩
- Pro Exchange 2013 SP1 PowerShell Administration For Exchange On-Premises and Office 365 by Jaap Wesselius and Michel de Rooij ↩
- Extensible Storage Engine Error Codes ↩
- Описание программы Isinteg ↩
- New Exchange Core Store Functionality in Exchange 2010 SP1 ↩
- New-MailboxRepairRequest ↩
- New-PublicFolderDatabaseRepairRequest ↩
- Moving Exchange Server 2013 Mailboxes ↩
