Тщательная подготовка — залог успеха

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

Совет 1. Оцениваем требуемые уровни служб

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

Время восстановления во многом зависит от длительности восстановления Active Directory (AD), системы Exchange и баз данных Exchange с резервных носителей. Поэтому, чтобы оценить время реагирования, требуется сначала определить общее время, необходимое для восстановления полной базы данных и полного сервера. После этого можно оценить время восстановления хранилища Information Store (IS) или полного сервера при оптимальных обстоятельствах. Затем нужно предусмотреть дополнительное время для восстановления после серьезных аварий, чтобы учесть такие факторы, как неполная или нерабочая сетевая инфраструктура и отказы других служб (например, сети хранения данных — SAN, сетевых адаптеров). Чтобы сократить время восстановления, можно уменьшить размеры баз данных, что почти автоматически потребует дополнительных баз данных и групп хранения данных (Storage Group, SG). Максимальное число SG на одном сервере — четыре, и каждая из них может располагать пятью базами данных. Каждая SG создает собственные файлы журналов, поэтому наборы журналов транзакций полезно сохранить отдельно на дисках. Такое распределение информационной нагрузки поможет ускорить восстановление баз данных.

Совет 2. Формируем информационный набор для восстановления после аварии

Рекомендуется подготовить набор аварийного восстановления и надежно сохранить его вне офиса на удаленном сервере, резервной ленте или даже в сейфе на бумаге. В набор входят подробные сведения об именах серверов, паролях, установках, истории установки обновлений и драйверов, истории изменения конфигурации и информация о лицензировании. Кроме того, в него включены сведения о конфигурации дисков и разделов, имя организации Exchange, имена административной группы и группы маршрутизации, информация о состоянии системы и резервные копии метабазы Microsoft IIS. Следует сохранить недавние резервные копии или печатную информацию о месте хранения других резервных носителей, дистрибутивные носители, резервные копии состояния системы и контактную информацию ИТ-специалистов, которые будут восстанавливать различные данные. Если на предприятии есть SAN, необходимо указать контактную информацию соответствующего специалиста. Кроме того, следует регулярно извлекать информацию о пользователях AD, в частности адреса электронной почты, с помощью такой утилиты как LDIFDE или CSVDE, и добавлять эти сведения в набор. Например, экспортировать объекты каталогов, в том числе почтовые адреса, можно с помощью команды

ldifde -f C:export.ldf -v

Совет 3. Резервная копия кворумного диска кластера

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

Чтобы сделать резервную копию кворумного диска, нужно выполнить полное резервное копирование компьютера или состояния системы Windows. С помощью инструмента NTBackup Automated System Recovery (ASR) можно создать гибкий диск ASR для хранения сигнатур дисков. В Windows NT 4.0 и выпусках Windows 2000, предшествующих Service Pack 3 (SP3), можно применить Windows 2000 Resource Kit Cluster Tool (clustool.exe) для резервного копирования конфигурации полного кластера, вместе с сигнатурами дисков. В случае потери кворума и при изменении сигнатуры диска кворума можно использовать утилиты Dumpcfg (dumpcfg.exe) из комплекта ресурсов Windows 2000, чтобы вручную записать сигнатуру на диск кворума. В статье Microsoft «Recovering from an Event ID 1034 on a server cluster» по адресу http://support.microsoft.com/?kbid=280425 содержатся подробные инструкции по использованию Dumpcfg. В Windows Server 2003 можно устранить последствия потери диска кворума с помощью службы кластера и инструмента Windows 2003 Resource Kit Cluster Server Recovery Utility (clusterrecovery.exe). Кроме того, следует обязательно прочитать, понять и протестировать процеду ры, описанные в справочном файле clusterrecovery.chm.

Готовимся заранее

Следует установить график тестов восстановления, чтобы администраторы могли приобрести опыт восстановления сервера Exchange. Проверить корректность резервных копий баз данных необходимо в тестовых лабораториях с использованием группы Recovery Storage Group (RSG). Например, с помощью утилиты Exchange Mailbox Merge (ExMerge) можно извлечь произвольные почтовые ящики из RSG для проверки данных, а инструмент Exchange Disaster Recovery Analyzer (ExDRA) обеспечит проверку целостности данных. Своевременное тестирование процедуры восстановления Exchange позволит лучше подготовиться к гораздо более ответственной задаче ликвидации реальной аварии Exchange.

