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

Стратегии резервного копирования

При наличии пяти типов резервного копирования, описанных в предыдущем разделе, большинство администраторов использует только три стратегии для резервного копирования сервера. Все эти стратегии начинаются с полного резервного копирования сервера Exchange, выполняемого на регулярной основе, например, каждое воскресенье. Затем в первой стратегии выполняется полное резервное копирование ежедневно, во второй - добавочное резервное копирование (типа incremental) во все остальные дни недели, и в третьей стратегии требуется разностное резервное копирование (типа differential) во все остальные дни недели.

• Полное ежедневное резервное копирование.Каждый день выполняется полное резервное копирование сервера Exchange. Если следовать другой стратегии резервного копирования, то вы рискуете оказаться в ситуации, когда придется возвращаться к резервной копии, созданной несколько дней или недель назад. Предположим, что у вас произошел сбой при использовании стратегии еженедельного полного резервного копирования типа normal плюс ежедневного резервного копирования типа incremental. Вам придется выполнить восстановление, используя все резервные копии за предыдущую неделю. Деньги, потраченные на системы резервного копирования большой емкости (такие как цифровые ленточные системы [DLT]), нужно использовать разумным образом.
• Резервное копирование типа normal плюс ежедневное типа incremental.По воскресеньям выполняется полное резервное копирование всех выбранных файлов на сервере Exchange. В понедельник выполняется добавочное резервное копирование (типа incremental) - копируются все файлы, которые изменились с момента создания полной резервной копии. Во вторник выполняется еще одно добавочное резервное копирование - копируются все файлы, которые изменились после добавочного резервного копирования, выполненного в понедельник. В конце недели у вас имеется полная резервная копия плюс шесть добавочных резервных копий. Для восстановления с этих резервных копий необходимо сначала использовать полную резервную копию и затем по порядку каждую добавочную резервную копию.
• Резервное копирование типа normal плюс ежедневное типа differential.По воскресеньям выполняется полное резервное копирование всех файлов. В понедельник выполняется разностное резервное копирование (типа differential) - копируются все файлы, которые изменились после создания полной резервной копии. Во вторник выполняется еще одно разностное резервное копирование - копируются все файлы, которые изменились после создания полной резервной копии, полученной в воскресенье. При каждом следующем разностном резервном копировании копируются все файлы, которые изменились с момента создания последней полной резервной копии. Для восстановления с этих резервных копий необходимо сначала использовать полную резервную копию и затем выполнить восстановление с последней разностной резервной копии.

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

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

Например, если сервер закончил полное резервное копирование прошлым вечером в 23:30, а сегодня в 16:30 произошел отказ диска, содержащего одно из хранилищ Exchange, вы сможете восстановить сегодняшнюю информацию из журналов транзакций. Но при таком методе восстановления предполагается, что журналы транзакций находятся на другом физическом диске. Если эти журналы и хранилище находятся на одном диске, то вы сможете восстановить только версию на 23:30 прошлого вечера, когда было выполнено резервное копирование. Продолжим данный сценарий в предположении, что журналы находятся на отдельном диске, и произошел сбой диска с данным хранилищем. Вам нужно выполнить полное восстановление с ленточной резервной копии, созданной прошлым вечером. При своем запуске процесс store.exe попытается воспроизвести в базе данных все транзакции, содержащиеся в журналах транзакций. По окончании воспроизведения произойдет запуск этой службы, и база данных будет восстановлена в состояние, предшествовавшее моменту аварии.

Если процесс store.exe начинает работу в обычных условиях (без восстановления), например, после нормального отключения и перезапуска

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

Процедура резервного копирования

Процедура резервного копирования начинается с запуска приложения резервного копирования. Это приложение вызывает службу Web Storage System с указанием требуемого типа резервного копирования, после чего начинается процесс резервирования. WSS информирует ESE о том, что она переходит в режим резервного копирования, после чего генерируется файл корректировки (.PAT) для каждой резервируемой базы данных (подразумевается процесс полного резервного копирования). В процессе онлайнового полного резервного копирования база данных открыта для работы, и транзакции по-прежнему могут заноситься в базы данных. Если транзакция вызывает операцию для уже скопированного .edb-файла через границу резервного копирования (место в файле .edb, которое обозначает, что скопировано, а что - нет), то данная страница перед границей записывается в файл .PAT. Для каждой резервируемой базы данных используется отдельный файл PAT, например Privl.pat, Publ.pat или Srs.pat. Эти файлы отображаются только во время процедур резервирования и восстановления. Во время процедуры разностного или добавочного резервного копирования файл корректировки не создается.

Когда ESE переходит в режим резервирования, открывается новый файл журнала. Например, если Edb.log открыт в данный момент, то он закрывается и переименовывается для соответствия последнему поколению, после чего открывается новый файл Edb.log. В этот момент ESE может усекать журналы после завершения резервного копирования.

