Edit

Share via

Importing Transportable Shadow Copied Volumes

  • Article

It is sometimes desirable to create a shadow copy on one system, but use the shadow copy on a second system.

Consider the case where data to be backed up is normally managed by a given system (systemOne) during normal operations, and that this data is physically stored on a storage array or an appliance.

To minimize any disruption to systemOne (because backup operations can be resource intensive), it is desirable to perform the backup using systemTwo, a backup server, which has access to the same storage array as systemOne.

To ensure a proper shadow copy—cooperating with the writers on systemOne and preserving the state appropriately for ongoing tasks—the shadow copy should be performed by systemOne.

Therefore, systemOne must create a transportable shadow copy, which systemTwo will then import.

Windows Server 2003, Standard Edition, Windows Server 2003, Web Edition and Windows XP: Transportable shadow copy sets are not supported. All editions of Windows Server 2003 with Service Pack 1 (SP1) support transportable shadow copy sets.

A typical example of importing a transportable shadow copy can proceed in the following way:

  1. Initially, the logical unit (LUN) that is provided by the storage array is mounted as a volume on systemOne (say, F:).

  2. A requester that is running on systemOne instantiates an instance of IVssBackupComponents and proceeds as if it were preparing for a backup. (See Overview of Backup Initialization, Overview of the Backup Discovery Phase, and Overview of Pre-Backup Tasks for more information.)

  3. The requester on systemOne modifies the shadow copy context that is typically used for local backup operation (VSS_CTX_APP_BACKUP) to indicate that a transportable shadow copy will be created (VSS_VOLSNAP_ATTR_TRANSPORTABLE). The transportable attribute can be added to other shadow copy contexts as well.

  4. With a shadow copy context of VSS_CTX_APP_BACKUP | VSS_VOLSNAP_ATTR_TRANSPORTABLE, the requester that is on systemOne creates a shadow copy by calling IVssBackupComponents::DoSnapshotSet.

  5. SystemOne uses IVssBackupComponents::SaveAsXML to save the current state of the Backup Components Document and IVssExamineWriterMetadata::SaveAsXML to save each writer's Writer Metadata Documents. The XML strings that contain these documents are then made available to a requester that is running on systemTwo.

    The requester transfers the Backup Components Document to systemTwo.

    Note that the requester on systemOne does not release its instance of IVssBackupComponents at this point if the purpose of the shadow copy is for backup. The interface should remain open until systemTwo successfully finishes its backup operations. Only then should the requester issue a BackupComplete event since some writers will truncate logs and do other work after a successful backup. If the goal of the shadow copy is data mining or other purposes, then the interface can be closed at this step.

  6. The requester on systemTwo then calls IVssBackupComponents::ImportSnapshots to get access to the shadow copy that was created by the requester on systemOne.

    Note

    The requester is responsible for serializing the import shadow copy operation. Also, if the call to IVssBackupComponents::ImportSnapshots fails, the VSS won't clean up LUNs on it's own. The requester has to initiate the cleanup of LUNs.

     

  7. The requester on systemTwo proceeds with the backup of the shadow copied material exactly as if it were backing up a shadow copy that it created by itself (see Overview of Actual Backup Of Files).

    The requester on systemTwo obtains the shadow copy's device object using IVssBackupComponents::GetSnapshotProperties on the imported shadow copy and appends that to the beginning of the original file paths that were obtained from the metadata to access files to be backed up.

  8. After using the shadow copy, the requester on systemTwo must delete the shadow copy. As with non-transportable shadow copies, if the shadow copy context indicates auto-release shadow copies (for example, VSS_CTX_BACKUP), then releasing the IVssBackupComponents on systemTwo will cause the VSS service to delete the shadow copy. Otherwise, if the context indicates a persistent shadow copy (for example, VSS_CTX_APP_ROLLBACK), then the requester on systemTwo must explicitly delete the shadow copy.

    Then the requester on systemTwo signals the requester on systemOne that it has finished with the backup of the transportable shadow copy.

  9. After the requester on systemOne has received notification that the requester on systemTwo has finished the backup of the transportable shadow copy, it notifies the writers on its system by generating a BackupComplete event with a call to IVssBackupComponents::BackupComplete. At this point, the requester on systemOne is free to release its instance of IVssBackupComponents.

Transportable shadow copies in a cluster: Transportable shadow copies must be imported from outside the cluster as long as the original volume is mounted within the cluster. For information about implementing a fast recovery in a cluster, see Fast Recovery Using Transportable Shadow Copied Volumes.