Stfw.RuСоздание резервных копий Exchange Server 2003 и служба теневого копирования тома
Служба теневого копирования тома (Volume Shadow Copy Service, VSS) из состава Microsoft Windows Server 2003 используется при разработке приложений для создания резервных копий и восстановления Microsoft Exchange Server 2003
🕛 21.12.2005, 05:34
На этой странице Аннотация Дополнительная информация Ниже перечислены действия, которые выполняются в процессе создания резервной копии Exchange Server 2003 с помощью службы теневого копирования тома. Три основных требования, которым должны соответствовать программы резервного копирования на базе службы VSS, чтобы обеспечить целостность и восстанавливаемость баз данных Exchange Проверка целостности резервных копий, созданных с помощью службы VSS Как определить нужные журналы транзакций Удаление журналов транзакций Восстановление непроверенных резервных копий Как проверить согласованность моментального снимка Информация в данной статье применима к: Аннотация
Служба теневого копирования тома (Volume Shadow Copy Service, 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 (http://support.microsoft.com/kb/841696/) Обзор политики корпорации Майкрософт в отношении поддержки программного обеспечения сторонних разработчиков, предназначенного для хранения данных Вверху страницы
Дополнительная информация
Ниже перечислены действия, которые выполняются в процессе создания резервной копии Exchange Server 2003 с помощью службы теневого копирования тома.
1. Программа резервного копирования (или агент) запускает запланированное задание.
2. Запросчик службы VSS в программе резервного копирования отправляет службе VSS команду сделать теневую копию выбранных групп хранилищ Exchange Server 2003.
3. Служба теневого копирования тома взаимодействует со средством записи Exchange Server 2003 для подготовки моментальной резервной копии.
4. Служба теневого копирования тома взаимодействует с соответствующим поставщиком хранилища для создания теневой копии одного или нескольких томов хранилища, который содержит одну или несколько групп хранилищ Exchange Server 2003.
5. Служба теневого копирования тома разблокирует Exchange Server 2003, позволяя ему вернуться в обычный режим работы.
6. Перед уведомлением сервера Exchange об успешном создании резервной копии запросчик службы VSS проверяет целостность резервной копии.
Например, когда запрос на создание теневой копии принимается программой резервного копирования Exchange Server 2003, которая поддерживает службу VSS (имеет запросчик), служба VSS обращается к средству записи Exchange Server 2003 Writer для подготовки моментальной копии, в это время Exchange Server 2003 запрещает выполнение административных действий по отношению к группе хранилищ, проверяет зависимости тома и приостанавливает все операции записи в файлы базы данных и журналы транзакций (доступ с правом только чтения продолжает предоставляться). После этого служба теневого копирования тома взаимодействует с соответствующим поставщиком хранилища, чтобы начать процесс теневого копирования для томов, содержащих данные Exchange Server 2003. Как правило, теневое копирование длится всего лишь пару секунд и проходит практически незаметно для конечного пользователя. После создания теневой копии служба VSS обращается к средству записи Exchange Server 2003 Writer, разрешая серверу Exchange вернуться в обычный режим работы. Перед уведомлением сервера Exchange об успешном создании резервной копии программа резервного копирования проверяет состояние теневой копии. После успешного создания резервной копии сервер Exchange усекает журналы и регистрирует время последнего создания резервной копии одной или нескольких баз данных.
Дополнительные сведения о создании резервной копии Exchange Server 2003 с помощью службы теневого копирования тома см. в следующих статьях базы знаний Майкрософт.
842066 (http://support.microsoft.com/kb/842066/) Веб-конференция TechNet, посвященная службе теневого копирования тома для Exchange Server 2003
820852 (http://support.microsoft.com/kb/820852/) Создание резервной копии банка сообщений Exchange Server 2003 и данных состояния системы Windows Server 2003 завершается неудачно, и регистрируется событие с кодом 8019 Вверху страницы
Три основных требования, которым должны соответствовать программы резервного копирования на базе службы VSS, чтобы обеспечить целостность и восстанавливаемость баз данных Exchange
Ниже представлены фрагменты журнала событий приложений, по которым можно определить, соблюдены ли требования совместимости с ПО Exchange. В процессе создания и восстановления резервных копий программы резервного копирования и сервер Exchange могут регистрировать и другие события. Регистрация приведенных ниже событий в процессе создания и восстановления резервных копий свидетельствует о том, что требования совместимости с ПО Exchange выполнены. На настоящий момент нет программы сертификации программного обеспечения сторонних разработчиков для сервера Exchange. Выполнение требований совместимости обеспечивает целостность и восстанавливаемость теневых копий, однако не является залогом эффективности и надежности ПО стороннего разработчика.
1. Резервные копии базы данных Exchange, журналов транзакций и файлов контрольной точки должны создаваться исключительно с помощью средства записи Exchange Writer.
Когда в процессе создания теневой копии инициируется средство записи Exchange Writer, в журнале «Приложение» регистрируются следующие события.
Тип: Information
Источник: ESE
Категория: ShadowCopy
Код (ID): 2005
Дата: 17.06.2004
Время: 11:40:41
Пользователь: N/A
Компьютер: EXCHSERVER
Описание: Information Store (2180) Shadow copy instance 3 starting. This will be a «тип_копии»* shadow copy.
* Где «тип_копии» - это тип создаваемой резервной копии (полная, копирующая, добавочная или разностная).
Тип: Information
Источник: MSExchangeIS
Категория: Exchange VSS Writer
Код (ID): 9608
Дата: 17.06.2004
Время: 11:40:42
Пользователь: N/A
Компьютер: EXCHSERVER
Описание: Exchange VSS Snapshot prepared for Snapshot successfully.
Тип: Information
Источник: MSExchangeIS
Категория: Exchange VSS Writer
Код (ID): 9610
Дата: 17.06.2004
Время: 11:40:43
Пользователь: N/A
Компьютер: EXCHSERVER
Описание: Exchange VSS Snapshot has frozen the storage groups successfully.
Тип: Information
Источник: MSExchangeIS
Категория: Exchange VSS Writer
Код (ID): 9612
Дата: 17.06.2004
Время: 11:40:44
Пользователь: N/A
Компьютер: EXCHSERVER
Описание: Exchange VSS Snapshot has thawed the storage groups successfully.
2. Программа резервного копирования должна проверять целостность набора теневых копий.
Корпорация Майкрософт рекомендует (но не требует) производить это перед тем, как программа резервного копирования уведомляет Exchange о завершении создания резервной копии, поскольку после успешного создания резервной копии Exchange выполняет два важных действия:
- обновляет заголовки продублированных баз данных с учетом времени последнего успешного создания резервной копии;
- удаляет (усекает) журналы транзакций на сервере, которые больше не нужны для восстановления с повтором всех завершенных транзакций по последней успешной резервной копии.
Если программа резервного копирования не проверяет целостности данных до выполнения этих действий, то следует принять специальные меры для сохранения последней проверенной резервной копии, а также всех журналов, которые необходимы этой копии. Даже если сервер Exchange получил уведомление об успешном создании резервной копии, она не может считаться надежной до тех пор, пока программа резервного копирования не закончит проверку целостности данных.
Подробные сведения о проверке целостности и определении файлов баз данных и журналов транзакций, которые необходимо сохранить до завершения проверки целостности, см. в разделе «Проверка целостности резервных копий, созданных с помощью службы VSS» этой статьи.
3. Восстановление в исходном месте** должно производиться исключительно с помощью средства записи Exchange Writer.
В процессе восстановления теневой копии средством записи Exchange Writer в журнале «Приложение» регистрируются следующие события.
Тип: Information
Источник: MSExchangeIS
Категория: Exchange VSS Writer
Код (ID): 9620
Дата: 17.06.2004
Время: 13:49:59
Пользователь: N/A
Компьютер: EXCHSERVER
Описание: Exchange VSS Snapshot has processed pre-restore event successfully
Тип: Information
Источник: MSExchangeIS
Категория: Exchange VSS Writer
Код (ID): 9618
Дата: 17.06.2004
Время: 13:59:46
Пользователь: N/A
Компьютер: EXCHSERVER
Описание: Exchange VSS Snapshot has processed post-restore event successfully
** «Исходное место» - это компьютер Exchange с тем же именем сервера и файловым путем, что и компьютер Exchange, на котором с помощью службы VSS была создана резервная копия
Восстановление для Exchange Server 2003 с пакетом обновления 1 (SP1) в другом месте с помощью средства записи Exchange Writer невозможно. Программы резервного копирования на базе службы VSS могут поддерживать восстановление теневых копий баз данных Exchange в других местах средствами программирования или в ручном режиме. Вверху страницы
Проверка целостности резервных копий, созданных с помощью службы VSS
При создании резервной копии базы данных с помощью интерфейса API для потокового архивирования Exchange поочередно считывается каждая страница базы данных и проверяется контрольная сумма для каждой страницы. Кроме того, перед созданием резервных копий журналов транзакций проверяется их контрольная сумма.
В процессе создания резервной копии с помощью службы VSS сервер Exchange не имеет возможности прочитать каждый файл базы данных полностью и проверить его контрольную сумму. Таким образом, целостность файла базы данных и журнала транзакций должна проверяться программой резервного копирования. Для этого в соответствии с инструкциями, приведенными в конце данной статьи, запускается средство Eseutil.
Если контрольная сумма резервной копии, созданной с помощью службы VSS, не проверяется, то поврежденная страница базы данных может остаться незамеченной и, как следствие, попасть во все существующие резервные копии. Единственный метод решения такой проблемы заключается в исправлении базы данных, что вызывает длительное простаивание сервера и неизбежную потерю определенной части данных (как минимум, данных на поврежденных страницах).
Если же целостность последней резервной копии, созданной с помощью службы VSS, была проверена, то поврежденные страницы базы данных можно удалить путем восстановления проверенной резервной копии с повтором всех транзакций, завершенных после создания этой копии. Время простоя сервера при этом, как правило, значительно меньше, чем при исправлении базы данных, а исправление базы данных происходит абсолютно без потери данных.
Следовательно, созданная с помощью службы VSS резервная копия не может считаться надежной, пока не проверена контрольная сумма каждого из содержащихся в ней файлов
При проверке целостности резервной копии требуется соблюдение двух приведенных ниже правил.
- Файлы базы данных: всегда храните копию файлов базы данных, целостность которых проверена. Целостность резервной копии считается проверенной после завершения проверки контрольных сумм для страниц файлов базы данных в составе резервной копии.
Только что созданная резервная копия базы данных не является надежной, пока не произведена проверка контрольных сумм. Не удаляйте предыдущую проверенную резервную копию до проверки целостности текущей резервной копии.
- Журналы транзакций: создайте резервные копии и проверьте контрольные суммы для всех журналов транзакций, которые необходимы для восстановления последней резервной копии базы данных с проверенной целостностью.
Это относится как минимум ко всем журналам, которые указаны в поле Log Required заголовка каждой базы данных в последней проверенной резервной копии. Если эти журналы не доступны, подключить базу данных после восстановления не удастся.
Внимание! Это требование относится к последней резервной копии с проверенной целостностью, а не к резервной копии, которая создана последней. Пока последняя резервная копия не прошла проверку контрольных сумм, она не может считаться надежной.
Кроме того, можно сохранить дополнительные журналы, необходимые для восстановления резервной копии базы данных с повтором всех завершенных транзакций, т. е. все журналы транзакций в непрерывной последовательности, начиная от самого нижнего файла в поле Log Required, и до последнего журнала транзакций, который был удален с сервера Exchange. Подробные примеры и пояснения см. в следующем разделе
Сохранение других журналов транзакций, кроме перечисленных в поле Log Required, необязательно (другими словами, успешное восстановление и подключение резервной копии базы данных возможно и без них). С другой стороны, если все эти журналы сохранены не были, то при восстановлении базы данных будут потеряны все изменения, внесенные после создания резервной копии. Корпорация Майкрософт настоятельно рекомендует хранить не только журналы транзакций, которые необходимы для восстановления и подключения резервной копии базы данных, но и все созданные впоследствии журналы транзакций, позволяющие воссоздать базу данных с повтором всех завершенных транзакций.
Как определить нужные журналы транзакций
Если резервная копия создается, когда база данных Exchange находится в оперативном режиме, то одновременно будет создана резервная копия по меньшей мере одного журнала транзакций (независимо от того, используется интерфейс API для потокового архивирования или интерфейс API для архивирования с помощью службы VSS).
При восстановлении такой резервной копии базу данных можно подключить только после применения к ней (воспроизведения) данных из журналов транзакций. В поле Log Required заголовка каждой базы данных указаны порядковые номера журналов транзакций, которые необходимо внести в базу данных.
Если в поле Log Required содержится значение 0-0, значит, базу данных можно подключить без воспроизведения дополнительных данных из журналов транзакций. Такая ситуация возможна только в том случае, если база данных выключена. Когда база данных запущена, в поле Log Required обязательно указан диапазон журналов транзакций, которые еще не были внесены в базу данных. Этот диапазон непрерывно обновляется.
В поле Log Required базы данных, резервная копия которой создается в оперативном режиме, всегда указан ненулевой диапазон, и одновременно должны создаваться резервные копии этих журналов транзакций. Если после восстановления эти журналы не доступны, подключить базу данных не удастся. (Если необходимых журналов транзакций нет, базу данных можно исправить, однако успешность этой операции не гарантируется и, кроме того, исправление практически всегда приводит к потере определенных данных [по меньшей мере данных в отсутствующих журналах].)
Если используется интерфейс API для потокового архивирования или интерфейс API для архивирования с помощью службы VSS из состава средства записи Exchange VSS Writer, то резервные копии журналов, необходимых для подключения базы данных, создаются автоматически одновременно с архивированием базы данных. В случае воспроизведения только тех журналов, которые указаны в поле Log Required, база данных будет восстановлена по состоянию на момент завершения создания резервной копии. Чтобы восстановить базу данных с повтором всех завершенных после этого момента времени транзакций, необходимо, кроме того, воспроизвести журналы, записанные после создания резервной копии.
Чтобы полностью восстановить базу данных по определенной резервной копии с повтором всех завершенных транзакций, необходимо сохранить все журналы транзакций в непрерывной последовательности, начиная от самого нижнего файла в поле Log Required, и до последнего журнала транзакций в группе хранилищ базы данных. Если какой-либо журнал в этой последовательности отсутствует или поврежден, то восстановить базу данных можно будет только по состоянию на момент создания последнего исправного журнала перед поврежденным или отсутствующим файлом.
Таким образом, для восстановления базы данных без потери данных необходимо хранить исправные копии всех журналов транзакций, начиная от момента создания последней проверенной резервной копии базы данных.
Удаление журналов транзакций
Если не удалять журналы транзакций с сервера Exchange, то наступит момент, когда они займут все свободное пространство на диске. По этой причине как интерфейс API для потокового архивирования, так и интерфейс API для архивирования с помощью службы VSS поддерживают удаление журналов транзакций после создания стандартной или добавочной резервной копии. Журналы, более старые, чем те, которые необходимы для восстановления последней резервной копии, автоматически удаляются с сервера после того, как программа резервного копирования сообщает серверу Exchange об успешном создании резервной копии.
Если используется интерфейс API для потокового архивирования, то контрольные суммы для базы данных проверяются в процессе создания резервной копии. На момент времени, когда создание резервной копии завершается, физическая целостность базы данных и необходимых журналов уже проверена. Интерфейс API для архивирования с помощью службы VSS не позволяет проверять контрольные суммы одновременно с созданием резервной копии. Проверка физической целостности базы данных должна производиться независимо от создания резервной копии. Это можно сделать с помощью средства Eseutil до или после уведомления сервера Exchange о том, что резервная копия создана.
Если проверка контрольных сумм выполняется до завершения процесса создания резервной копии и в ней обнаруживается проблема, то сервер Exchange получает уведомление о неудачном создании резервной копии и не удаляет журналы с сервера.
Если же проверка контрольных сумм производится после отправки уведомления о завершении процесса создания резервной копии, то Exchange удаляет старые журналы с сервера. Некоторые из этих журналов могут быть необходимы для восстановления предыдущей резервной копии с повтором всех завершенных транзакций. Если эти журналы не были скопированы ранее, то выполнить такое восстановление полностью не удастся.
По этой причине корпорация Майкрософт рекомендует (но не требует) производить проверку контрольных сумм для резервной копии, созданной с помощью службы VSS, перед тем, как программа резервного копирования уведомляет Exchange о завершении создания резервной копии. Если проверка контрольных сумм производится после завершения процесса создания резервной копии, то программа резервного копирования должна обеспечивать создание копий всех журналов транзакций, которые удаляются с сервера, иначе полное восстановление с повтором всех завершенных транзакций будет невозможно.
В большинстве случаев все журналы транзакций, которые необходимы для восстановления с повтором всех завершенных транзакций резервной копии, созданной с помощью службы VSS, содержатся в наборах журналов, сохраненных с предыдущей и текущей резервной копиями. Этот вопрос необходимо прояснить перед приобретением продукта определенного разработчика.
Восстановление непроверенных резервных копий
Возможна ситуация, когда до завершения проверки контрольных сумм для последней резервной копии происходит сбой, требующий восстановления системы. В таких случаях корпорация Майкрософт рекомендует восстановить предыдущую проверенную резервную копию с повтором всех завершенных транзакций, не полагаясь на непроверенную резервную копию.
Но, возможно, вашим соглашением об уровне обслуживания предусмотрено более быстрое восстановление данных, чем то, которое доступно с помощью предыдущей резервной копии. В этом случае попробуйте восстановить непроверенную резервную копию, однако не удаляйте предыдущую (проверенную) резервную копию и все журналы транзакций, необходимые для ее полного восстановления с повтором всех завершенных транзакций. При условии соблюдения этих требований вы сможете восстановить проверенную резервную копию с повтором всех завершенных транзакций, если окажется, что последняя резервная копия содержит ошибки.
Как проверить согласованность моментального снимка
Запросчик службы VSS должен проверять согласованность моментального снимка путем запуска средства Eseutil.exe для файлов базы данных и журналов (доступные параметры см. в представленной ниже таблице). Запросчик службы VSS проверяет, что все возвращенные значения ERRORLEVEL не являются отрицательными. Чтобы увидеть значения ERRORLEVEL в командной строке, введите после завершения программы Eseutil.exe команду echo %errorlevel%. Отрицательное значение ERRORLEVEL означает, что в файлах имеется повреждение. До вызова функции BackupComplete запросчик службы VSS должен убедиться, что статус компонента резервной копии в документе 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, в соответствующей папке.