Кроме того, когда начинается резервное копирование, запрашивается считывание системой ESE базы данных и упорядочивание страниц. После упорядочивания страницы группируются во фрагменты по 64 Кб (16 страниц), после чего загружаются в оперативную память. После этого ESE проверяет контрольную сумму для каждой отдельной страницы для подтверждения целостности данных. Если какая-либо из страниц содержит вычисленную контрольную сумму, не совпадающую с контрольной суммой, которая была занесена в страницу при записи страницы на диск, процесс резервного копирования базы данных останавливается, а в журналы событий записывается сообщение об ошибке. Это делается для того, чтобы предотвратить сохранение поврежденных данных. Большим преимуществом здесь является то, что после получения успешно созданной в оперативном режиме резервной копии баз данных Exchange при помощи агента Exchange от поставщика вашего программного обеспечения, можно быть уверенным в том, что база данных на резервном носителе не повреждена, так как ка ждая страница считывается в оперативную память с вычислением контрольной суммы и последующим копированием на резервный носитель.

После успешного завершения резервного копирования и считывания всех страниц утилита резервного копирования копирует журналы и файлы корректировки в резервный набор. Далее файлы журнала усекаются или удаляются в тот момент, когда создается новое поколение файлов в начале резервного копирования. Резервный набор файлов закрывается, ESE переходит в обычный режим, и резервное копирование завершается.

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

Еще раз представим процесс резервного копирования в виде последовательности шагов.

1. Резервное копирование начинается, фиксируется точка синхронизации и создается пустой файл корректировки.
2. Файл Edb.log переименовывается с присвоением последующего номера, независимо от того, заполнен он или нет, и создается новый файл Edb.log.
3. Начинается резервное копирование текущей группы хранения.
4. Создается файл PAT для каждой резервируемой базы данных в группе хранения, заголовок базы данных записывается в файл .PAT.
5. В процессе резервного копирования операции для уже скопированного .edb-файла через границу резервного копирования записываются в файл .PAT.
6. В процессе резервного копирования Windows Server 2003 Backup копирует 64 Кб данных единовременно. Дополнительные транзакции создаются и сохраняются в нормальном режиме. Контрольная сумма каждой страницы вычисляется и сравнивается с контрольной суммой, записанной для этой страницы в самой странице. Контрольные суммы сравниваются для подтверждения целостности данных на каждой странице.
7. Журналы, использованные в процессе резервного копирования (т.е. журналы от контрольной точки и далее) и файлы корректировки копируются на резервный носитель.
8. Старые журналы удаляются с диска.
9. Старые файлы корректировки удаляются с диска.
10. Процесс резервного копирования завершается.

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

Обзор процесса восстановления

Перед тем как начать процесс восстановления, необходимо демонтировать базу данных или группу хранения и сделать их недоступными для пользователей. Это можно осуществить с помощью Exchange System Manager (ESM).

Когда начинается операция восстановления, хранилище информирует ESE о том, что начинает работу процесс восстановления и ESE переходит в режим восстановления. Агент резервного копирования копирует базу данных с резервного носителя напрямую в конечный путь для базы данных. Помните, что база данных представляет собой пару файлов -.EDN и .STM. Соответствующие файлы журнала и корректировок копируются на сервер во временное, указанное вами расположение, чтобы они не сохранялись там, где находятся файлы в функционирующей среде. Если получилось так, что указан один и тот же рабочий и временный путь, может произойти запись поверх файлов журналов и произойти логическое повреждение текущей рабочей базы данных. Поэтому временный путь должен обязательно отличаться от рабочего пути.

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

Из всего сказанного следует, что каждая транзакция в каждом файле журнала интерпретируется следующим образом. Временной штамп каждой транзакции считывается вместе с номером страницы в базу данных, на которую ссылается транзакция. Затем временной штамп на странице в базе данных считывается и сравнивается с временным штампом транзакции в журнале транзакций. Если транзакция в журнале имеет более поздний временной штамп, то транзакция из журнала транзакций записывается в базу данных. В противном случае (временной штамп на странице в базе данных является более поздним, чем временной штамп в транзакции из журнала транзакций) 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 Storage System, пока не будет восстановлена собственно Web Storage System и вручную переконфигурированы учетные записи Windows Server 2003.

Различные сценарии восстановления

Иногда не требуется восстанавливать весь сервер или всю базу данных целиком. В этом разделе мы будем обсуждать различные варианты восстановления:

• восстановление оперативных резервных копий;
• восстановление автономных резервных копий;
• восстановление одного почтового ящика;
• восстановление одной базы данных;
• восстановление базы данных на другой сервер;
• восстановление файлов журналов.

Восстановление оперативных резервных копий

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