First published on TECHNET on Jan 29, 2008
Array Requirements: Beginning with Windows Server 2003 SP1, arrays were required to support globally unique page 83 identifiers for LUNs exposed in clusters. With Server 2008, that requirement extends to all hardware shadow copies including non-clustered cases. This means that both the original LUN and the shadow copy LUN must have at least one globally unique identifier of type 1, 2, 3 or 8 and Association 0.
Now let’s consider some of the new scenarios enabled in Windows Server 2008.
Multiple Imports : Hardware transportable shadow copies created on Windows Server 2008 may be imported to more than one host though not concurrently. For example it’s possible to create a hardware shadow copy of a SQL database on host A, mask it and import it to host B where it may be used to stream a backup to tape. The same shadow copy may then be masked and if required imported once again to either A or B or to an entirely new host for the purpose of data mining or a quick recovery.
This scenario requires support from both hardware providers and requesters. Specifically the hardware provider must support the OnLunStateChange method of the IVssHardwareSnapshotProviderEx interface which is new with Windows Server 2008. Requesters must call the BreakSnapshotSetEx method of the IVssBackupComponentsEx2 interface to use this functionality
Auto recovery of hardware transportable shadow copies: With Windows Server 2008 it is now possible to create a transportable hardware shadow copy that has been auto-recovered. Auto recovery is the processing performed on a shadow copy immediately after it is created.
A common example is the need to roll back database transactions that were incomplete when the shadow copy was created. Auto-recovery may also be used to roll back incomplete transactions within NTFS . It must be noted that file system transactions may also be rolled back when the shadow copy is first imported i.e. in the absence of auto-recovery NTFS transactions are rolled back when the shadow copy is first imported to a system.
Support for auto recovery of hardware transportable shadow copies requires that hardware providers support the OnLunStateChange method. Requesters can control both the auto recovery behavior during snapshot creation and also recovery later during import using the context flags VSS_VOLSNAP_ATTR_TXF_RECOVERY and VSS_VOLSNAP_ATTR_NO_AUTORECOVERY
Convert a hardware shadow copy into a read-write volume: In Windows Server 2008 it is possible to convert a hardware shadow copy into a read-write volume. This requires requesters to use the BreakSnapshotSetEx method with the VSS_BREAKEX_FLAG_MAKE_READ_WRITE flag specified. There are no changes required from hardware providers to support this feature. Note that once a shadow copy has been converted into a read-write volume, it cannot be managed using VSS APIs.
You can find sample code for all these scenarios in the sample provider (vsssampleprovider) and requester (vshadow) in the VSS SDK which is now included in the Windows SDK. The most recent pre-release version is available here .
This is the second in a series of posts on what’s new in VSS in Windows Server 2008. In this article I’ll cover some of the new scenarios with hardware shadow copies and also requirements from storage arrays. This is a primarily an overview and you can find more details in the documentation on MSDN and the SDK.
Array Requirements: Beginning with Windows Server 2003 SP1, arrays were required to support globally unique page 83 identifiers for LUNs exposed in clusters. With Server 2008, that requirement extends to all hardware shadow copies including non-clustered cases. This means that both the original LUN and the shadow copy LUN must have at least one globally unique identifier of type 1, 2, 3 or 8 and Association 0.
Now let’s consider some of the new scenarios enabled in Windows Server 2008.
Multiple Imports : Hardware transportable shadow copies created on Windows Server 2008 may be imported to more than one host though not concurrently. For example it’s possible to create a hardware shadow copy of a SQL database on host A, mask it and import it to host B where it may be used to stream a backup to tape. The same shadow copy may then be masked and if required imported once again to either A or B or to an entirely new host for the purpose of data mining or a quick recovery.
This scenario requires support from both hardware providers and requesters. Specifically the hardware provider must support the OnLunStateChange method of the IVssHardwareSnapshotProviderEx interface which is new with Windows Server 2008. Requesters must call the BreakSnapshotSetEx method of the IVssBackupComponentsEx2 interface to use this functionality
Auto recovery of hardware transportable shadow copies: With Windows Server 2008 it is now possible to create a transportable hardware shadow copy that has been auto-recovered. Auto recovery is the processing performed on a shadow copy immediately after it is created.
A common example is the need to roll back database transactions that were incomplete when the shadow copy was created. Auto-recovery may also be used to roll back incomplete transactions within NTFS . It must be noted that file system transactions may also be rolled back when the shadow copy is first imported i.e. in the absence of auto-recovery NTFS transactions are rolled back when the shadow copy is first imported to a system.
Support for auto recovery of hardware transportable shadow copies requires that hardware providers support the OnLunStateChange method. Requesters can control both the auto recovery behavior during snapshot creation and also recovery later during import using the context flags VSS_VOLSNAP_ATTR_TXF_RECOVERY and VSS_VOLSNAP_ATTR_NO_AUTORECOVERY
Convert a hardware shadow copy into a read-write volume: In Windows Server 2008 it is possible to convert a hardware shadow copy into a read-write volume. This requires requesters to use the BreakSnapshotSetEx method with the VSS_BREAKEX_FLAG_MAKE_READ_WRITE flag specified. There are no changes required from hardware providers to support this feature. Note that once a shadow copy has been converted into a read-write volume, it cannot be managed using VSS APIs.
You can find sample code for all these scenarios in the sample provider (vsssampleprovider) and requester (vshadow) in the VSS SDK which is now included in the Windows SDK. The most recent pre-release version is available here .
In addition to the scenarios discussed above there are several enhancements to make the shadow copy creation and import process more robust. These do not require any changes from requesters or providers. Note that existing Server 2003 hardware providers should work on Server 2008 albeit without any of the new functionality.
If you have any comments or are looking for more information in specific areas write us at vss(nospam)@microsoft.com. Stay tuned for more on what’s new in VSS.
- Dinesh
Updated Apr 10, 2019
Version 2.0