Обзор фактической резервной копии файлов
VSS позволяет запрашивающим пользователям получить доступ к теневой копии томов, содержащих данные для резервного копирования и копирования данных в носитель резервного копирования. Авторы обычно продолжают работать в обычном режиме во время этого процесса. Дополнительные сведения см. в разделе Обзор обработки резервного копирования вVSS.
В следующей таблице показана последовательность действий и событий, необходимых для резервного копирования файлов.
| Действие запрашивающего лица | Событие | Действие записи |
|---|---|---|
| Доступ к файлам на томе с теневым копированием (см. раздел IVssBackupComponents::GetSnapshotProperties, VSS_SNAPSHOT_PROP) | Никакой | Нет |
| Создайте список файлов для резервного копирования и копирования данных файлов в носитель резервного копирования. | Никакой | Никакой |
| Укажите успешность или сбой резервной копии с помощью IVssBackupComponents::SetBackupSucceeded. | Нет | Нет |
| Запрашивающая сторона указывает на то, что резервная копия завершена с помощью вызова IVssBackupComponents::BackupComplete. | Резервное копирование завершено | Выполните очистку после резервного копирования (см. раздел CVssWriter::OnBackupComplete, IVssWriterComponents, IVssComponent). |
| Запрашивающий ожидает, чтобы все авторы подтвердили получение события IVssBackupComponents::BackupComplete с помощью IVssAsync. Он также должен проверить состояние писателя (см. раздел IVssBackupComponents::GatherWriterStatus, IVssBackupComponents::GetWriterStatus). Запрашивающий объект должен вызвать GatherWriterStatus в данный момент, чтобы сеанс записи был переведен в завершенное состояние.
Примечание. Это необходимо только в Windows Server 2008 с пакетом обновления 2 (SP2) и более ранними версиями. |
Нет | Нет |
| Сохраните документ компонентов резервного копирования и каждый документ метаданных записи в формате XML, которые можно записать на устройство резервного копирования (см. IVssBackupComponents::SaveAsXML и IVssExamineWriterMetadata::SaveAsXML). | Никакой | Никакой |
Действия программ записи во время резервного копирования файлов
После завершения теневой копии все операции ввода-вывода в системе, резервное копирование которых выполняется, должны быть в состоянии возобновить работу без нарушения целостности резервной копии. Это одна из основных мотиваций для использования функций теневого копирования.
Таким образом, как и на этапе обнаружения (см. обзор этапа обнаружения резервных копий), к авторам предъявляются минимальные требования в то время, как файлы действительно резервируются.
После завершения резервного копирования и создания средством запроса события BackupComplete, VSS вызовет функцию CVssWriter::OnBackupComplete, виртуальную функцию, которая по умолчанию просто возвращает TRUE. Тем не менее, авторы могут переопределить реализацию по умолчанию и выполнить такие действия, как удаление оставшихся временных файлов, или использовать интерфейс IVssWriterComponents, который вызывается, чтобы проверить состояние резервной копии каждого из явно включенных компонентов (и любого набора компонентов , который они могут определить), извлекая соответствующий объект IVssComponent. Затем модуль записи может определить успешность или неудачу резервного копирования и предпринять соответствующие действия, вызвав IVssComponent:GetBackupSucceeded. Значение, возвращаемое IVssComponent:GetBackupSucceeded, будет TRUE только в том случае, если все файлы, явно включенные в компонент, и все неявно включены любого из его подкомпонентов успешно созданы.
После завершения вызова CVssWriter::OnBackupComplete запросчик должен вызвать IVssBackupComponents::GatherWriterStatus и IVssBackupComponents::GetWriterStatus (для каждого средства записи) в последний раз. Память состояния сеанса записи — это ограниченный ресурс, и авторы в конечном итоге должны повторно использовать состояния сеансов. На этом шаге писатель помечает состояние сеанса своего резервного копирования как завершенное и уведомляет VSS о том, что этот слот сеанса резервного копирования можно повторно использовать при последующей операции резервного копирования.
Действия запрашивающей стороны во время резервного копирования файлов
Как отмечалось в обзор этапа обнаружения резервных копий, не следует создавать фактический список файлов, которые будут резервированы до тех пор, пока не завершится теневая копия.
Объект устройства , соответствующий теневой копии заданного тома, используется для получения доступа к файлам на теневом скопированном томе после завершения теневой копии. Объект устройства получен из объекта VSS_SNAPSHOT_PROP, возвращаемого IVssBackupComponents::GetSnapshotProperties. Каждая теневая копия в наборе теневого копирования будет иметь свой собственный объект устройства.
Затем объект устройства и пути, полученные из спецификаций документа метаданных для записи, используются для выбора файлов для резервного копирования. Дополнительные сведения о доступе запрашивающего средства к теневым копированным данным см. в .
Какие файлы будут включены в список резервных копий, зависит от типа данной резервной копии, от возможности выбора компонента для резервного копирования, а также от логической структуры пути автора (см. Работа с возможностью выбора для резервного копирования).
Помимо файлов, указанных в компонентах, данное записывающее устройство может также явно исключить файлы. Исключение файлов всегда должно соблюдаться независимо от того, какие компоненты выбраны.
Кроме того, как отмечалось в обзор этапа обнаружения резервных копий, подключенная папка или точка повторного анализа может отображаться в теневой копии и может быть создана резервная копия. Однако подключенную папку или точку повторного анализа нельзя пройти по теневой копии тома (см. работа с подключенными папками и точками повторного анализа).
Будьте также внимательны во время операции резервного копирования, если альтернативный путь, возвращаемый IVssWMFiledesc::GetAlternateLocation не является пустым. Альтернативный путь отличается от альтернативного сопоставления местоположений тем, что он используется только во время резервного копирования, тогда как альтернативное сопоставление местоположений используется только во время восстановления.
В этом случае данные не должны резервироваться из нормального расположения (указано IVssWMFiledesc::GetPath), а из расположения, возвращаемого IVssWMFiledesc::GetAlternateLocation. При восстановлении файл должен быть возвращен в нормальное расположение. Дополнительные сведения см. в нестандартных расположениях резервного копирования и восстановления.
VSS не ограничивает фактический механизм резервного копирования данных в носитель хранилища или выбор этого носителя. Однако рекомендуется обрабатывать файлы каждого компонента каждого экземпляра записи единым блоком. Для обсуждения лучших практик по созданию списка файлов резервного копирования см. раздел о формировании набора резервных копий.
Успех или сбой резервного копирования любого из файлов, управляемых заданным компонентом, и (если он определяет набор компонентов) его вложенных для данного экземпляра записи следует сохранить в документе резервных компонентов путем вызова IVssBackupComponents::SetBackupSucceeded. Если любому файлу, управляемому компонентом или набором компонентов, не удаётся создать резервную копию, считается, что компонент завершился с ошибкой. Точные сведения о том, какой файл не удалось создать резервную копию, всегда следует записывать в журнал.
Разработчикам может быть полезно хранить записи на носителе резервных копий о файлах, которые были сохранены, компонентах и наборах компонентов, к которым они принадлежали, их спецификациях и их исходных путях. Также может быть полезно хранить такие сведения, как определение компонента каждого автора. Это может сделать операцию извлечения проще. Однако такие сведения остаются за разработчиком, который делает запрос.
Так как авторы могут изменять документ компонентов резервного копирования при обработке события PostSnapshot, созданного вызовом средства запросчика IVssBackupComponents::DoSnapshotSet, документ компонентов резервного копирования не должен быть сохранен до тех пор, пока не завершится асинхронный вызов.
Хотя это может произойти ранее, это также удобное время для сохранения документа метаданных Writer.
Очень важно сохранить как документ компонентов резервного копирования, так и документы метаданных записи с помощью IVssBackupComponents::SaveAsXML и IVssExamineWriterMetadata::SaveAsXML. Если они отсутствуют, во время восстановления файлов не удастся использовать VSS.
Помимо хранения исходных метаданных, некоторые приложения резервного копирования могут оказаться полезными для сохранения копии собственного списка файлов (в собственном оптимизированном формате) и связанного средства записи, компонента, процедуры восстановления и сведений о расположении на носителе резервного копирования для последующего извлечения. Такой список можно использовать, чтобы избежать разбора и сравнения документов метаданных Writer и документов компонентов резервного копирования во время восстановления.
Резервные копии томов могут содержать данные, которые не управляются средствами записи VSS. Эти данные можно и нужно резервировать из тома, созданного с использованием теневого копирования, где они будут находиться в состоянии, устойчивом к сбоям . Дополнительные сведения см. в резервных копий без участия автора.