Hardware providers may support copy-on-write and/or full copy mirror (differential and/or plex)
shadow copies. Resource allocation for shadow copies should follow the context specified by the requester in
IVssBackupComponents::SetContext,
enumerated by _VSS_SNAPSHOT_CONTEXT, for the shadow
copy set.
- If the requester specifies a shadow copy context that is supported by the provider, the provider should
create a shadow copy using that method.
- If the requester specifies a shadow copy context that is not supported by the provider, then the provider
should not attempt to create the shadow copy and return FALSE through the pbIsSupported parameter in
IVssHardwareSnapshotProvider::AreLunsSupported.
- If the requester does not explicitly specify a shadow copy context, then the provider should use
reasonable default behavior for shadow copy creation.
Hardware providers associated with SAN RAID subsystems should support transportable shadow copies to allow
movement between hosts on a SAN.
Hardware providers running on multiple machines on a SAN yet managing the same RAID subsystem do not need to
coordinate between providers on a SAN. The coordinator maintains any necessary state. Two kinds of state are
recognized:
- State necessary to support data access to the volumes contained on a hardware shadow copy. This includes
any tagging of a volume as read-only or hidden. This state must be on the hardware LUN and travel with the LUN.
This state is preserved across boot epochs and/or device discovery. VSS manages this state for the lifetime of
the shadow copy.
- State necessary to recognize a specific volume as part of a shadow copy set. This state is persisted by
VSS in conjunction with the requester that originally created the shadow copy set.
For more information, see the following topics:
Send comments about this topic to Microsoft
Build date: 11/12/2009