Создание резервных копий Exchange Server 2003 и служба теневого копирования тома

Переводы статьи Переводы статьи
Код статьи: 822896 - Vizualiza?i produsele pentru care se aplic? acest articol.
Развернуть все | Свернуть все

В этой статье

Аннотация

Служба теневого копирования томов (VSS) Microsoft Windows Server 2003 используется при разработке приложений для создания резервных копий и восстановления Microsoft Exchange Server 2003. Эта служба предоставляет инфраструктуру, которая необходима сторонним программам управления хранилищами, бизнес-приложениям и поставщикам оборудования для взаимодействия при создании теневых копий и управлении ими. Решения, разработанные на базе этой инфраструктуры, могут использовать теневые (или зеркальные) копии для резервного копирования и восстановления одной или нескольких баз данных Exchange Server 2003.

Служба теневого копирования томов координирует взаимодействие между запрашивающими сторонами (приложениями резервного копирования), модулями записи (приложениями в службах Windows, например Exchange Server 2003 и SQL Server 2000) и поставщиками (системными, программными или аппаратными компонентами, создающими теневые копии). Чтобы использовать службу теневого копирования томов для создания резервной копии данных Exchange Server 2003, программа резервного копирования должна содержать запрашивающую сторону службы теневого копирования томов, совместимую с Exchange Server 2003. Поскольку программа резервного копирования из состава Windows Server не имеет такой запрашивающей стороны, организациям следует использовать программы сторонних производителей.

Для совместимости с Exchange Server 2003 программы резервного копирования на базе службы VSS должна соответствовать трем основным требованиям, обеспечивающим целостность и восстанавливаемость теневых копий. Если эти требования не соблюдены, то служба технической поддержки Майкрософт считает программу резервного копирования несоответствующей концепции Exchange VSS и не сможет устранять неполадки с созданием и восстановлением резервных копий. Приобретая программу резервного копирования, убедитесь, что она соответствует требованиям совместимости с Exchange, перечисленным в данной статье (см. раздел «Дополнительная информация»).

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

Дополнительные сведения о поддержке службой технической поддержки решений на базе службы VSS см. в следующей статье базы знаний Майкрософт:
841696 Обзор политики корпорации Майкрософт в отношении поддержки программного обеспечения сторонних производителей, предназначенного для хранения данных (Эта ссылка может указывать на содержимое полностью или частично на английском языке)

Дополнительная информация

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

  1. Программа резервного копирования (или агент) запускает запланированное задание.
  2. Запрашивающая сторона службы теневого копирования томов в программе резервного копирования отправляет службе теневого копирования томов команду создать теневую копию выбранных групп хранения Exchange Server 2003.
  3. Служба теневого копирования томов взаимодействует с модулем записи Exchange Server 2003 для подготовки резервного копирования путем создания моментального снимка.
  4. Служба теневого копирования томов взаимодействует с соответствующим поставщиком хранилища для создания теневой копии одного или нескольких томов хранилища, которые содержат одну или несколько групп хранения Exchange Server 2003.
  5. Служба теневого копирования томов освобождает Exchange Server 2003, позволяя ему вернуться в обычный режим работы.
  6. Перед уведомлением сервера Exchange об успешном создании резервной копии запрашивающая сторона службы теневого копирования томов проверяет целостность резервного набора данных.
Например, при получении запроса на создание теневой копии от программы резервного копирования Exchange Server 2003, которая поддерживает службу теневого копирования томов (запрашивающую сторону), служба теневого копирования томов обращается к модулю записи Exchange Server 2003 Writer для подготовки моментальной копии, в это время Exchange Server 2003 запрещает выполнение административных действий с группой хранения, проверяет зависимости тома и приостанавливает все операции записи в файлы базы данных и журналов транзакций, разрешая только доступ с правом на чтение. После этого служба теневого копирования томов взаимодействует с соответствующим поставщиком хранилища, чтобы начать теневое копирование томов, содержащих данные Exchange Server 2003. Как правило, теневое копирование длится всего лишь пару секунд и проходит практически незаметно для конечного пользователя. После создания теневой копии служба теневого копирования томов обращается к модулю записи Exchange Server 2003, разрешая серверу Exchange вернуться в обычный режим работы. Перед уведомлением сервера Exchange об успешном создании резервной копии программа резервного копирования проверяет работоспособность теневой копии. После успешного создания резервной копии сервер Exchange усекает журналы и регистрирует время последнего резервного копирования одной или нескольких баз данных.

