Backup Components Document Life Cycle

Requesters have primary responsibility for the life cycle of a Backup Components Document.

This control is exercised by an instance of the IVssBackupComponents interface object returned by CreateVssBackupComponents.

A requester must initialize a Backup Components Document prior to a backup or restore by calling IVssBackupComponents::InitializeForBackup or IVssBackupComponents::InitializeForRestore. The requester can initialize the document as empty, or it can load a previously stored copy of the document.

For backup operations, a Backup Components Document is typically initialized as empty. Its data will be filled in with cooperation from the system's writers in the course of processing the backup.

For restore operations, a Backup Components Document is typically initialized from a stored document generated during the initial backup. This allows the restore (in conjunction with examination of stored Writer Metadata Documents) to determine what data was initially backed up and how it should be restored.

Backing up transportable shadow copies is an exception to this rule. In this case, a shadow copy could have been moved from one system (where it was created along with the initial Backup Components Document) to another by means of reassigning a shared storage device's logical unit. To back up under these circumstances, a requester loads the stored backup state and proceeds from where the initial system left off. (For more information, see Importing Transportable Shadow Copied Volumes.)

In the course of processing a backup, the requester decides which components to actually copy on the basis of which components are marked as selectable for backup, the component's logical paths, and its own internal logic.

Some of the components will be explicitly included in the backup operation; information about the component will be added to the Backup Components Document. Others will be implicitly included in the backup; information about the added components will not be added to the Backup Components Document.

All of a writer's nonselectable for backup components without a selectable ancestor in their logical path, and those selectable for backup components the requester chooses, will be added explicitly.

Both nonselectable and selectable for backup components can be added implicitly if they have a selectable ancestor in their logical path, which is explicitly included in the backup. These components (subcomponents) are members of component sets defined by their selectable ancestor.

When handling restore operations, the requester uses selectability for restore instead of selectability for backup in conjunction with logical path information and its own internal logic to decide which files to restore.

If a component that had been implicitly added to the backup is now to be explicitly added to the restore, the requester will update the Backup Components Document with that component's information.

Information about the stored components is available both to requesters and writers through instances of the IVssComponent interface.

It is through IVssComponent interfaces that writers can query and (until the end of PostSnapshot and PostRestore events) modify information in the Backup Components Document.

When the CVssWriter::OnPrepareBackup, CVssWriter::OnPreRestore, CVssWriter::OnPostSnapshot, CVssWriter::OnBackupComplete, or CVssWriter::OnPostRestore event handler is called, a writer receives an instance of an IVssWriterComponents interface.

Note that upon generation of the BackupComplete event, the Backup Components Document is made read-only, and therefore CVssWriter::OnBackupComplete cannot use the IVssComponent interface to modify it.

From the IVSSWriterComponents interface, the writer can retrieve instances of the IVssComponent interface that will allow it to access all of its components explicitly added to the Backup Components Document and to alter their state. For more information, see Overview of Processing a Backup Under VSS and Overview of Processing a Restore Under VSS.

Backup Components Documents are removed from memory when the IVssBackupComponents interface is released, and must be stored using IVssBackupComponents::SaveAsXML, or all their information will be lost.

In addition, when an IVssBackupComponents document is properly released, a BackupShutdown event is generated andauto-release shadow copies are deleted.