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

Недавно почтовый сервер, верой и правдой отработавший на благо завода 8 лет без перерыва, "протянул ноги". Отказалось монтироваться почтовое хранилище, где была почта трёх организаций, и единственный backup имел возраст 3 года. Поскольку, кроме меня, никаких других администраторов не оказалось, пришлось "на коленке" в полевых условиях восстанавливать почтовую базу, имея самый минимум знаний по Exchange и узкий канал в Интернет. После окончания работы я написал некий Курс молодого бойца, который, надеюсь, пригодится кому-то в трудную минуту.

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

• файлов хранилища (information store);
• файла(-ов) журнала(-ов);
• файла чек-пойнта.

Файлы хранилища делятся на базу данных c расширением EDB (Exchange DataBase) и файл потока с расширением STM (STreaM). Они имеют одинаковые имена и располагаются в одной папке файловой системы. Что хранится в каждом из файлов, описано подробнее в статьях Microsoft MSDN, для нас же важно знать, что в STM-файле хранится почта, бегущая по IMAP, а не по SMTP. Посему, если у вас в организации IMAP не используется, при восстановлении упавшей базы данных можно преспокойно удалять STM-файл и пересоздать его заново. Файлы хранилища можно специальным способом переместить в папку\диск, отличные от места их первоначального создания для того, чтобы почта не "рухнула" вместе с операционной системой (не секрет, что Exchange 2003 по умолчанию ставится в c:\program files\exchsrvr, а первая база, естественно, в c:\program files\exchsrvr\mdbdata). Обычно для хранения этих файлов применяют RAID-1 (зеркалируемый) массив жёстких дисков.

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

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

При обширном инфаркте базы данных файлы лога бесполезны и подлежат удалению.

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

Файлы базы данных Exchange 2003 контролируются базой при помощи службы (service) Microsoft Exchange Information Store (в дальнейшем - sIS), которую придётся в процессе починки время от времени останавливать. Её запуск делает возможным монтирование (mount) хранилища данных в систему Exchange.

Если у вас не монтируется хранилище данных, не паникуйте. Во-первых, отключите sIS для исключения постороннего доступа к файлам данных. Делается это через консоль services.msc.

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

Сейчас придётся немного пошаманить с настройками системы, ибо это здорово облегчит дальнейший труд. Во-первых, найдите жёсткий диск в системе, на котором присутствует достаточное количество свободного места для проведения восстановления. Достаточным считается (со слов Microsoft, конечно) объём пространства, равный 110-120% от суммарного размера файлов ремонтируемого хранилища данных. Если у вас в системе недостаточно места, не отчаивайтесь, самую "тяжёлую" операцию можно провести и вне жёстких дисков системы. Но об этом чуть ниже.

Итак, в корне диска с большим количеством свободного места создайте папку с кратким именем и назначьте её адрес в переменные окружения TEMP и TMP. Например, вы выбрали диск "Е:", создали на нём папку TEMP и теперь с лёгким сердцем в Свойствах системы (вход по Win+Break) в закладке "Дополнительно" ("Advanced") прописываете в окне переменных среды (Environment Variables) TEMP=E:\TEMP и TMP=E:\TEMP.

Найдите на жёстком диске место, куда установлен Exchange. Путь по умолчанию я уже приводил выше, но если не вы устанавливали почтовую систему, то поищите в папках BIN файл eseutil.exe. Найденный путь необходимо добавить к переменной окружения PATH, чтобы в процессе восстановления не прописывать этот путь постоянно. Например, вы нашли Exchange в d:\exch2k3 (действуем всё в том же окне Environment Variables):

PATH=[текущее_значение_оставляем_без_изменений];d:\exch2k3\bin

В настоящий момент подготовительные операции завершены, приступаем к оценке повреждений базы данных. Например, вы нашли файлы лога и чек-пойнта в d:\exch2k3\ mdbdata, а файлы хранилища - в e:\mdbdata. Для определённости представим себе, что у вас только одно хранилище данных с именем E00 и именем файла хранилища priv1, а лог-файл цикличен (один). Тогда создайте в "Блокноте" файл со следующими командами:

del c:\a.txt
eseutil /mh e:\mdbdata\priv1.edb >c:\a.txt
eseutil /ml d:\exch2k3\mdbdata\E00.log >>c:\a.txt
eseutil /mk d:\exch2k3\mdbdata\E00.chk >>c:\a.txt
notepad c:\a.txt
exit

Сохраните файл в любое место жёсткого диска под любым именем с расширением CMD или BAT и запустите его на выполнение. В результате выполнения откроется "Блокнот" с записанными в него тремя журналами проверки: файлов хранилища, файлов лога и файла чек-пойнта. Проанализировав среднюю часть, найдите первый лог-файл, напротив которого НЕ БУДЕТ написано CONSISTENT (то бишь, "присутствует и цел"). Это и есть место сбоя. Удалите все файлы логов, которые относятся к точке аварии и позже.

Теперь попытаемся восстановить базу данных "малой кровью". Для этого запустите службу sIS и в командной консоли (Start-Run-CMD) выполните команды:

d:
cd d:\exch2k3\mdbdata
eseutil /r e:\mdbdata\priv1.edb

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

Если ошибки всё же закрались, и предыдущая команда завершила выполнение с ошибкой (как правило, код ошибки 551), придётся применить проверку целостности перед мягкой починкой. Находясь в командной консоли, выполните команду

isinteg -s [имя_вашего_почтового_сервера] E00 -fix -test alltests