Дополнительные сведения о создании резервной копии Exchange Server 2003 с помощью службы теневого копирования томов см. в следующей статье базы знаний Майкрософт:
842066 Веб-трансляция TechNet, посвященная службе теневого копирования томов для Exchange Server 2003 (Эта ссылка может указывать на содержимое полностью или частично на английском языке)

Требования, которым должны соответствовать программы резервного копирования на базе службы теневого копирования томов, чтобы обеспечить целостность и восстанавливаемость баз данных Exchange Server 2003

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

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

    Тип события: Сведения
    Источник события: ESE
    Категория события: Теневое копирование
    Код события: 2005
    Дата: 6/17/2004
    Время: 11:40:41
    Пользователь: Н/Д
    Компьютер: EXCHSERVER
    Описание: Information Store (2180) Shadow copy instance 3 starting. This will be a «тип_резервного_копирования»* shadow copy.

    * Где «тип_резервного_копирования» — это тип выполняемого резервного копирования (полное, добавочное, разностное или копирующая архивация).

    Тип события: Сведения
    Источник события: MSExchangeIS
    Категория события: Exchange VSS Writer
    Код события: 9608
    Дата: 6/17/2004
    Время: 11:40:42
    Пользователь: Н/Д
    Компьютер: EXCHSERVER
    Описание: Exchange VSS Snapshot prepared for Snapshot successfully.

    Тип события: Сведения
    Источник события: MSExchangeIS
    Категория события: Exchange VSS Writer
    Код события: 9610
    Дата: 6/17/2004
    Время: 11:40:43
    Пользователь: Н/Д
    Компьютер: EXCHSERVER
    Описание: Exchange VSS Snapshot has frozen the storage groups successfully.

    Тип события: Сведения
    Источник события: MSExchangeIS
    Категория события: Exchange VSS Writer
    Код события: 9612
    Дата: 6/17/2004
    Время: 11:40:44
    Пользователь: Н/Д
    Компьютер: EXCHSERVER
    Описание: Exchange VSS Snapshot has thawed the storage groups successfully.

  2. Программа резервного копирования должна проверять целостность резервного набора данных теневых копий.

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

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

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

    Тип события: Сведения
    Источник события: MSExchangeIS
    Категория события: Exchange VSS Writer
    Код события: 9620
    Дата: 6/17/2004
    Время: 13:49:59
    Пользователь: Н/Д
    Компьютер: EXCHSERVER
    Описание: Exchange VSS Snapshot has processed pre-restore event successfully

    Тип события: Сведения
    Источник события: MSExchangeIS
    Категория события: Exchange VSS Writer
    Код события: 9618
    Дата: 6/17/2004
    Время: 13:59:46
    Пользователь: Н/Д
    Компьютер: EXCHSERVER
    Описание: Exchange VSS Snapshot has processed post-restore event successfully

** «Исходное место» — это компьютер Exchange с тем же именем сервера и путем, что и компьютер Exchange, на котором с помощью службы теневого копирования томов была создана резервная копия.

Восстановление для Exchange Server 2003 с пакетом обновления 1 (SP1) и более поздних версий в другом месте с помощью модуля записи Exchange Writer невозможно. Программы резервного копирования на базе службы теневого копирования томов могут поддерживать восстановление теневых копий баз данных Exchange в других местах средствами программирования или в ручном режиме.

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

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

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

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

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

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

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

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

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

Сохранение других журналов транзакций, кроме перечисленных в поле Log Required, необязательно (успешное восстановление и подключение резервной копии базы данных возможно и без них). Тем не менее если все эти журналы не были сохранены, то при восстановлении базы данных будут потеряны все изменения, внесенные после создания резервной копии. Корпорация Майкрософт настоятельно рекомендует хранить не только журналы транзакций, которые необходимы для восстановления и подключения резервной копии базы данных, но и все созданные впоследствии журналы транзакций, позволяющие выполнить накат базы данных и избежать потери данных.

