Восстановление базы данных Exchange Server 2003 после сбоев
Стратегия резервного копирования и восстановления
Разумеется, для того чтобы иметь хорошую стратегию восстановления, необходимо наличие хорошей стратегии резервного копирования. Применение качественного плана и поддержка консистентности базы данных могут повысить уровень целостности любой базы данных Exchange Server 2003.
Стратегия резервного копирования определяет стратегию восстановления. Планирование этих операций не может осуществляться по отдельности. При разработке стратегии резервного копирования необходимо принимать во внимание то, каким образом будет проводиться восстановление баз данных. Например, следует убедиться, что на диске достаточно свободного места для восстановления как базы данных, так и файлов журналов. Если в течение одной недели создается 2000 файлов журналов, то в итоге может понадобиться восстанавление 10 Гб информации. Прибавьте эту цифру к размерам базы данных, и вы начнете понимать, что планирование стратегии восстановления нужно проводить вместе с планированием резервного копирования.
Нельзя проводить восстановление без уверенности в том, что резервные копии находятся в рабочем состоянии. Следует каждый день проверять проводимые операции резервного копирования, чтобы обеспечить успешное восстановление данных. Если администратор не проверяет
операции резервного копирования, он совершает ошибку, так как не следует всегда подразумевать, что резервные носители заменены, и что данные резервируются корректным образом. Следует каждый день в обязательном порядке просматривать все журналы резервного копирования и устранять любые возникшие ошибки и несоответствия.
Кроме того, необходимо разобраться в работе Extensible Storage Engine (ESE) и Web Storage System (WSS), встроенной в ESE, прежде чем приступать к планированию стратегии резервного копирования и восстановления. В лекции 2 курса "Администрирование почтовых служб на базе Microsoft Exchange Server 2003" рассказывалось о работе этой базы данных. В данной лекции мы более детально рассмотрим компоненты ESE, связанные с восстановлением данных в базе ESE, поэтому вам необходимо четко представлять себе концепции, описанные в гл. 2.
GUID базы данных
Каждая база данных ESE имеет глобально уникальный идентификатор (GUID), присваиваемый базе данных и хранимый в Active Directory. Это необходимо понимать, так как если в какой-либо момент времени имеет место несоответствие GUID-ов, базы данных нельзя будет смонтировать.
GUID почтового ящика
Собственный GUID есть не только у базы данных, но и у каждого почтового ящика в базе данных. GUID почтового ящика является атрибутом учетной записи пользователя в Active Directory, к которой относится почтовый ящик.
Поэтому почтовые ящики можно отключать и подключать между различными учетными записями пользователей. Кроме того, при удалении пользователя из Active Directory почтовый ящик по-прежнему останется в базе данных, если настроено время Deleted Mailbox Retention (Сохранение удаленного почтового ящика). Значением по умолчанию является 30 дней, поэтому при удалении учетной записи пользователя с доступом к почте, почтовый ящик сохраняется в базе данных на протяжении дополнительных 30 дней после удаления пользовательской учетной записи.
Подпись файла журнала
Каждый журнал транзакций имеет уникальную подпись, записываемую в заголовок каждого журнала транзакций в наборе. Если по какой-либо причине в наборе журналов удалены все файлы журналов, то при перезапуске сервера ESE создаст новую последовательность файлов журналов, начиная с первого поколения. Так как файлы журнала могут иметь одинаковые имена, ESE ставит в заголовки каждой последовательности файлов подписи, чтобы отличать последовательности файлов журналов друг от друга.
Циклическое ведение журналов
За исключением серверов Exchange Server 2003, на которых восстановление информации не является обязательным, циклическое ведение журналов использовать не рекомендуется. Циклическое ведение журналов предназначено для снижения требований к хранению журналов транзакций после того, как между транзакциями в журналах и базами данных устанавливается фиксированное соответствие. К счастью, циклическое ведение журналов отключено по умолчанию.
Контрольная сумма
Контрольная сумма (также называется хэшем сообщения) - это строка из 4-байтовых частей, вычисляемая и добавляемая на каждую страницу в базе данных для верификации целостности этой страницы. Контрольная сумма сама по себе не гарантирует целостность данных - вместо этого проводится повторное вычисление контрольной суммы, когда страница считывается в RAM. Тем самым обеспечивается идентичность данных, считываемых из базы данных, и информации, которая была записана в базу данных.
С точки зрения общей структуры страницы, первые 82 байта страницы базы данных содержат информацию заголовка с флагами типа страницы, а также информацию о том, данные какого типа содержит страница. Когда страница загружается в память, вычисляется контрольная сумма и проверяется номер страницы. Если контрольная сумма не совпадает с той контрольной суммой, которая была записана в базу данных, можно быть уверенным в том, что страница повреждена или приведена в негодность. ESE возвратит ошибку, база данных будет остановлена, и в журнал будет занесено событие, информирующее о повреждении.
Обратите внимание, что ESE не вызывает повреждение страницы, а просто информирует о повреждении. Практически во всех случаях повреждение базы данных является результатом неисправности оборудования или драйвера устройства. ESE не может вызывать повреждение страничных файлов. Повреждения происходят при записи данных на диск и являются следствием неправильной работы оборудования или драйверов устройств. По этой причине крайне необходимо быть уверенным в том, что все аппаратное обеспечение и драйвера используют самые последние обновления и надстройки. Служба Microsoft Product Support Services (PSS) может работать совместно с производителем вашего оборудования до устранения всех проблем, возникающих между оборудованием и базой данных Exchange Server 2003.
Обновление одной базы данных
В Exchange Server 2003 можно использовать утилиту резервного копирования, имеющуюся в Windows Server 2003, для резервирования одной базы данных. Если для резервного копирования выбрать одну базу данных, программа резервного копирования создаст резервные копии файлов .edb и .stm этой базы данных, а также скопирует необходимые файлы журналов транзакций в группе хранения. Рекомендуется резервировать весь набор журналов транзакций при резервировании отдельной базы данных.
Вам понадобится наличие разрешений Backup Operator (Оператор резервного копирования) на резервируемом компьютере. Windows Server 2003 при резервном копировании использует разрешения пользователя, работающего в данный момент в системе. Сторонние утилиты резервного копирования могут функционировать как службы Windows 2003, которые используют разрешения из параметров загрузки службы. Как правило, это разрешения, установленные в учетной записи LocalSystem.
Разделы домена и конфигурации
Когда дело доходит до полного восстановления сервера, необходимо понимать, что конфигурационная информация Exchange Server 2003, такая как параметры административной группы или группы маршрутизации, содержится в разделе конфигурации Active Directory. Объекты с доступом к почте находятся в разделе домена, и если у этих объектов есть почтовые ящики, то эти почтовые ящики хранятся в базах данных Exchange.
Следовательно, необходимо помнить о резервном копировании данных Active Directory System State (Состояние системы Active Directory), а также баз данных Exchange. Оба набора данных нужны для полного восстановления системы.
Вам также понадобится осуществлять резервное копирование мета-базы Microsoft Internet Information Services (IIS). Метабаза - это структура для хранения параметров конфигурации IIS, некоторые из которых напрямую связаны с работой по развертыванию Exchange, например с синхронизацией Microsoft Outlook Mobile Access и Microsoft Outlook Web Access. Если не создать резервную копию метабазы IIS, то придется заново создавать или устанавливать компоненты Exchange Server 2003. Метабазу можно просматривать с использованием таких утилит, как MetaEdit и Mdutil.
Не путайте метабазу IIS со службой обновления метабазы в Exchange Server 2003. Служба обновления метабазы считывает данные из Active Directory и записывает их в локальную метабазу IIS. Когда Active Directory уведомляет эту службу о внесении изменений в каталог, служба осуществляет сбор произведенных изменений, после чего автоматически обновляет метабазу.
Часто производится резервное копирование всех файлов на локальном жестком диске. Однако метод резервирования файловой системы не является оптимальным с точки зрения резервирования метабазы IIS, так как метабаза зависит от других компонентов, которые не сохраняются при непосредственном резервировании файловой системы. Кроме того, в файл резервной копии могут вноситься изменения во время резервного копирования. Наилучшим методом резервного копирования является резервирование данных о состоянии системы, в процессе которого осуществляется резервное копирование метабазы.
Типы резервного копирования
С помощью утилиты Windows Server 2003 Backup (и большинства других утилит резервного копирования) можно выполнять пять основных типов резервного копирования. Ключевым отличием между ними является способ изменения бита архивации, который включается в каждый файл Windows Server 2003. При создании или модификации файла бит архивации устанавливается в состояние on (включен), что отражается буквой А в колонке Attributes (Атрибуты) (см. рис. 7.1). После выполнения некоторых типов резервного копирования бит архивации устанавливается в состояние off (отключен), что указывает на создание резервной копии для этого файла. Если администратор вручную установил бит архивации какого-либо файла до начала резервного копирования, то этот файл подлежит резервному копированию вместе с другими файлами.
Имеется пять типов резервного копирования:
- Normal (Обычный).Резервное копирование выполняется для всех выбранных файлов независимо от установки их бита архивации. После резервного копирования бит архивации сбрасывается в состояние off для всех файлов, указывая на то, что для этих файлов получены резервные копии;
- Сору (Копирование).Резервное копирование этого типа выполняется для всех выбранных файлов независимо от установки их бита архивации. После резервного копирования бит архивации любого файла не изменяется;
- Incremental (Добавочное).Резервное копирование выполняется для всех файлов, у которых включен бит архивации. После резервного копирования бит архивации сбрасывается для всех этих файлов;
- Differential (Разностное).Резервное копирование выполняется для всех файлов, у которых включен бит архивации. После резервного копирования бит архивации любого файла не изменяется;
- Daily (Ежедневное).Для всех файлов, измененных ко времени резервного копирования, что определяется по дате модификации, а не по биту архивации, выполняется резервное копирование, и бит архивации не изменяется ни в одном из файлов.
При первоначальной подготовке задания на резервное копирование вручную выбираются файлы, для которых будет создаваться резервная копия. В большинстве программ резервного копирования, включая утилиту Windows 2000 Backup, эти задания можно сохранять и повторно использовать. В некоторых случаях не для всех выбранных файлов будет в действительности выполнено резервное копирование. Для типов normal и сору резервное копирование выполняется для всех выбранных файлов, но для типов incremental, differential или daily выбранные файлы должны также отвечать критериям соответствующего типа резервного копирования, которые мы только что описали.
Все пять типов применимы к данным Exchange 2000, хотя обычно используются только три: normal, differential и incremental. Типы daily и сору обычно применяются только на уровне файлов (документы Word или электронные таблицы Excel). Ниже описывается, что происходит с информацией Exchange 2000 Server при каждом типе резервного копирования.
- Normal - выполняется резервное копирование выбранных хранилищ Exchange, после чего происходит очистка журналов транзакций для этих хранилищ.
- Сору - выполняется резервное копирование выбранных хранилищ Exchange, но журналы транзакций не очищаются.
- Daily - в Exchange резервное копирование типа Daily выполняется так же, как и резервное копирование типа Сору.
- Differential - выполняется резервное копирование только журналов транзакций выбранных хранилищ. Поскольку предполагается, что при использовании типа differential происходит резервное копирование всех изменений, внесенных в хранилища с момента последнего резервного копирования типа normal, то журналы транзакций не очищаются, чтобы для них снова можно было выполнить резервное копирование типа differential или normal.
- Incremental - выполняется резервное копирование только журналов транзакций выбранных хранилищ. Поскольку предполагается, что при использовании типа incremental происходит резервное копирование только тех изменений, которые внесены в хранилища с момента последнего резервного копирования типа normal или incremental, то происходит очистка файлов транзакций.