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

MapiExceptionNetworkError: Unable to mount database

www.microsoft.com

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


Найти больше информации по настройке и администрированию Exchange 2013 на моем блоге вы сможете в основной статье тематики — Exchange 2013 — Установка, настройка, администрирование.


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

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

Хранилище Exchange 2013 08

Зеленым цветом как раз обозначены данных, которые попали в журналы транзакций, но ещё не были применены к базе. Этот механизм работает автоматически, примененные транзакции отслеживаются с помощью файла контрольных точек (checkpoint file). Подробнее читайте в Хранилище Exchange 2013 — Принцип работы.

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

Хранилище Exchange 2013 04

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

Если же работа сервера была завершена аварийно или произошло некорректное отключение БД, то состояние базы будет Dirty Shutdown:

Хранилище Exchange 2013 05

Как минимум это означает, что база данных находится в несогласованном состоянии и для исправления этой ситуации необходимо применить к ней недостающие транзакции, которые на момент до сбоя были зафиксированы только в журналах транзакций (строчка Log Required явно намекает на это). Этот процесс называется мягкое восстановление (Soft Recovery) и подразумевает следующее:

  1. Файл базы данных находится в исправном состоянии;
  2. Существуют и находятся в исправном состоянии все необходимые журналы транзакций.

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

Мягкое восстановление

Как только вы обнаружили проблемы с базой данных, необходимо действовать в следующем порядке:

  1. Проверить состояние БД (Если в свойстве State видим Clean Shutdown, то все хорошо. Если Dirty Shutdown, двигаемся дальше);
  2. Убедиться, что присутствуют все журналы транзакций и что находятся они в исправном виде;
  3. Попытаться выполнить мягкое восстановление (Soft Recovery).

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

Set-Location 'E:\DB\UserDatabase02'

Ну а теперь посмотрим с чем имеем дело.

Анализ БД

Чтобы просмотреть служебную информацию о БД, выполните команду:

eseutil.exe /mh UserDatabase02.edb

Примечание: Здесь и далее я буду использовать имя базы данных UserDatabase02.

В результате вы получите достаточно много данных и не все они нам нужны. Стоит заострить внимание на секции Fields:

Восстановление баз данных Exchange 2013 01Полезную информацию для нас будут представлять свойства 2:

  • DB Signature — запись, отражающая дату и время создания БД, а также случайное целочисленное значение, уникально идентифицирующее эту базу;
  • cbDbPage — размер страницы (напоминаю, что для Exchange 2010, 2013 это 32КБ, для более ранних версий — 8КБ);
  • Dbtime — количество изменений, примененных к БД;
  • State — состояние. Как я и говорил ранее, бывает только два состояния БД — Clean Shutdown (согласованное) и Dirty Shutdown (несогласованное);
  • Log Required — файлы журналов транзакций, которые необходимы базе данных для того, чтобы она находилась в согласованном состоянии. Для нормально размонтированной базы это значение всегда будет равно 0;

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

Примечание: база данных может перейти в состояние Dirty Shutdown после аварийной перезагрузки сервера (сбой ОС или пропадание питания). Тем не менее, в большинстве случаев после загрузки сервер в состоянии сам смонтировать базу и привести её в согласованное состояние без вмешательства системного администратора. Например специально для этой статьи я имитировал сбой БД путем изменения буквы диска, на котором эта база находилась (спустя пару минут я выставлял диску его прежнюю букву). Через некоторое время я обнаруживал, что база находится в Clean Shutdown и примонтирована к серверу, происходило это полностью без моего участия.

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

Анализ логов

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

Чтобы проверить все имеющиеся логи, нужно ввести только префикс базы данных и воспользоваться ключом /ml:

eseutil.exe /ml E01

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

Как видно из моего примера, все логи базы в порядке и это дает все шансы на успешное выполнение мягкого восстановления. Если у вас возникнет интерес на детальный анализ какого-либо лог-файла, в команде выше вы можете определить его точное имя, например:

eseutil.exe /ml E0100000013.log

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

Из заголовка файла можно получить полезную информацию, включая то, к какой базе он относится, включено ли циклическое ведение журнала и др. Если же файл поврежден, вы можете увидеть что-то подобное:

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). Для меня большая загадка в каких ситуациях это действительно может пригодиться, но все же я не могу не рассказать об этой возможности.

Для получения информации о заголовке файла выполните команду:

eseutil.exe /mk E01.chk

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

Ну а теперь переходим к восстановлению.

Выполнение Soft Recovery

Для запуска мягкого восстановления необходимо воспользоваться ключом /r утилиты eseutil, а также задать префикс базы данных. В простейшем виде (на основе моего примера) команда будет выглядеть следующим образом:

eseutil.exe /r E01

Если необходимо вручную задать путь до логов и базы данных, воспользуйтесь ключами /l и /d соответственно.

При успешном выполнении вы получите результат как на скриншоте:

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

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

eseutil.exe /mh UserDatabase02.edb

Если видим State: Clean Shutdown, значит все хорошо и базу можно монтировать.

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

Если чуда не случилось, читайте статью дальше.

Грубое восстановление

Eseutil в режиме Hard Recovery выполняет только низкоуровневое восстановление данных — сканирует страницы данных и указатели, и в случае обнаружения повреждений, просто удаляет указатели на поврежденные страницы. Учитывая тот факт, что страницы в иерархии B+tree могут занимать самые разные позиции (от корней до листьев дерева), то и потеря данных может сильно разниться.

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

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

Подготовка