В диалоговом режиме выберите хранилище, подлежащее проверке (чаще это 1, то есть Private Folders; 2 отвечает за Public Folders). Убедитесь, что слева от выбранного хранилища стоит статус Offline (размонтировано либо недоступно), и подтвердите начало проверки вводом Y с клавиатуры. Процесс проверки сильно аппаратнозависим, на слабеньких серверах (например, у меня 16 Гб база крутится на P3-733/384 SDRAM) может затянуться на продолжительное время.

Иногда такую операцию потребуется делать и в дальнейшем, не забывайте об этом. Не забывайте, что для её выполнения требуется запустить sIS!

Если всё завершилось удачно, то вам необходимо немедленно приступать к мягкой починке, иначе продолжайте чтение статьи. Опять остановите sIS.

При серьёзном повреждении хранилища повреждаются файлы EDB и STM. И если вторым в некоторых случаях можно пожертвовать, то первым - никогда. Восстановление работоспособности базы целиком определяется успехом последнего возможного действия: серьёзной починки. Для неё нам не понадобится Серьёзный Сэм, но пригодится весьма серьёзный компьютер, то есть высокомощный, ибо операция требует очень мощной системы для того, чтобы закончиться как можно быстрее. А ведь нам нужно поднять почту как можно быстрее, не так ли?

Если ваш почтовый сервер обладает двумя XEON по 2800 и выше и 2 Гб оперативной памяти, то можете пропустить этот абзац. Всем остальным рекомендую слить файлы priv1.edb и priv1.stm на отдельный жёсткий диск и принести их на высокомощный компьютер, если база очень большая. По сети из почтового сервера копируем в произвольное место папку xchange\BIN и так же, как я писал выше, прописываем на мощном компьютере путь к этой папке в PATH. Также не забудьте прописать в TEMP и TMP путь к папке, в которой свободно, как минимум, 110% от размера файлов хранилища.

Сделайте (на всякий случай) резервные копии файлов хранилища. В командной консоли подаём следующую команду, находясь в папке с priv1.edb:

eseutil /p priv1.edb

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

Мелкомягкие настоятельно рекомендуют сразу после серьёзной починки сделать офлайновую дефрагментацию. Если у вас есть время на это (процесс сильно аппаратнозависим, так что на слабеньких компьютерах рекомендую запускать его по ночам), то после успешно проведённой серьёзной починки (сигналом о которой будет 0 ошибок в финальном отчёте) можете подать в той же консоли команду на дефрагментацию:

eseutil /d priv1.edb 

Обращаю ваше внимание, что обе вышеописанные операции проводятся с явным заданием EDB-файла в качестве аргумента. Не думайте, что про поток забыли. STM-файл починяется и дефрагментируется автоматически вместе с EDB.

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

eseutil /p /d priv1.edb

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

Здесь и только здесь уместно поговорить о пересоздании STM-файла. Да, иногда STM-файл повреждается настолько сильно, что не позволяет остальным компонентам встать. В таком случае приходится его пересоздавать, теряя информацию. Вы можете это проделать, запустив с указанием дополнительного ключа

eseutil /p priv1.edb /createstm

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

Иногда начинающие администраторы впадают в транс, когда им не даёт восстановить работоспособность базы ошибка 1216. Волноваться не надо, просто Exchange сигнализирует о невозможности монтирования базы, которая превысила свой допустимый размер. Например, для оригинального Exchange 2003 Standard Edition это 16 Гб, для Exchange 2003 Standard Edition SP2 это 75 Гб, а для Exchange 2003 Enterprise Edition это 16 Тб. Вы себе представляете 16 терабайт на базу данных? Я - с трудом. А вот выше 16 Гб я уже давно вышел. И всем рекомендую установить SP2 для Exchange 2003 Standard Edition: весит немного (109 Мб), а проку от него - вагон.

Если нет доступа к Интернету и скачать SP2 временно возможности нет, допустимо применение трюка с раздуванием лимита базы при её подключении. Работает этот трюк только до первой перезагрузки Windows Server, так что будьте внимательны и сразу после монтирования хранилища удалите оттуда что-нибудь большое и лишнее. Как это сделать, можно прочитать в MSDN, учтите, что лимит размера базы до установки SP2 временно раздувается не больше, чем на 1 (до 17) гигабайт. Запускаем редактор реестра и ищем раздел HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ MSExchangeIS\<ИМЯ_ВАШЕГО_СЕРВЕРА>\Private-013e2e46-2cd7-4a8e-bfec-0e4652b94b00. Содержимое параметра Database Size Limit in GB представляет собой число (внимательно посмотрите вид отображения!) в гигабайтах, описывающее максимальный размер базы. По умолчанию, после установки SP2 это 18 Гб. Замените 18 на 28 и монтируйте базу :).

Во время установки SP2, если вы на это решились, не забудьте, что будут недоступны все хранилища Exchange, а не только повреждённое, так что или предупредите пользователей, или делайте это в нерабочее время. Службы, обеспечивающие внешние контакты Exchange-узла (например, ADSL- или dialup-телефония), отключать не обязательно.

После восстановления работоспособности Exchange обычно Microsoft настоятельно рекомендует немедленно сделать полную онлайновую дефрагментацию базы. Однако не торопитесь. Смысла особого в ней не будет, пока вы не почистите почту. Зайдите в свойства монтированного Information Store и сбросьте число, указывающее, сколько дней хранить удалённые сообщения, в ноль. Вот только после этого данные, которые могли бы быть удалены при дефрагментации, реально после неё уйдут. Но только при соблюдении двух условий: проведения полной архивации (backup) базы и проведения офлайновой дефрагментации.

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

Комментарии и дополнения приветствуются на моей почте,

дядюшка хардовик Mexicanetz Express,
crowngold.narod.ru