Overview of Actual Backup Of Files
VSS enables a requester to access the shadow copy of volumes containing data for backup and to copy data to backup media. Writers generally proceed with normal operation during this process. For more information, see Overview of Processing a Backup Under VSS.
The following table shows the sequence of actions and events that are required for files to be backed up.
| Requester action | Event | Writer action |
|---|---|---|
| Access files on the shadow-copied volume (see IVssBackupComponents::GetSnapshotProperties, VSS_SNAPSHOT_PROP) | None | None |
| Generate the list of files to back up, and copy file data to backup media. | None | None |
| Indicate the success or failure of the backup with IVssBackupComponents::SetBackupSucceeded. | None | None |
| The requester indicates that the backup has completed by calling IVssBackupComponents::BackupComplete. | BackupComplete | Perform any post-backup cleanup (see CVssWriter::OnBackupComplete, IVssWriterComponents, IVssComponent). |
| The requester waits for all writers to acknowledge receipt of the IVssBackupComponents::BackupComplete event using IVssAsync. It should also verify writer status (see IVssBackupComponents::GatherWriterStatus, IVssBackupComponents::GetWriterStatus). The requester must call GatherWriterStatus at this time to cause the writer session to be set to a completed state. Note: This is only necessary on Windows Server 2008 with Service Pack 2 (SP2) and earlier. |
None | None |
| Save the Backup Components Document and each Writer Metadata Document to XML documents, which can be written to the backup media (see IVssBackupComponents::SaveAsXML and IVssExamineWriterMetadata::SaveAsXML). | None | None |
Writer Actions during Backup of Files
After the shadow copy has been completed, all I/O operations on the system that is being backed up should be able to resume without disrupting the integrity of the backup. This is one of the prime motivations for having the shadow copy functionality.
Therefore, as in the discovery phase (see Overview of the Backup Discovery Phase), there are few demands placed on the writers while files are actually being backed up.
After a backup has completed, and a requester has generated a BackupComplete event, VSS will call each writer's CVssWriter::OnBackupComplete method, a virtual method that by default simply returns TRUE. However, writers can override the default implementation and take such actions as removing remaining temporary files, or use the IVssWriterComponents interface it is called with to check the state of the backup of each of its included explicitly components (and any component set they might define) by retrieving the corresponding IVssComponent object. The writer can then determine, and act on, the success or failure of the backup by calling IVssComponent:GetBackupSucceeded. The value returned by IVssComponent:GetBackupSucceeded will be TRUE only if all explicitly included files in the component and all implicitly included of any of its subcomponents have been successfully backed up.
When the call to CVssWriter::OnBackupComplete has completed, the requester should call IVssBackupComponents::GatherWriterStatus and IVssBackupComponents::GetWriterStatus (for each writer) one last time. The writer session state memory is a limited resource and writers must eventually reuse session states. This step marks the writer’s backup session state as completed and notifies VSS that this backup session slot can be reused by a subsequent backup operation.
Requester Actions during Backup of Files
As noted in Overview of the Backup Discovery Phase, you should not generate the actual list of files to be backed up until the shadow copy has completed.
The device object corresponding to the shadow copy of a given volume is used to get access to files on the shadow copied volume once the shadow copy has completed. The device object is obtained from the VSS_SNAPSHOT_PROP object returned by IVssBackupComponents::GetSnapshotProperties. Each shadow copy of a shadow copy set will have its own device object.
The device object and the paths obtained from the Writer Metadata Document specifications of components are then used to select files for backup. See Requester Access to Shadow Copied Data for more information.
Which files will be included in the backup list depends on the nature of the particular backup, upon component selectability for backup, and the logical path structure of the writer (see Working with Selectability for Backup).
In addition to files specified in the components, a given writer may also have explicitly excluded files. File exclusion must always be respected, regardless of which components are selected.
Also as noted in Overview of the Backup Discovery Phase, a mounted folder or reparse point can appear in a shadow copy and can be backed up. However, a mounted folder or reparse point cannot be traversed on the shadow-copied volume (see Working with Mounted Folders and Reparse Points).
Care should also be taken during a backup operation, if the alternate path returned by IVssWMFiledesc::GetAlternateLocation is not blank. An alternate path differs from an alternate location mapping in that it is used only during backups, while an alternate location mapping is used only during restores.
In this case, the data is not to be backed up from its normal location (indicated by IVssWMFiledesc::GetPath), but from the location returned by IVssWMFiledesc::GetAlternateLocation. On restore, the file should be returned to its normal location. See Non-Default Backup and Restore Locations for more information.
VSS places no restrictions on the actual mechanism of backing up data to a storage medium or the choice of that medium. However, it is recommended that the files of each component of each writer instance be processed as a unit. See Generating A Backup Set for a discussion of best practices in generating the backup file list.
The success or failure of backing up any of the files managed by a given component and (if it defines a component set) its subcomponents for a given writer instance should be preserved in the Backup Components Document by calling IVssBackupComponents::SetBackupSucceeded. If any file managed by a component or component set fails to back up, the entire component is said to fail. Exact information about which file failed to back up should always be logged.
Developers may find it helpful to store a record on the backup media of which files are backed up, the components and component set they were a member of, their specification, and what their original paths were. It may also be useful to store information such as each writer's component definition. Doing this may make the retrieval operation simpler. However, such details are left to the requester developer.
Because writers can modify the Backup Components Document while handling the PostSnapshot event generated by the requester's call to IVssBackupComponents::DoSnapshotSet, the Backup Components Document should not be saved until after that asynchronous call has completed.
Although it may take place earlier, this is also a convenient time to save the Writer Metadata Document.
It is very important that both the Backup Components Document and the Writer Metadata Documents be preserved using IVssBackupComponents::SaveAsXML and IVssExamineWriterMetadata::SaveAsXML. If they are not, it will not be possible to make use of VSS during file restoration.
In addition to storing the original metadata, some backup applications may find it useful to save a copy of their own list of the files (in their own optimized format)—and their associated writer, component, restore procedure, and location information—to the backup media for later retrieval. Such a list can be used to avoid some of the parsing and comparing of Writer Metadata Documents and the Backup Component Documents during restore.
Volumes being backed up may have data that is not managed by VSS writers. This data can and should be backed up from the shadow copied volume, where it will be in a crash-consistent state. See Backups without Writer Participation for more information.