Главная Exchange/UC, Без рубрики, Новое Восстановление баз данных при помощи ESEUTIL (часть 1)
  • Восстановление баз данных при помощи ESEUTIL (часть 1)

    image_thumb[5]Пусть не часто, но все же бывают ситуации, когда необходимо произвести какие-либо манипуляции с базой данных почтовых ящиков Exchange на достаточно низком уровне. В подавляющем большинстве случаев необходимость такая возникает в аварийных ситуациях, когда нужно восстановить работоспособность базы, либо в совсем критических случаях, для того, чтобы вытащить из неё как можно больше информации. Процедуру дефрагментации базы в расчет не берем, т.к. сервер Exchange 2010 практически в ней не нуждается.

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

    Принцип работы базы данных почтовых ящиков

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

    • · в файле с расширением *.EDB – файл самой базы;
    • · в лог-файлах.

    При этом лог-файлов есть несколько видов

    • · E00.log – это лог файл, используемый в настоящее время механизмом базы данных;
    • · E00tmp.log – новый лог файл, который создается в текущий момент;
    • · E00000003A.log, E00000003B.log, E00000003C.log – это лог файлы, хранящиеся на диске, которые можно использовать для восстановления;
    • · E00res00001.jrs и E00res00002.jrs – это предварительно созданные лог файлы, используемые, когда диск, содержащий лог файлы, заполнен.

    Ещё в папке с логами есть файл E00.chk – это файл контрольной точки, используемой для отслеживания отношений между лог-файлами и файлом базы данных.

    В результате процесс работы базы данных можно проиллюстрировать следующим образом:

    clip_image002

    Рис.1: Работа базы данных

    1. Почтовые данные сначала обрабатываются в памяти, разделяются на страницы (32 Kb – Exchange 2010, 8 Kb – Exchange 2007).
    2. Обновленные страницы, образующие транзакцию, записываются в лог файл – E00.log.
    3. Если страницы больше не требуются, они записываются в базу данных.
    4. Файл контрольной точки (E00.chk) обновляется и отображает новое место контрольной точки, файл E00.log переименовывается в следующий E0000000…log, а на место него приходит E00tmp.log.

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

    В процессе создания и получения новых писем, может возникнуть ситуация когда новая информация находится только в транзакционном логе и еще не была записана в файл базы данных. Следовательно, если некорректно выключить сервер, то часть данных останется в файле E00.log. При этом база будет в состоянии «Неправильного отключения» (Dirty Shutdown).

    Если отключить базу корректно при помощи командлета Unmount-Database, то вся информация будет перемещена в основной файл базы данных (*.EDB) и логи можно будет удалять. При этом база будет в состоянии «Правильного отключения» (Clean Shutdown). Для того, чтобы смонтировать базу на сервер Exchange, её нужно перевести в состояние Clean Shutdown.

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

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

    Реанимация базы данных

    Все манипуляции с файлами базы данных придется производить из командной строки при помощи утилиты ESEUTIL.

    Первое что нам нужно сделать – это оценить обстановку, для этого используем ключи /MH и /ML для получения информации из заголовков файла базы данных и лог-файлов.

    Eseutil /MH MDB.edb

    Eseutil /ML E00.log

    Для проверки целостности всех лог-файлов нужно использовать команду:

    Eseutil /ML E00

    clip_image003

    Рис.2: Заголовок edb-фала.

    clip_image005

    Рис.3: Заголовок лог-файла.

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

    1. State – Dirty Shutdown – говорит нам о том, что база была отключена не корректно;
    2. Информация о связанных лог-файлах;
    3. Сигнатура базы;
    4. Сигнатура лог-файлов;
    5. Системные директории.

    Также можно обратить внимание на строку lGeneration – это номер, под которым будет сохранен текущий лог-файл. А по сигнатурам лог-файлов и базы можно оценить принадлежность этих файлов конкретной базе.

    Оценив ситуацию, давайте перейдем непосредственно к реанимации базы

    Начать стоит с мягкого восстановления, для этого используется ключ /R – Recovery, следующим образом:

    Eseutil /R E00

    При этом нужно обратить внимание на такую вещь, как расположение файла базы данных и лог-файлов. Если мы вернемся к рис.3, то под цифрой 5 на нем указано, где должны лежать системные файлы, лог-файлы и файл базы данных. Следовательно, если мы восстанавливаем базу из архива в альтернативное место, то нам нужно перезаписать эту информацию новыми значениями. Здесь проще всего положить лог-файлы в каталог с самой базой данных и использовать ключик /D для перезаписи путей.

    Примечание: Нужно знать, что совместно с ключом /R ключик /D не дефрагментирует базу, а выполняет перезапись путей. Если переключатель /D указан без пути, в качестве пути к файлам базы данных будет использован текущий каталог. Если сразу за переключателем /D следует путь к файлу (без пробелов), этот путь будет использован для поиска файлов базы данных.

    Если все же вы хотите использовать альтернативные системные директории, то вам понадобятся ключи /S – для системных файлов, /L – для лог-файлов, /D – для файла базы данных. При этом в данном контексте писать путь нужно НЕ отделяя его пробелом от ключа.

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

    Eseutil /R E00 /D /Ld:\temp\logs /Sd:\temp\logs

    clip_image006

    Рис.4: Мягкое восстановление базы данных и проверка состояния файла EDB.

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

    Если в ходе восстановления вы получаете ошибку:

    Operation terminated with error -1216 (JET_errAttachedDatabaseMismatch, An outstanding database attachment has been detected at the start or end of recovery, but database is missing or does not match attachment info)

    то к команде следует добавить ключ /i.

    Заключение

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

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

    Богомолов Алексей (Alexx)

    http://alexxhost.ru

Комментарии

  1. Отличная статья 🙂

  2. что такое сигнатура? сигнатура базы?

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

  4. Alexx, это рандомное число, которое было сформировано при создании базы и соответствующих ей логов, это число неизменная величина. Так?

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

  6. Alexx, подпись? – что вы имеете в виду?
    в разный момент времени подпись разная?
    не могу нагуглить информацию про данному вопросу, если есть какая нибудь ссылочка, дайте пожалуйста

  7. А если я хочу восстановить бэкап в базу с другим именем. Как быть тогда? Сначала создать базу в exchange, а потом подменить файлы или как?

  8. Привет! Зайдите в свойства монтированного Information Store и сбросьте число, указывающее, сколько дней хранить удалённые сообщения, в ноль. Вот только после этого данные, которые могли бы быть удалены при дефрагментации, реально после неё уйдут.