Дополнительные сведения

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

Примечание.
В данном событии тип_резервной_копии представляет собой тип выполняемого резервного копирования. Например, тип_резервной_копии может иметь следующие значения: полная, копирующая, добавочная или разностная.

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

После успешного резервного копирования сервер Exchange выполняет две операции, указанные ниже.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Целостность моментального снимка должна проверять запрашивающая сторона службы теневого копирования томов. Проверка целостности моментального снимка — это обязательное требование к решениям для резервного копирования, которые поддерживаются рабочей группой Exchange. Сервер Exchange 2007 поддерживает два метода проверки целостности моментального снимка:

• интерфейс API CHKSGFILES;
  
  
• программа командной строки Eseutil.
  
  

Дополнительные сведения о проверке целостности моментального снимка с помощью интерфейса API CHKSGFILES см. в статье Validating Backup Integrity By Using CHKSGFILES (на английском языке).

Дополнительные сведения о проверке целостности моментального снимка с помощью программы командной строки Eseutil см. в статье Validating Backup Integrity By Using Eseutil (на английском языке).

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

Этап 1. Подготовка базы данных

Этап 2. Моментальный снимок базы данных

Этап 3. Проверка теневой копии

Этап 4. Усечение журналов транзакций

Программу командной строки для администрирования службы теневого копирования томов (VSSADMIN) можно использовать для получения сведений о модулях записи и поставщиках, зарегистрированных в службе теневого копирования томов.

Чтобы получить сведения о модулях записи VSS, выполните действия, указанные ниже.

1. На сервере Exchange нажмите кнопку Пуск, выберите пункт Выполнить, введите команду cmd и нажмите кнопку ОК.
   
   
2. В командной строке введите vssadmin list writers и нажмите клавишу ВВОД.
   
   Просмотрите возвращенные результаты и найдите сведения о модуле записи Exchange. Модуль записи Exchange должен находиться в стабильном состоянии. Если это так, при выполнении команды выводятся указанные ниже данные.
   
   

   Имя модуля записи: "Microsoft Exchange Writer" ИД модуля записи: {76fe1ac4-15f7-4bcd987e-8e1acb462fb7} ИД экземпляра модуля записи: {977637c2-fcdd-463e-b1f8-a9a5d603a2e8} Состояние: [1] Стабильный Последняя ошибка: Нет ошибок

   Если параметр Состояние имеет значение, отличное от значения Стабильный, перезапустите службу банка данных Microsoft Exchange. Если модуль записи Exchange находится в состоянии сбоя, при выполнении команды выводятся данные, подобные указанным ниже.
   
   

   Имя модуля записи: "Microsoft Exchange Writer" ИД модуля записи: {76fe1ac4-15f7-4bcd987e-8e1acb462fb7} ИД экземпляра модуля записи: {977637c2-fcdd-463e-b1f8-a9a5d603a2e8} Состояние: [14] Ошибка Последняя ошибка: Ошибка, допускающая повторение попытки

3. Чтобы получить сведения о поставщиках, зарегистрированных в службе теневого копирования томов, введите в командной строке команду vssadmin list providers. Будут выведены результаты, указанные ниже.
   
   

   Имя поставщика: "Microsoft Software Shadow Copy provider 1.0" Тип поставщика: Система ИД поставщика: {b5946137-7b9f-4925-af80-51abd60b20d5} Версия: 1.0.0.7

   По умолчанию в списке указывается только поставщик теневого копирования программ Майкрософт (Microsoft Software Shadow Copy provider). Однако если на компьютере установлена программа резервного копирования стороннего производителя, в списке могут быть указаны и другие поставщики.
   
   

Примечание.
Чтобы получить дополнительные сведения о доступных командах, введите в командной строке vssadmin /?.

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

1. Запустите командную консоль Exchange.
   
   
2. Выполните следующую команду:
   
   

   	Копировать код
   get-eventloglevel | where-object {$_.identity -like "*Exchange Writer*"} | set-eventloglevel -level expert

3. Чтобы проверить уровень ведения журнала для модуля записи Exchange, выполните следующую команду:
   
   

   	Копировать код
   get-eventloglevel | where-object {$_.identity -like "*Exchange Writer*"}

4. Чтобы восстановить уровень ведения журнала диагностики по умолчанию, выполните следующую команду:
   
   

   	Копировать код
   get-eventloglevel | where-object {$_.identity -like "*Exchange Writer*"} | set-eventloglevel -level Lowest

Для трассировки модуля записи Exchange можно использовать помощник по устранению неполадок (средство Extra), входящий в состав сервера Exchange 2007. Для этого выполните действия, описанные ниже.

1. На сервере Exchange нажмите кнопку Пуск, выберите пункт Выполнить, введите команду extra и нажмите кнопку ОК.
   
   
2. Если программа запускается впервые, выберите пункт Присоединиться к программе улучшения качества программного обеспечения Майкрософт или Я не хочу присоединяться к программе сейчас.
   
   
3. В области задач щелкните Выберите задачу.
   
   
4. На экране выбора задачи по устранению неполадок выберите элемент Управление трассировкой.
   
   
5. Нажмите кнопку ОК, если на экран выведено следующее сообщение:
   
   

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

6. Запишите путь, указанный в поле Выберите местоположение файла трассировки.
   
   
7. Щелкните Задать теги трассировки вручную.
   
   
8. В списке Компоненты для трассировки выберите элемент Хранилище, но не устанавливайте флажок Хранилище.
   
   
9. В списке Теги трассировки установите флажок tagVSS.
   
   
10. Нажмите кнопку Начать трассировку.
    
    