Как определить нужные файлы в журналов транзакций

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

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

Если в поле Log Required содержится значение 0-0, значит базу данных можно подключить без преобразования дополнительных данных из журналов транзакций. Такая ситуация возможна только в том случае, если база данных переведена в состояние «чистого» отключения. Когда база данных запущена, в поле Log Required обязательно указан диапазон журналов транзакций, которые еще не были применены к базе данных. Этот диапазон непрерывно обновляется.

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

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

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

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

Удаление журналов транзакций

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

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

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

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

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

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

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

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

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

Проверка согласованности моментального снимка

Запрашивающая сторона службы теневого копирования томов должна проверять согласованность моментального снимка путем запуска средства Eseutil.exe для файлов базы данных и журналов (соответствующие параметры см. в представленной ниже таблице). Запрашивающая сторона службы теневого копирования томов проверяет, что все возвращенные значения ERRORLEVEL не являются отрицательными. Чтобы увидеть значения ERRORLEVEL в командной строке, введите после выполнения средства Eseutil.exe команду echo %errorlevel%. Отрицательное значение ERRORLEVEL означает, что файлы повреждены. До вызова функции BackupComplete запрашивающая сторона службы теневого копирования томов должна убедиться, что состояние компонента резервного копирования в Backup Component Document соответствует результатам проверки согласованности (т. е. состояние компонента резервного копирования равно FALSE, если найдено повреждение, и TRUE в противном случае). Проверка согласованности моментального снимка — это обязательное требование к решениям, которые поддерживаются группой Exchange.

Следующая таблица содержит сведения о проверке целостности для каждого типа резервного копирования.
Свернуть эту таблицуРазвернуть эту таблицу
Тип файла \ тип резервного копированияПолноеКопирующая архивацияДобавочноеРазностное
EDB"eseutil /k /i""eseutil /k /i"
LOG"eseutil /k" *"eseutil /k" *"eseutil /k" **"eseutil /k" **
STM
CHK

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

* Все файлы журналов с номером версии, равным номеру файла контрольных точек или превышающим его, необходимы для восстановления моментального снимка базы данных. Для восстановления базы данных также требуется текущий журнал Enn.log (если он существует). Если любой из файлов журналов не проходит проверку согласованности, то перед вызовом функции BackupComplete запрашивающая сторона должна присвоить компоненту резервного копирования состояние FALSE. Чтобы определить файл контрольных точек, запустите средство eseutil.exe для моментального снимка файла контрольных точек и найдите в результатах строку «Checkpoint:». Например, при выполнении команды «c:\eseutil.exe /mk E01.chk» будут выведены следующие данные:
Checkpoint:  (0x20,9D,187)
, где 0x20 — это номер версии журнала файла контрольных точек.

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

** Для восстановления базы данных требуются все журналы из состава добавочного или разностного резервного набора данных. Чтобы проверить согласованность всей последовательности журналов, запустите средство eseutil, указав в командной строке префикс файлов журналов. Например, команда «eseutil /k E01» проверит согласованность всех файлов, имена которых имеют формат E01xxxxx.log, в соответствующей папке.

Свойства

Код статьи: 822896 - Последний отзыв: 3 декабря 2007 г. - Revision: 8.4
Информация в данной статье относится к следующим продуктам.
  • Microsoft Exchange Server 2003 Enterprise Edition
  • Microsoft Exchange Server 2003 Standard Edition
  • Microsoft Exchange Server 2003 Standard Edition на следующих платформах
    • Microsoft Windows Server 2003, Enterprise x64 Edition
    • Microsoft Windows Server 2003, Datacenter Edition (32-bit x86)
    • Microsoft Windows Server 2003, Enterprise Edition (32-bit x86)
    • Microsoft Windows Server 2003, Standard Edition (32-bit x86)
    • Microsoft Windows Server 2003, Web Edition
  • Microsoft Windows Small Business Server 2003 Premium Edition
  • Microsoft Windows Small Business Server 2003 Standard Edition
Ключевые слова: 
kbtshoot KB822896

Отправить отзыв

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com