Разумеется, для того чтобы иметь хорошую стратегию восстановления, необходимо наличие хорошей стратегии резервного копирования. Применение качественного плана и поддержка консистентности базы данных могут повысить уровень целостности любой базы данных Exchange Server 2003.
Стратегия резервного копирования определяет стратегию восстановления. Планирование этих операций не может осуществляться по отдельности. При разработке стратегии резервного копирования необходимо принимать во внимание то, каким образом будет проводиться восстановление баз данных. Например, следует убедиться, что на диске достаточно свободного места для восстановления как базы данных, так и файлов журналов. Если в течение одной недели создается 2000 файлов журналов, то в итоге может понадобиться восстанавление 10 Гб информации. Прибавьте эту цифру к размерам базы данных, и вы начнете понимать, что планирование стратегии восстановления нужно проводить вместе с планированием резервного копирования.
Нельзя проводить восстановление без уверенности в том, что резервные копии находятся в рабочем состоянии. Следует каждый день проверять проводимые операции резервного копирования, чтобы обеспечить успешное восстановление данных. Если администратор не проверяет
операции резервного копирования, он совершает ошибку, так как не следует всегда подразумевать, что резервные носители заменены, и что данные резервируются корректным образом. Следует каждый день в обязательном порядке просматривать все журналы резервного копирования и устранять любые возникшие ошибки и несоответствия.
Кроме того, необходимо разобраться в работе Extensible Storage Engine (ESE) и Web
Каждая база данных ESE имеет глобально уникальный идентификатор (GUID), присваиваемый базе данных и хранимый в Active Directory. Это необходимо понимать, так как если в какой-либо момент времени имеет место несоответствие GUID-ов, базы данных нельзя будет смонтировать.
Собственный GUID есть не только у базы данных, но и у каждого почтового ящика в базе данных. GUID почтового ящика является атрибутом учетной записи пользователя в Active Directory, к которой относится почтовый ящик.
Поэтому почтовые ящики можно отключать и подключать между различными учетными записями пользователей. Кроме того, при удалении пользователя из Active Directory почтовый ящик по-прежнему останется в базе данных, если настроено время Deleted
Каждый журнал транзакций имеет уникальную подпись, записываемую в заголовок каждого журнала транзакций в наборе. Если по какой-либо причине в наборе журналов удалены все файлы журналов, то при перезапуске сервера 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, для резервирования одной базы данных. Если для резервного копирования выбрать одну базу данных, программа резервного копирования создаст резервные копии файлов .
Вам понадобится наличие разрешений 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 (отключен), что указывает на создание резервной копии для этого файла. Если администратор вручную установил бит архивации какого-либо файла до начала резервного копирования, то этот файл подлежит резервному копированию вместе с другими файлами.
(рис 7.1) Содержимое папки Mdbdata с установленным для всех файлов битом архивацииИмеется пять типов резервного копирования:
При первоначальной подготовке задания на резервное копирование вручную выбираются файлы, для которых будет создаваться резервная копия. В большинстве программ резервного копирования, включая утилиту Windows 2000 Backup, эти задания можно сохранять и повторно использовать. В некоторых случаях не для всех выбранных файлов будет в действительности выполнено резервное копирование. Для типов normal и сору резервное копирование выполняется для всех выбранных файлов, но для типов incremental,
Все пять типов применимы к данным Exchange 2000, хотя обычно используются только три: normal,
При наличии пяти типов резервного копирования, описанных в предыдущем разделе, большинство администраторов использует только три стратегии для резервного копирования сервера. Все эти стратегии начинаются с полного резервного копирования сервера Exchange, выполняемого на регулярной основе, например, каждое воскресенье. Затем в первой стратегии выполняется полное резервное копирование ежедневно, во второй - добавочное резервное копирование (типа incremental) во все остальные дни недели, и в третьей стратегии требуется разностное резервное копирование (типа
При использовании любой стратегии запланируйте использование журналов транзакций. В каждой стратегии резервного копирования следует использовать ту роль, которую играют журналы транзакций в восстановлении данных до момента аварии. Напомним, что журналы транзакций отражают то, что должно произойти с базой данных в будущем. Часто они содержат фиксированные транзакции, которые еще предстоит записать в эту базу данных. (Подробнее о структуре журнала транзакций см. в гл. 2.)
В случае аварии на сервере Exchange информация, созданная в организации Exchange с момента последнего резервного копирования, может быть восстановлена из журналов транзакций.
Например, если сервер закончил полное резервное копирование прошлым вечером в 23:30, а сегодня в 16:30 произошел отказ диска, содержащего одно из хранилищ Exchange, вы сможете восстановить сегодняшнюю информацию из журналов транзакций. Но при таком методе восстановления предполагается, что журналы транзакций находятся на другом физическом диске. Если эти журналы и хранилище находятся на одном диске, то вы сможете восстановить только версию на 23:30 прошлого вечера, когда было выполнено резервное копирование. Продолжим данный сценарий в предположении, что журналы находятся на отдельном диске, и произошел сбой диска с данным хранилищем. Вам нужно выполнить полное восстановление с ленточной резервной копии, созданной прошлым вечером. При своем запуске процесс store.exe попытается воспроизвести в базе данных все транзакции, содержащиеся в журналах транзакций. По окончании воспроизведения произойдет запуск этой службы, и база данных будет восстановлена в состояние, предшествовавшее моменту аварии.
Если процесс store.exe начинает работу в обычных условиях (без восстановления), например, после нормального отключения и перезапуска
сервера Exchange, то при отсутствии доступа к файлу контрольных точек выполняется воспроизведение всех журналов транзакций. Здесь существенно то, что из этого файла процесс store определяет, какая часть журналов транзакций уже записана в базы данных, а какая еще нет. Если имеется доступ к файлу контрольных точек, то лишь те части журналов транзакций, которые не были записаны в базу данных, будут воспроизведены в ней, если транзакции в журналах более новые, чем транзакции в базе данных.
Процедура резервного копирования начинается с запуска приложения резервного копирования. Это приложение вызывает службу Web
Когда ESE переходит в режим резервирования, открывается новый файл журнала. Например, если
Кроме того, когда начинается резервное копирование, запрашивается считывание системой ESE базы данных и упорядочивание страниц. После упорядочивания страницы группируются во фрагменты по 64 Кб (16 страниц), после чего загружаются в оперативную память. После этого ESE проверяет контрольную сумму для каждой отдельной страницы для подтверждения целостности данных. Если какая-либо из страниц содержит вычисленную контрольную сумму, не совпадающую с контрольной суммой, которая была занесена в страницу при записи страницы на диск, процесс резервного
После успешного завершения резервного копирования и считывания всех страниц утилита резервного копирования копирует журналы и файлы корректировки в резервный набор. Далее файлы журнала усекаются или удаляются в тот момент, когда создается новое поколение файлов в начале резервного копирования. Резервный набор файлов закрывается, ESE переходит в обычный режим, и резервное копирование завершается.
При добавочном или разностном резервном копировании работа производится только с файлами журналов. Операции, включающие в себя файлы корректировки, контрольные суммы или последовательное считывание страниц, не выполняются.
Еще раз представим процесс резервного копирования в виде последовательности шагов.
До сих пор мы описывали процесс оперативного резервного копирования. Существует другой тип резервного копирования, называемый автономным. Автономное резервное копирование отличается от оперативного тем, что база данных останавливается перед началом резервного копирования, что позволяет сохранить копию полноценного файла базы данных. Автономное резервное копирование всегда является полным, так как база данных отключается. Автономное резервное копирование всегда менее предпочтительно, так как перед его осуществлением необходимо демонтировать базу данных.
Перед тем как начать процесс восстановления, необходимо демонтировать базу данных или группу хранения и сделать их недоступными для пользователей. Это можно осуществить с помощью Exchange System Manager (
Когда начинается операция восстановления, хранилище информирует ESE о том, что начинает работу процесс восстановления и ESE переходит в режим восстановления. Агент резервного копирования копирует базу данных с резервного носителя напрямую в конечный путь для базы данных. Помните, что база данных представляет собой пару файлов -.EDN и .
После восстановления файлов журнала и корректировки во временное расположение открывается новая группа хранения восстановления специально для восстановления базы данных. После этого база данных копируется с резервного носителя во временное местоположение (и в группу хранения восстановления). Затем данные из файла корректировок и журналов на резервном носителе копируются в базу данных системой восстановления базы данных.
Из всего сказанного следует, что каждая транзакция в каждом файле журнала интерпретируется следующим образом. Временной штамп каждой транзакции считывается вместе с номером страницы в базу данных, на которую ссылается транзакция. Затем временной штамп на странице в базе данных считывается и сравнивается с временным штампом транзакции в журнале транзакций. Если транзакция в журнале имеет более поздний временной штамп, то транзакция из журнала транзакций записывается в базу данных. В противном случае (временной штамп на странице в базе данных является более поздним, чем временной штамп в транзакции из журнала транзакций) ESE пропускает эту транзакцию и
переходит к следующей транзакции для воспроизведения ее в базу данных.
Следовательно, ESE обрабатывает текущие журналы, что возвращает вас к тому моменту, когда база данных была повреждена (подразумевается, что имеются все журналы транзакций из последнего полного оперативного успешного резервного копирования к моменту сбоя). После этого ESE выполняет действия по очистке, удаляя журнал и файлы корректировки из временного местоположения и удаляя экземпляр хранилища восстановления. Затем группа хранения монтируется в рабочей среде, и происходит монтирование базы данных.
Так как настроечная информация Exchange Server 2003 содержится в разделе конфигурации Active Directory, можно более простым способом восстановить сервер Exchange, нежели в Exchange 5.5. Если сервер Exchange Server 2003, на который восстанавливаются файлы, является членом домена, необходимо убедиться, что работает Active Directory. Запустите Exchange System Manager и убедитесь, что в Active Directory по-прежнему существует действительный объект-сервер для сервера Exchange Server 2003. Если Active Directory отсутствует, восстановите Active Directory перед восстановлением Exchange Server 2003.
Если сервер Exchange, который требуется восстановить, является также контроллером домена, начните с восстановления Active Directory на этом компьютере. Вы сможете восстановить Exchange Server 2003 только после успешного восстановления Active Driectory. Идентификатор безопасности на восстанавливаемом сервере должен соответствовать идентификатору безопасности исходного сервера. Если идентификаторы безопасности различны, нельзя будет осуществить доступ к системе Web
Иногда не требуется восстанавливать весь сервер или всю базу данных целиком. В этом разделе мы будем обсуждать различные варианты восстановления:
Восстановление оперативной резервной копии баз данных является предпочтительным методом восстановления базы данных, так как записи в журнале транзакций отображаются в базе данных в процессе восстановления. При восстановлении из оперативной резервной копии будет использоваться файл корректировок и журналы транзакций. По возможности, следует всегда отдавать предпочтение этому методу восстановления баз данных Exchange Server 2003.
Если требуется заменить оборудование на сервере Exchange Server 2003, рассмотрите проведение автономного резервного копирования и восстановления. Помните, что службы базы данных останавливаются в процессе автономного резервного копирования, поэтому пользователи, чьи почтовые ящики расположены в соответствующей группе хранения, не смогут пользоваться услугами электронной почты до тех пор, пока база данных не будет восстановлена.
Кроме того, может понадобиться автономное резервное копирование баз данных в том случае, если в процессе оперативного резервирования процесс резервного копирования не был успешно завершен из-за возникновения ошибок -1018,-1022 или другой ошибки, связанной с повреждением данных на страничном уровне. Выполнение автономного резервного
Одной из главных проблем, связанных с автономным резервным копированием, является то, что страницы не проверяются на целостность в процессе резервирования, как это происходит при оперативном резервном копировании. Кроме того, недоступна возможность воспроизведения транзакций в базу данных при проведении операции восстановления. По сути, при восстановлении автономной копии происходит восстановление до того момента, когда был остановлен процесс store.exe.
Процесс восстановления автономной резервной копии значительно проще: нужно скопировать базу данных в корректное местоположение на сервере и запустить службы хранилища. Убедитесь, что установлен нужный журнал транзакций, который находился вместе с базой данных перед началом ее монтирования.
Если требуется восстановить один почтовый ящик, для которого истек период сохранения, необходимо либо использовать стороннее программное обеспечение, либо восстановить всю базу данных на сервер восстановления. Так как обе эти процедуры занимают много времени, рекомендуем настроить период сохранения почтового ящика на значение, превышающее по длительности большинство случаев, когда приходилось восстанавливать почтовый ящик. Для этого нужно открыть
(рис 7.2) Настройка времени сохранения удаленного почтового ящика в свойствах хранилищаТак как почтовые ящики являются атрибутами учетной записи пользователей, переподключение почтового ящика к новой учетной записи осуществляется легко. По этой причине, если требуется удалить учетную запись пользователя, почтовый ящик, связанный с этой учетной записью, сохраняется на значительный период времени. Следует указать такой период сохранения, по прошествии которого вы уже будете точно знать, что данный почтовый ящик больше не понадобится.
При удалении почтового ящика он помечается красным крестом в интерфейсе System Manager. Можно подключить почтовый ящик к новой учетной записи пользователя, щелкнув правой кнопкой мыши на почтовом ящике и выбрав команду
Если требуется восстановить одну базу данных, демонтируйте ее с помощью Exchange System Manager и затем восстановите отдельную базу
данных. Обратите внимание, что не требуется останавливать процесс store.exe - он продолжает функционировать. Вместо этого происходит лишь демонтаж базы данных, поверх которой будет происходить восстановление, после чего производится непосредственное восстановление копии с резервного носителя. В процессе восстановления создается специальная группа хранения восстановления, и база данных с журналами транзакций из резервной копии восстанавливается в эту группу хранения. Восстановленная база данных монтируется в исходной группе хранения системой ESE.
Имеется возможность восстановления баз данных на другой сервер Exchange Server 2003, отличный от сервера, с которого производилось резервное копирование. Этот метод следует использовать на крайний случай, когда требуется восстановить отдельные элементы или базы данных, и ни один другой метод не работает. Вторичный сервер должен отвечать аппаратным требованиям, предъявляемым к оборудованию для нормальной работы Exchange: он не должен быть подключен к сети и должен содержать достаточно свободного места на диске для восстановления всей резервной копии.
Чтобы восстановить базу данных на другой сервер, должны совпадать отображаемые имена базы данных и группы. Кроме того, имя организации и административной группы сервера, на который будет проводиться восстановление, должны соответствовать серверу, с которого была создана резервная копия базы данных. Потребуется настроить текущие базы данных так, чтобы разрешить их перезапись; это необходимо для того, чтобы новые базы данных с новыми подписями могли записываться поверх старых в процессе восстановления.
При этом методе восстанавливаются только базы данных ESE, поэтому такой подход не следует использовать для восстановления всего сервера. После копирования или перемещения всех баз данных на другой сервер необходимо настроить разрешения для почтовых ящиков, прежде чем пользователи смогут с ними работать.
Если имеется большое число почтовых ящиков, которые необходимо подключить к соответствующим учетным записям Active Directory, используйте программу MBCONN (файл mbconn.exe, утилита
Server). Эта утилита особенно полезна тогда, когда только что был удален или добавлен новый сервер Exchange в организацию Exchange. Если вы знакомы с утилитой Exchange 5.5 DS/IS
Большая часть сторонних приложений, осуществляющих резервное копирование, резервирует отдельные почтовые ящики с обеспечением выборочного резервирования на уровне элементов (например, резервируется отдельная календарная запись или отдельное сообщение). Если не используется резервное копирование на уровне почтового ящика или если используется утилита Windows Backup, период сохранения удаленного почтового ящика истек и требуется восстановить отдельный почтовый ящик, необходимо использовать автономный сервер и восстановить на нем почтовый ящик. В большинстве случаев этого не потребуется из-за наличия возможностей сохранения почтового ящика, таких как Dumpster и ExMerge. Но все же давайте рассмотрим действия, которые нужно выполнить, если вам понадобится данный подход.
Во-первых, убедитесь, что автономный сервер находится в другом лесу Windows Server 2003, нежели рабочие серверы. Во-вторых, группа хранения, содержащая восстанавливаемую базу данных, должна иметь такое же отображаемое имя, как и исходный рабочий сервер. В-третьих, база данных, которую требуется восстановить, должна иметь такое же отображаемое имя, как и исходный рабочий сервер. Имя базы данных должно быть уникальным на сервере резервного копирования для всех групп хранения. Например, если именем базы данных является Priv.
Чтобы восстановить почтовый ящик, повторно подключите почтовый ящик к пользовательской учетной записи
В данном разделе описываются требования к восстановлению и действия, предпринимаемые в следующих сценариях:
Существует пять общих требований к восстановлению всех серверов Exchange Server 2003:
Чтобы произвести полное восстановление рядового сервера Windows Server 2003, выполните следующие шаги.
Для успешного выполнения операции резервного копирования или восстановления необходимо действовать согласно ряду рекомендаций, проверенных на деле.
Одной из новых интересных возможностей в Windows 2003 является служба Volume Shadow Copy (VSC). Эта служба позволяет значительно сократить время, требуемое для резервирования и восстановления баз данных Exchange Server 2003. Служба VSC работает с приложениями резервного копирования и оборудованием для теневого резервного копирования баз данных Exchange Server 2003.
По сути, VSC запрашивает очень короткую паузу в работе Exchange Server 2003 для сброса структур памяти в базы данных, а также запрашивает паузы в новых транзакциях и завершение текущих транзакций. После этого происходит быстрое аппаратное копирование баз данных в нейтральное расположение на сервере.
После выполнения действия по копированию рабочие базы данных разблокируются для дальнейшего использования, в то время как версия теневой копии используется для создания резервной копии на ленте. По умолчанию после завершения резервирования теневых баз данных теневая копия удаляется.
В последующих версиях этой функции, возможно, появится возможность планирования дополнительных периодических теневых копий в течение дня, которые можно будет оставить на диске и использовать во время операций восстановления. Эта возможность снижает объем данных, теряемый при откате к более ранним экземплярам базы данных, и значительно увеличивает скорость восстановления баз данных.
В данной лекции обсуждались основные принципы и подходы к выполнению операций резервного копирования и восстановления. Мы выделили способы восстановления баз данных Exchange, рассказали об основных шагах, которые следует выполнять для восстановления всего сервера целиком, а также привели краткое описание того, как функция VSC в Windows Server 2003 используется для сведения к минимуму времени, затрачиваемого на восстановление. Если базы данных были повреждены, или что-то в процессе работы пошло не так, как надо, обязательно используйте шаги, приведенные в этой лекции, для восстановления баз данных и информации Exchange.
Разумеется, для того чтобы иметь хорошую стратегию восстановления, необходимо наличие хорошей стратегии резервного копирования. Применение качественного плана и поддержка консистентности базы данных могут повысить уровень целостности любой базы данных Exchange Server 2003.
Стратегия резервного копирования определяет стратегию восстановления. Планирование этих операций не может осуществляться по отдельности. При разработке стратегии резервного копирования необходимо принимать во внимание то, каким образом будет проводиться восстановление баз данных. Например, следует убедиться, что на диске достаточно свободного места для восстановления как базы данных, так и файлов журналов. Если в течение одной недели создается 2000 файлов журналов, то в итоге может понадобиться восстанавление 10 Гб информации. Прибавьте эту цифру к размерам базы данных, и вы начнете понимать, что планирование стратегии восстановления нужно проводить вместе с планированием резервного копирования.
Нельзя проводить восстановление без уверенности в том, что резервные копии находятся в рабочем состоянии. Следует каждый день проверять проводимые операции резервного копирования, чтобы обеспечить успешное восстановление данных. Если администратор не проверяет
операции резервного копирования, он совершает ошибку, так как не следует всегда подразумевать, что резервные носители заменены, и что данные резервируются корректным образом. Следует каждый день в обязательном порядке просматривать все журналы резервного копирования и устранять любые возникшие ошибки и несоответствия.
Кроме того, необходимо разобраться в работе Extensible Storage Engine (ESE) и Web
Каждая база данных ESE имеет глобально уникальный идентификатор (GUID), присваиваемый базе данных и хранимый в Active Directory. Это необходимо понимать, так как если в какой-либо момент времени имеет место несоответствие GUID-ов, базы данных нельзя будет смонтировать.
Собственный GUID есть не только у базы данных, но и у каждого почтового ящика в базе данных. GUID почтового ящика является атрибутом учетной записи пользователя в Active Directory, к которой относится почтовый ящик.
Поэтому почтовые ящики можно отключать и подключать между различными учетными записями пользователей. Кроме того, при удалении пользователя из Active Directory почтовый ящик по-прежнему останется в базе данных, если настроено время Deleted
Каждый журнал транзакций имеет уникальную подпись, записываемую в заголовок каждого журнала транзакций в наборе. Если по какой-либо причине в наборе журналов удалены все файлы журналов, то при перезапуске сервера 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, для резервирования одной базы данных. Если для резервного копирования выбрать одну базу данных, программа резервного копирования создаст резервные копии файлов .
Вам понадобится наличие разрешений 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 (отключен), что указывает на создание резервной копии для этого файла. Если администратор вручную установил бит архивации какого-либо файла до начала резервного копирования, то этот файл подлежит резервному копированию вместе с другими файлами.
(рис 7.1) Содержимое папки Mdbdata с установленным для всех файлов битом архивацииИмеется пять типов резервного копирования:
При первоначальной подготовке задания на резервное копирование вручную выбираются файлы, для которых будет создаваться резервная копия. В большинстве программ резервного копирования, включая утилиту Windows 2000 Backup, эти задания можно сохранять и повторно использовать. В некоторых случаях не для всех выбранных файлов будет в действительности выполнено резервное копирование. Для типов normal и сору резервное копирование выполняется для всех выбранных файлов, но для типов incremental,
Все пять типов применимы к данным Exchange 2000, хотя обычно используются только три: normal,
При наличии пяти типов резервного копирования, описанных в предыдущем разделе, большинство администраторов использует только три стратегии для резервного копирования сервера. Все эти стратегии начинаются с полного резервного копирования сервера Exchange, выполняемого на регулярной основе, например, каждое воскресенье. Затем в первой стратегии выполняется полное резервное копирование ежедневно, во второй - добавочное резервное копирование (типа incremental) во все остальные дни недели, и в третьей стратегии требуется разностное резервное копирование (типа
При использовании любой стратегии запланируйте использование журналов транзакций. В каждой стратегии резервного копирования следует использовать ту роль, которую играют журналы транзакций в восстановлении данных до момента аварии. Напомним, что журналы транзакций отражают то, что должно произойти с базой данных в будущем. Часто они содержат фиксированные транзакции, которые еще предстоит записать в эту базу данных. (Подробнее о структуре журнала транзакций см. в гл. 2.)
В случае аварии на сервере Exchange информация, созданная в организации Exchange с момента последнего резервного копирования, может быть восстановлена из журналов транзакций.
Например, если сервер закончил полное резервное копирование прошлым вечером в 23:30, а сегодня в 16:30 произошел отказ диска, содержащего одно из хранилищ Exchange, вы сможете восстановить сегодняшнюю информацию из журналов транзакций. Но при таком методе восстановления предполагается, что журналы транзакций находятся на другом физическом диске. Если эти журналы и хранилище находятся на одном диске, то вы сможете восстановить только версию на 23:30 прошлого вечера, когда было выполнено резервное копирование. Продолжим данный сценарий в предположении, что журналы находятся на отдельном диске, и произошел сбой диска с данным хранилищем. Вам нужно выполнить полное восстановление с ленточной резервной копии, созданной прошлым вечером. При своем запуске процесс store.exe попытается воспроизвести в базе данных все транзакции, содержащиеся в журналах транзакций. По окончании воспроизведения произойдет запуск этой службы, и база данных будет восстановлена в состояние, предшествовавшее моменту аварии.
Если процесс store.exe начинает работу в обычных условиях (без восстановления), например, после нормального отключения и перезапуска
сервера Exchange, то при отсутствии доступа к файлу контрольных точек выполняется воспроизведение всех журналов транзакций. Здесь существенно то, что из этого файла процесс store определяет, какая часть журналов транзакций уже записана в базы данных, а какая еще нет. Если имеется доступ к файлу контрольных точек, то лишь те части журналов транзакций, которые не были записаны в базу данных, будут воспроизведены в ней, если транзакции в журналах более новые, чем транзакции в базе данных.
Процедура резервного копирования начинается с запуска приложения резервного копирования. Это приложение вызывает службу Web
Когда ESE переходит в режим резервирования, открывается новый файл журнала. Например, если
Кроме того, когда начинается резервное копирование, запрашивается считывание системой ESE базы данных и упорядочивание страниц. После упорядочивания страницы группируются во фрагменты по 64 Кб (16 страниц), после чего загружаются в оперативную память. После этого ESE проверяет контрольную сумму для каждой отдельной страницы для подтверждения целостности данных. Если какая-либо из страниц содержит вычисленную контрольную сумму, не совпадающую с контрольной суммой, которая была занесена в страницу при записи страницы на диск, процесс резервного
После успешного завершения резервного копирования и считывания всех страниц утилита резервного копирования копирует журналы и файлы корректировки в резервный набор. Далее файлы журнала усекаются или удаляются в тот момент, когда создается новое поколение файлов в начале резервного копирования. Резервный набор файлов закрывается, ESE переходит в обычный режим, и резервное копирование завершается.
При добавочном или разностном резервном копировании работа производится только с файлами журналов. Операции, включающие в себя файлы корректировки, контрольные суммы или последовательное считывание страниц, не выполняются.
Еще раз представим процесс резервного копирования в виде последовательности шагов.
До сих пор мы описывали процесс оперативного резервного копирования. Существует другой тип резервного копирования, называемый автономным. Автономное резервное копирование отличается от оперативного тем, что база данных останавливается перед началом резервного копирования, что позволяет сохранить копию полноценного файла базы данных. Автономное резервное копирование всегда является полным, так как база данных отключается. Автономное резервное копирование всегда менее предпочтительно, так как перед его осуществлением необходимо демонтировать базу данных.
Перед тем как начать процесс восстановления, необходимо демонтировать базу данных или группу хранения и сделать их недоступными для пользователей. Это можно осуществить с помощью Exchange System Manager (
Когда начинается операция восстановления, хранилище информирует ESE о том, что начинает работу процесс восстановления и ESE переходит в режим восстановления. Агент резервного копирования копирует базу данных с резервного носителя напрямую в конечный путь для базы данных. Помните, что база данных представляет собой пару файлов -.EDN и .
После восстановления файлов журнала и корректировки во временное расположение открывается новая группа хранения восстановления специально для восстановления базы данных. После этого база данных копируется с резервного носителя во временное местоположение (и в группу хранения восстановления). Затем данные из файла корректировок и журналов на резервном носителе копируются в базу данных системой восстановления базы данных.
Из всего сказанного следует, что каждая транзакция в каждом файле журнала интерпретируется следующим образом. Временной штамп каждой транзакции считывается вместе с номером страницы в базу данных, на которую ссылается транзакция. Затем временной штамп на странице в базе данных считывается и сравнивается с временным штампом транзакции в журнале транзакций. Если транзакция в журнале имеет более поздний временной штамп, то транзакция из журнала транзакций записывается в базу данных. В противном случае (временной штамп на странице в базе данных является более поздним, чем временной штамп в транзакции из журнала транзакций) ESE пропускает эту транзакцию и
переходит к следующей транзакции для воспроизведения ее в базу данных.
Следовательно, ESE обрабатывает текущие журналы, что возвращает вас к тому моменту, когда база данных была повреждена (подразумевается, что имеются все журналы транзакций из последнего полного оперативного успешного резервного копирования к моменту сбоя). После этого ESE выполняет действия по очистке, удаляя журнал и файлы корректировки из временного местоположения и удаляя экземпляр хранилища восстановления. Затем группа хранения монтируется в рабочей среде, и происходит монтирование базы данных.
Так как настроечная информация Exchange Server 2003 содержится в разделе конфигурации Active Directory, можно более простым способом восстановить сервер Exchange, нежели в Exchange 5.5. Если сервер Exchange Server 2003, на который восстанавливаются файлы, является членом домена, необходимо убедиться, что работает Active Directory. Запустите Exchange System Manager и убедитесь, что в Active Directory по-прежнему существует действительный объект-сервер для сервера Exchange Server 2003. Если Active Directory отсутствует, восстановите Active Directory перед восстановлением Exchange Server 2003.
Если сервер Exchange, который требуется восстановить, является также контроллером домена, начните с восстановления Active Directory на этом компьютере. Вы сможете восстановить Exchange Server 2003 только после успешного восстановления Active Driectory. Идентификатор безопасности на восстанавливаемом сервере должен соответствовать идентификатору безопасности исходного сервера. Если идентификаторы безопасности различны, нельзя будет осуществить доступ к системе Web
Иногда не требуется восстанавливать весь сервер или всю базу данных целиком. В этом разделе мы будем обсуждать различные варианты восстановления:
Восстановление оперативной резервной копии баз данных является предпочтительным методом восстановления базы данных, так как записи в журнале транзакций отображаются в базе данных в процессе восстановления. При восстановлении из оперативной резервной копии будет использоваться файл корректировок и журналы транзакций. По возможности, следует всегда отдавать предпочтение этому методу восстановления баз данных Exchange Server 2003.
Если требуется заменить оборудование на сервере Exchange Server 2003, рассмотрите проведение автономного резервного копирования и восстановления. Помните, что службы базы данных останавливаются в процессе автономного резервного копирования, поэтому пользователи, чьи почтовые ящики расположены в соответствующей группе хранения, не смогут пользоваться услугами электронной почты до тех пор, пока база данных не будет восстановлена.
Кроме того, может понадобиться автономное резервное копирование баз данных в том случае, если в процессе оперативного резервирования процесс резервного копирования не был успешно завершен из-за возникновения ошибок -1018,-1022 или другой ошибки, связанной с повреждением данных на страничном уровне. Выполнение автономного резервного
Одной из главных проблем, связанных с автономным резервным копированием, является то, что страницы не проверяются на целостность в процессе резервирования, как это происходит при оперативном резервном копировании. Кроме того, недоступна возможность воспроизведения транзакций в базу данных при проведении операции восстановления. По сути, при восстановлении автономной копии происходит восстановление до того момента, когда был остановлен процесс store.exe.
Процесс восстановления автономной резервной копии значительно проще: нужно скопировать базу данных в корректное местоположение на сервере и запустить службы хранилища. Убедитесь, что установлен нужный журнал транзакций, который находился вместе с базой данных перед началом ее монтирования.
Если требуется восстановить один почтовый ящик, для которого истек период сохранения, необходимо либо использовать стороннее программное обеспечение, либо восстановить всю базу данных на сервер восстановления. Так как обе эти процедуры занимают много времени, рекомендуем настроить период сохранения почтового ящика на значение, превышающее по длительности большинство случаев, когда приходилось восстанавливать почтовый ящик. Для этого нужно открыть
(рис 7.2) Настройка времени сохранения удаленного почтового ящика в свойствах хранилищаТак как почтовые ящики являются атрибутами учетной записи пользователей, переподключение почтового ящика к новой учетной записи осуществляется легко. По этой причине, если требуется удалить учетную запись пользователя, почтовый ящик, связанный с этой учетной записью, сохраняется на значительный период времени. Следует указать такой период сохранения, по прошествии которого вы уже будете точно знать, что данный почтовый ящик больше не понадобится.
При удалении почтового ящика он помечается красным крестом в интерфейсе System Manager. Можно подключить почтовый ящик к новой учетной записи пользователя, щелкнув правой кнопкой мыши на почтовом ящике и выбрав команду
Если требуется восстановить одну базу данных, демонтируйте ее с помощью Exchange System Manager и затем восстановите отдельную базу
данных. Обратите внимание, что не требуется останавливать процесс store.exe - он продолжает функционировать. Вместо этого происходит лишь демонтаж базы данных, поверх которой будет происходить восстановление, после чего производится непосредственное восстановление копии с резервного носителя. В процессе восстановления создается специальная группа хранения восстановления, и база данных с журналами транзакций из резервной копии восстанавливается в эту группу хранения. Восстановленная база данных монтируется в исходной группе хранения системой ESE.
Имеется возможность восстановления баз данных на другой сервер Exchange Server 2003, отличный от сервера, с которого производилось резервное копирование. Этот метод следует использовать на крайний случай, когда требуется восстановить отдельные элементы или базы данных, и ни один другой метод не работает. Вторичный сервер должен отвечать аппаратным требованиям, предъявляемым к оборудованию для нормальной работы Exchange: он не должен быть подключен к сети и должен содержать достаточно свободного места на диске для восстановления всей резервной копии.
Чтобы восстановить базу данных на другой сервер, должны совпадать отображаемые имена базы данных и группы. Кроме того, имя организации и административной группы сервера, на который будет проводиться восстановление, должны соответствовать серверу, с которого была создана резервная копия базы данных. Потребуется настроить текущие базы данных так, чтобы разрешить их перезапись; это необходимо для того, чтобы новые базы данных с новыми подписями могли записываться поверх старых в процессе восстановления.
При этом методе восстанавливаются только базы данных ESE, поэтому такой подход не следует использовать для восстановления всего сервера. После копирования или перемещения всех баз данных на другой сервер необходимо настроить разрешения для почтовых ящиков, прежде чем пользователи смогут с ними работать.
Если имеется большое число почтовых ящиков, которые необходимо подключить к соответствующим учетным записям Active Directory, используйте программу MBCONN (файл mbconn.exe, утилита
Server). Эта утилита особенно полезна тогда, когда только что был удален или добавлен новый сервер Exchange в организацию Exchange. Если вы знакомы с утилитой Exchange 5.5 DS/IS
Большая часть сторонних приложений, осуществляющих резервное копирование, резервирует отдельные почтовые ящики с обеспечением выборочного резервирования на уровне элементов (например, резервируется отдельная календарная запись или отдельное сообщение). Если не используется резервное копирование на уровне почтового ящика или если используется утилита Windows Backup, период сохранения удаленного почтового ящика истек и требуется восстановить отдельный почтовый ящик, необходимо использовать автономный сервер и восстановить на нем почтовый ящик. В большинстве случаев этого не потребуется из-за наличия возможностей сохранения почтового ящика, таких как Dumpster и ExMerge. Но все же давайте рассмотрим действия, которые нужно выполнить, если вам понадобится данный подход.
Во-первых, убедитесь, что автономный сервер находится в другом лесу Windows Server 2003, нежели рабочие серверы. Во-вторых, группа хранения, содержащая восстанавливаемую базу данных, должна иметь такое же отображаемое имя, как и исходный рабочий сервер. В-третьих, база данных, которую требуется восстановить, должна иметь такое же отображаемое имя, как и исходный рабочий сервер. Имя базы данных должно быть уникальным на сервере резервного копирования для всех групп хранения. Например, если именем базы данных является Priv.
Чтобы восстановить почтовый ящик, повторно подключите почтовый ящик к пользовательской учетной записи
В данном разделе описываются требования к восстановлению и действия, предпринимаемые в следующих сценариях:
Существует пять общих требований к восстановлению всех серверов Exchange Server 2003:
Чтобы произвести полное восстановление рядового сервера Windows Server 2003, выполните следующие шаги.
Для успешного выполнения операции резервного копирования или восстановления необходимо действовать согласно ряду рекомендаций, проверенных на деле.
Одной из новых интересных возможностей в Windows 2003 является служба Volume Shadow Copy (VSC). Эта служба позволяет значительно сократить время, требуемое для резервирования и восстановления баз данных Exchange Server 2003. Служба VSC работает с приложениями резервного копирования и оборудованием для теневого резервного копирования баз данных Exchange Server 2003.
По сути, VSC запрашивает очень короткую паузу в работе Exchange Server 2003 для сброса структур памяти в базы данных, а также запрашивает паузы в новых транзакциях и завершение текущих транзакций. После этого происходит быстрое аппаратное копирование баз данных в нейтральное расположение на сервере.
После выполнения действия по копированию рабочие базы данных разблокируются для дальнейшего использования, в то время как версия теневой копии используется для создания резервной копии на ленте. По умолчанию после завершения резервирования теневых баз данных теневая копия удаляется.
В последующих версиях этой функции, возможно, появится возможность планирования дополнительных периодических теневых копий в течение дня, которые можно будет оставить на диске и использовать во время операций восстановления. Эта возможность снижает объем данных, теряемый при откате к более ранним экземплярам базы данных, и значительно увеличивает скорость восстановления баз данных.
В данной лекции обсуждались основные принципы и подходы к выполнению операций резервного копирования и восстановления. Мы выделили способы восстановления баз данных Exchange, рассказали об основных шагах, которые следует выполнять для восстановления всего сервера целиком, а также привели краткое описание того, как функция VSC в Windows Server 2003 используется для сведения к минимуму времени, затрачиваемого на восстановление. Если базы данных были повреждены, или что-то в процессе работы пошло не так, как надо, обязательно используйте шаги, приведенные в этой лекции, для восстановления баз данных и информации Exchange.
Для получения официальных документов о завершении программы дополнительного профессионального образования (удостоверения о повышении квалификации, дипломов о профессиональной переподготовке и MBA) необходимо предоставить:
Внимание! Вы можете не заказывать доставку бумажной версии официального документы, а скачать его в электронном виде и распечатать самостоятельно. Информация о выданном документе в течение 1 месяца загружается в Федеральную информационную систему «Федеральный реестр сведений о документах об образовании и (или) о квалификации, документах об обучении» - ФИС ФРДО.
Доступ на новый сайт осуществляется с использованием адреса электронной почты, который был указан вами при регистрации на "старом". Мы постарались перенести все ваши данные с прежнего ресурса, однако не исключена вероятность потери части информации.
При возникновении проблемы со входом, воспользуйтесь функцией сброса пароля
Если вы обнаружите несоответствия, пожалуйста, сообщите нам.