Менко ден Оуден - Независимый консультант по серверной инфраструктуре Microsoft, Exchange и миграции. Отвечает на вопросы об Exchange на форуме MSExchange.org (http://www.msexchange.org). С ним можно связаться по адресу menko.den.ouden@exor-it.com

Ресурсы Microsoft

Сайт инструментов ExDRA и ExMerge http://www.microsoft.com/technet/prodtechnol/exchange/ downloads/2003/tools.mspx

Руководство по восстановлению Exchange Server 2003 после аварии, http://www.microsoft.com/technet/prodtechnol/exchange/ 2003/library/disrecopgde.mspx

Дополнительные сведения об использовании LDIFDE и CSVDE:

XADM: How to Modify a User?s E-mail Addresses by Using Ldifde, http://support.microsoft.com/?kbid=313823

How to use Csvde to import contacts and user objects into Active Directory, http://support.microsoft.com/?kbid=327620

Другие советы по восстановлению Exchange

Совет 1. План восстановления должен охватывать AD

Во многих случаях восстановлению Exchange сопутствует восстановление Active Directory (AD). В небольших компаниях часто имеется только один сервер для Exchange и AD, и даже на очень крупных предприятиях небольшая ошибка в AD может иметь последствия для всей конфигурации Exchange и AD. AD активно используется в Exchange Server 2003 и Exchange 2000 Server, поэтому необходимо регулярно создавать резервные копии состояния системы контроллера домена (DC), включая AD, реестр, файлы начальной загрузки, службы сертификатов, Microsoft IIS, COM+ и Sysvol. Копировать состояние системы нужно по меньшей мере так же часто, как и Exchange.

Следует тщательно проверить функции резервного копирования и восстановления состояния системы и убедиться, что пространства томов NTDS и Sysvol достаточно для полного восстановления системы. Мне приходилось наблюдать неудачные попытки восстановления глобального каталога (GC) объемом более 2 Гбайт на дисках со свободным пространством свыше 2 Гбайт. Планом восстановления должны быть предусмотрены как принудительные, так и непринудительные процедуры восстановления AD. Например, удаление или изменение важных объектов каталогов в AD в среде с несколькими DC требует принудительного восстановления, а после полного отказа DC из-за аппаратных неисправностей предпочтителен непринудительный режим. Более подробные сведения о процедурах резервного копирования и восстановления AD можно найти в статье «Active Directory Operations Guide» на Web-узле Microsoft TechNet по адресу http://technet2.microsoft.com/windowsserver/en/library/9c6e4dd4-3877-4100-a8e2-5c60c5e19bb01033.mspx.

Совет 2. «Резервный» специалист по Exchange

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

Совет 3. Используйте анализатор аварийного восстановления Exchange

Инструмент Exchange Server Disaster Recovery Analyzer (ExDRA) поможет администраторам в поиске неполадок, связанных с базой данных Exchange. ExDRA собирает данные о конфигурации и заголовки из базы данных и файлов журналов транзакций и создает подробный список проблем базы данных вместе с рекомендациями по их устранению, как показано на экране . Освоить ExDRA необходимо заранее, чтобы уверенно обращаться с инструментом и читать его информацию в напряженных условиях аварии. Бесплатный инструмент ExDRA можно загрузить по адресу http://www.microsoft.com/downloads/details.aspx?familyid=c86fa454-416c-4751-bd0e-5d945b8c107b&displaylang=en.

Если базы данных не монтируются или есть подозрения на неполадки в службе Information Store (IS), следует запустить ExDRA, чтобы отыскать противоречия и ошибки. С помощью ExDRA можно проверить демонтированные IS, дабы выяснить, был ли IS закрыт «чисто» или «грязно». Кроме того, ExDRA покажет, какие команды eseutil.exe и Isinteg.exe необходимы для запуска и восстановления баз данных и файлов журнала транзакций. Типичные проверки ExDRA запускаются следующими командами:

isinteg -s ServerName -test allfoldertests

проверяет целостность табличных структур базы данных IS на высоком уровне (вместо ServerName нужно указать имя конкретного сервера Exchange) и

eseutil /g

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

На начальной стадии неполадок с монтированием базы данных, если есть основания подозревать системные ошибки Windows, переполнение диска или вирусное заражение, следует перезапустить службу Information Store либо целиком сервер Exchange. В процессе запуска службы Information Store выбор «мягкого» режима восстановления — с проверкой непротиворечивости базы данных и воспроизведения журналов незавершенных транзакций — может автоматически устранить проблемы. В статье Microsoft «How to identify logical corruption problems in Exchange Server», http://support.microsoft.com/?kbid=828068, приведены дополнительные сведения о диагностике испорченной базы данных Exchange. Эта статья может стать полезным дополнением к набору инструментов восстановления после аварии.