Средство BETest можно использовать, чтобы определить, является ли источником проблемы запрашивающая сторона службы теневого копирования томов стороннего производителя.

Средство BETest представляет собой тестовую запрашивающую сторону, которую можно использовать для тестирования модуля записи VSS Exchange. Для обмена данными с модулем записи Exchange и его тестирования средство BETest использует интерфейс API службы теневого копирования томов Майкрософт. Средство BETest может выполнять многие из задач, которые выполняет стандартная запрашивающая сторона службы теневого копирования томов. Данное средство можно использовать для получения с помощью службы теневого копирования томов резервной копии группы хранения Exchange. Средство BETest способно создать моментальный снимок активной базы данных или реплики базы данных на сервере Exchange 2007.

Чтобы получить это средство, загрузите и установите пакет SDK версии 7.2 для службы теневого копирования томов. Этот пакет SDK можно загрузить на странице Volume Shadow Copy Service SDK 7.2 (на английском языке).

По умолчанию для установки версии i386 средства BETest используется следующее местоположение:

C:\Program Files (x86)\Microsoft\VSSSDK72\TestApps\betest\obj\i386

Примечание.
Также доступна версия AMD64 средства BETest. Перед запуском средства BETest перейдите в каталог, который содержит версию, соответствующую операционной системе.

Чтобы использовать средство BETest, выполните указанные ниже действия.

1. Откройте окно командной строки и перейдите в каталог, который содержит версию, соответствующую операционной системе. Например, перейдите в каталог C:\Program Files (x86)\Microsoft\VSSSDK72\TestApps\betest\obj\amd64.
   
   
2. Проверьте, какие модули записи службы теневого копирования томов являются доступными. Для этого введите команду betest.exe >AvailableWriters.txt.
   
   
3. Создайте файл Components.txt, который будет использоваться средством BETest. Для этого выполните действия, описанные ниже.
   
   
   1. Откройте файл AvailableWriters.txt в текстовом редакторе, например в Блокноте.
      
      
   2. Найдите раздел Microsoft Exchange Writer. В Блокноте нажмите клавишу F3, в поле Найти введите Microsoft Exchange Writer и нажмите кнопку Найти далее.
      
      
   3. Используйте сведения в разделе WriterName = Microsoft Exchange Writer для заполнения файла Components.txt. Этот файл имеет следующий формат:
      
      

      "<GUID_модуля_записи>": "<логический_путь_к_компоненту>" {"target" # "new target", ...}, ..."<логический_путь_к_компоненту>" : "<логический_путь_к_подкомпоненту>,...";

      В этом файле <логический_путь_к_компоненту> — это параметр LogicalPath, параметр LogicalPath вместе с идентификатором GUID компонента или, если значения LogicalPath не существует, только идентификатор GUID компонента. Идентификатор GUID компонента указывает конкретную группу хранения. Например, в качестве значения параметра <логический_путь_к_компоненту> может быть указан путь Microsoft Exchange Server\Microsoft Information Store\имя_сервера\000dd565-c4e8-4f58-a8b1-2e29eee4f5c0.
      
      Ниже приведен образец файла Components.txt.
      
      

      "{76fe1ac4-15f7-4bcd-987e-8e1acb462fb7}":"Microsoft Exchange Server\Microsoft Information Store\имя_сервера\999dd565-c4e8-4f58-a8b1-2e29eee4f5c0 ";

      В этом примере первый идентификатор GUID относится к модулю записи Exchange. Изменить данный идентификатор GUID нельзя. Второй идентификатор GUID принадлежит конкретной группе хранения. Можно задать группу хранения, для которой будет выполнена команда, указав идентификатор GUID соответствующей группы хранения. Чтобы получить идентификатор GUID конкретной группы хранения, выполните командлет Get-StorageGroup '<имя_группы_хранения>' | fl GUID.
      
      Сервер Exchange поддерживает только потоковое резервное копирование активных групп хранения. Поэтому для резервного копирования пассивной группы хранения необходимо использовать службу теневого копирования томов. При наличии кластера Exchange с непрерывной репликацией, а также при необходимости выполнить резервное копирование реплики с сервера, для которого включена локальная непрерывная репликация, файл Components.txt должен быть похож на один из примеров, приведенных ниже.
      
      Для пассивной копии кластера с непрерывной репликацией:
      
      

      "{76fe1ac4-15f7-4bcd-987e-8e1acb462fb7}":"Microsoft Exchange Server\Microsoft Information Store\Replica\<имя_кластерного_сервера_почтовых_ящиков>\<GUID_группы_хранения>";

      Для пассивной копии с сервера с локальной непрерывной репликацией:
      
      

      "{76fe1ac4-15f7-4bcd-987e-8e1acb462fb7}":"Microsoft Exchange Server\Microsoft Information Store\Replica\<имя_сервера>\<GUID_группы_хранения>";

4. Чтобы создать резервную копию группы хранения, после создания файла Components.txt выполните следующую команду:
   
   

   	Копировать код
   BETEST.exe /B /E /T 1 /S output.XML /C components.txt /D c:\betest > output.txt

   Примечание.
   При выполнении данной команды в каталоге C:\Betest будет создана резервная копия. Эту команду можно также выполнить без параметра /E.

5. Если при выполнении команды выводится сообщение об ошибке, это означает, что источником возникновения неполадок является модуль записи Exchange. Чтобы устранить неполадки, просмотрите содержимое файла Output.txt, который создается при выполнении команды в действии 4.