Есть несколько базовых рекомендаций:

  1. Первым делом скопируйте каталог с базой в другое расположение. Это необходимо для того, чтобы всегда иметь возможность вернуться к тому с чего начали, если в процессе восстановления что-то пойдет не так;
  2. Обеспечьте достаточный запас свободного места на диске, обычно хватает 20% от объема БД;
  3. Запаситесь терпением, ведь ремонт базы может занять значительное время и исчисляться даже сутками;
  4. Не прерывайте процесс, а если прервали, то начинайте с начала, удалив файлы существующей базы и скопировав на их место бэкап (см. пункт 1.);

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

Переходим к процессу восстановления.

Выполнение Hard Recovery

Необходимость в Hard Recovery может возникнуть в двух случаях: когда неисправен основной файл БД и когда повреждены/отсутствуют необходимые для логической целостности базы журналы транзакций. В моем случае были проблемы с лог-файлами:

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

Тем не менее помните, что процесс восстановления применяется к базе данных, но не к журналам. Просто может быть ситуация, когда базе данных для согласованного состояния необходимы некоторые лог-файлы, которые были безвозвратно утрачены (например как у меня).

Для восстановления выполним команду:

eseutil.exe /p UserDatabase02.edb

Поскольку процесс необратим и в конечном счете приведет к потери той или иной части данных, вы получите предупреждение:

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

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

Примечание: В процессе выполнения задачи вам будет доступен прогрессбар, но для больших и/или очень сильно поврежденных баз у вас может сложиться впечатление, что восстановление замерло на месте или даже зависло. Это нормально, прерывать операцию ни в коем случае не нужно, иначе вы рискуете впустую потратить время..

При успешном завершении операции вы получите сообщение:

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

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

eseutil.exe /mh UserDatabase02.edb

Если видите State: Clean Shutdown, значит все хорошо, но не спешите монтировать базу. На этом процесс восстановления базы закончен, но до здорового состояния данных внутри неё ещё очень далеко, поэтому переходим к следующему этапу.

Дефрагментация

На этом шаге необходимо запустить оффлайн-дефрагментацию базы данных. Строго говоря, это не является обязательным, но крайне рекомендуется. Фактически мы не знаем какая по объему часть данных была удалена, а какая осталась. При большой потери данных может наблюдаться падение производительности и потому важно выполнить дефрагментацию.

Вам необходимо помнить, что:

  • В процессе выполнения дефрагментации создается новая база (и др. файлы), в которую копируются исправные данные. Именно поэтому нужно иметь достаточный запас свободного места на диске, которое должно быть не менее, чем 110% от текущего размера дефрагментируемой базы. Пример файлов, которые были созданы во время дефрагментации моей базы:

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

  • После выполнения дефрагментации оригинальный файл БД удаляется.

Запускаем команду:

eseutil.exe /d UserDatabase02.edb

При успешном завершении операции получаем:

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

Данные дефрагментированы и пора привести их к логической целостности.

Восстановление логической целостности данных

Для проверки логической целостности данных ранее использовался инструмент isinteg 4, но уже к Exchange 2010 он значительно устарел и по сути не поддерживался. Тогда в Exchange 2010 SP1 было добавлено новое средство 5, а именно командлеты:

  • New-MailboxRepairRequest 6
  • New-PublicFolderDatabaseRepairRequest 7

В таком же виде они переехали и в последующие версии Exchange Server. Именно ими и воспользуемся.

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

Ну а дальше монтируем базу командой:

Mount-Database UserDatabase02

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

New-MailboxRepairRequest -Database UserDatabase02 -CorruptionType SearchFolder,AggregateCounts,ProvisionedFolder,FolderView

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

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

Get-MailboxRepairRequest -Database UserDatabase02

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

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

Перенос данных в новую базу

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

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

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

New-MailboxDatabase -Name UserDatabase03 -Server exch02 -EdbFilePath "E:\DB\UserDatabase03\UserDatabase03.edb" -LogFolderPath "E:\DB\UserDatabase03" -OfflineAddressBook "Default Offline Address Book"

Перезапускаем службу банка данных:

Restart-Service MSExchangeIS

Монтируем базу:

Mount-Database UserDatabase03

А теперь необходимо перенести ящики из старой базы в новую:

Get-Mailbox -Database UserDatabase02 | New-MoveRequest -TargetDatabase UserDatabase03 -BatchName "from db02 to db03"

В базе UserDatabase02 у меня был всего лишь один ящик, поэтому и вывод командлета весьма скромный:

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

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

Get-MoveRequest -BatchName "from db02 to db03" | Get-MoveRequestStatistics

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

Подробнее о переносе почтовых ящиков вы сможете прочитать в моей статье — Перемещение почтовых ящиков Exchange 2013, а также в других источниках 8. Про лучшие практики администрирования баз данных читайте в статье Базы данных Exchange 2013.

На этом шаге процесс извлечения данных из поврежденной базы заканчивается. Пришло время рассмотреть более надежный и проверенный способ восстановления данных — восстановление из резервных копий.

Восстановление из резервной копии

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

Восстановление на уровне приложения

WSB на уровне приложения позволяет восстановить целиком либо все базы на сервере враз, либо ни одну. Если у вас одна единственная база, то сценарий восстановления очевиден — заходим в оснастку wbadmin, нажимаем правой кнопкой мышки на Локальная архивация слева и далее по скриншотам:

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

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

База должна восстановиться и смонтироваться без лишнего вмешательства администратора.

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

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

Итак, восстановление одиночной БД в то же самое расположение от сценария выше начнет отличаться с третьего шага:

vosstanovlenie-baz-dannyh-exchange-2013-30

vosstanovlenie-baz-dannyh-exchange-2013-31

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

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

На это обзор вариантов восстановления работоспособности баз данных Exchange 2013 заканчивается. На самом деле есть и другие сценарии, но я рассмотрю их в отдельных статьях. Успехов вам и всегда делайте бэкапы!

comments powered by HyperComments