Exchange 2003: восстановление баз данных

На прошлой неделе у меня проявился "глюк" из-за которого база Exchange начала расти и съедать место. Через 5 дней, утром в прошлый понедельник, база отъела все доступные 75 ГБ свободного пространства на диске "C", это как раз и продемонстрировано на рисунке. Свободного места на системном диске нет, а значит все сервисы полноценно работать не могут, в том числе и почтовый.

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

База данных Microsoft Exchange 2003 хранится в файлах трёх типов:

• файлов хранилища
• файлов журналов
• системные файлов

Файлы хранилища Exchange

Файлы хранилища состоят из файлов c расширением EDB и  STM. Они имеют одинаковые имена и находятся в одной папке, по умолчанию это "C:\Program Files\Exchsrvr\MDBDATA".

По умолчанию при установке Exchange создаются Mailbox Store (Хранилище электронной почты) и Public Folder Store (Хранилище общей папки).

Mailbox Store состоит из двух файлов:

• Priv1.edb - файл базы данных, содержит электронные сообщения, прикрепленные файлы и заголовки электронных сообщений
• Priv1.stm – потоковый файл, содержит мультимедийные данные в формате MIME.

Public Folder Store также состоит из двух файлов:

• Pub1.edb – файл базы данных, содержит сообщения, прикрепленные файлы и заголовки сообщений, хранящихся общих папках.
• Pub1.stm – потоковый файл, содержит мультимедийные данные в формате

Каждый файл EDB ассоциируется с файлом STM. Важно знать, что в STM-файле хранится почта, бегущая по IMAP, а не по SMTP. Если IMAP не используется, при восстановлении базы данных можно удалять STM-файл и позже пересоздать его заново.

Файлы журналов Exchange

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

Microsoft Exchange Server использует журналы транзакций для восстановления в случае аварии. Перед тем, как что-нибудь записать в файл EDB, это записывается в журнал транзакций. После того, как транзакция была занесена в журнал, данные записываются в базу данных. В файле с контрольной точкой содержится информация о последней совершенной транзакцией в журнале транзакций.

Существует следующие журналы транзакций:

• E##.log – текущий журнал транзакций. После того, как файл достигает размера 5MB, он переименовывается в E#######.log и создается новый файл E##.log. Символы ## указывают на номер Группы хранилищ (Storage Group).
• Res1.log, Res2.log – резервные файлы журнала, ограничены 5MB. Когда диск переполняется, транзакции записываются в этот журнал транзакций, пока вы занимаетесь очисткой диска.

Системные файлы Exchange

Существуют два системных файла Tmp.edb – временная база данных, в которую записываются транзакции, и E##.chk - файл с контрольной точкой отслеживает последнюю совершенную транзакцию. Символы ## представляют номер Storage Group - для первой Storage Group файл будет называться E00.chk.

Подготовка восстановления баз данных Exchange

Какие файлы и за что отвечают разобрались. Теперь приступаем к утилитам и командам.

Файлы базы данных Exchange 2003 контролируются службой Microsoft Exchange Information Store, рекомендуют ее отключить. Но помните, для возможности монтирования баз данных эту службу необходимо будет снова запустить.

Прежде всего рекомендую скопировать куда-либо все эти файлы, если вдруг процесс восстановления что-либо повредит, у меня все эти файлы находились в папке "C:\Program Files\Exchsrvr\MDBDATA\"

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

Сначала проверим с помощью утилиты eseutil в каком состоянии находиться наша база данных:

eseutil /mh C:\Program Files\Exchsrvr\MDBDATA\priv1.edb

Найдите строку со "State:" и если Вы наблюдаете "State: Dirty Shutdown", то можно попытаться базу перевести из состояния "Грязного выключения" в состояние "Чистого выключения", тогда мы обойдемся малой кровью, "мягким восстановлением":

eseutil /r "E00" /l "C:\Program Files\Exchsrvr\MDBDATA" /d "C:\Program Files\Exchsrvr\MDBDATA\"

Где:

• E00 - префикс-имя вашего лог файла.
• /l - параметр указывает на папку где находятся лог-файлы
• /d - параметр указывает на папку где находятся базы

Выполнение команды у меня заняло несколько минут - то есть не много времени. После этого снова проверяем статус базы, если вместо "State: Dirty Shutdown" мы видим "State: Clean Shutdown", то поздравляю - стартуйте сервис Microsoft Exchange Information Store и монтируйте базу.

Именно так я и восстановил свои базы. Но пока происходило резервное копирование я готовился к худшему варианту, посему опишу что бы я делал если бы "мягкое восстановление" не помогло.

Жесткое восстановление

В принудительном восстановлении используется все та же утилита eseutil с параметром /p, это  чревато тем, что Вы теряете некоторую часть данных. Данный режим советуют использовать только в крайних случаях, сам процесс достаточно длителен и требователен к ресурсам.

Восстановление включает следующие этапы:

1. Запуск Eseutil /P для выполнения восстановления на уровне таблиц и страниц баз данных.
2. Запуск Eseutil /G для проверки целостности базы. Если тест пройден успешно - приступаем к дефрагментации. Шаг с контролем целостности можно пропустить, если поджимает время.
3. Запуск Eseutil /D для полной переиндексации и дефрагментации базы данных.
4. Запуск Isinteg только для восстановления базы данных на уровне приложений: isinteg –s servername –fix –test alltests . Перед запуском этой команды необходимо запустить службу MSExchangeIS

Для всех этих режимов работы утилиты Eseutil необходимо свободное пространство достигающее 120% от размера базы данных, а так как оно у меня закончилось, то можно использовать какой-либо внешний диск, не забывая использовать параметр /t  в котором необходимо указать что временные файлы должны создаваться на по такому-то адресу на внешнем диске.

Например восстановление:

eseutil /p "C:\Program Files\Exchsrvr\MDBDATA\priv1.edb" /t d:\privtemp.edb

Контроль целостности:

eseutil.exe /g "c:\Program Files\Exchsrvr\MDBDATA\priv1.edb" /t e:\privedbintegrity.edb

Более детальное описания "жесткого" восстановления пока не буду писать, так как этот метод меня обошел стороной.