Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2
- Methods for Creating Shadow Copies
- Volume Shadow Copy Service Architecture
- Components Used for Creating Shadow Copies
- How Shadow Copies Are Created
- Related Information
The Volume Shadow Copy Service can produce consistent shadow copies by coordinating with business applications, file-system services, backup applications, fast-recovery solutions, and storage hardware. Several features in the Windows Server 2003 operating systems use the Volume Shadow Copy Service, including Shadow Copies for Shared Folders and Backup.
Methods for Creating Shadow Copies
Clone (Full Copy/Split Mirror):
Hardware vendors offer different hardware-based implementations (sometimes called split mirrors, snapshot mirrors, or clones) for creating identical images of volumes that can be used for online backup, application development, and testing.
Copy-on-Write (Differential Copy)
The Copy-on-Write Method of Creating Shadow Copies
|Time||Source Data||Contents||Shadow Copy||Contents|
| T0 || Original data || 1 2 3 4 5 || No copy || — |
| T1 || Original data overwritten || 1 2 3 4 5 || Differences and index stored on shadow copy || 3 |
Volume Shadow Copy Service Architecture
Volume Shadow Copy Service Architecture Diagram
Volume Shadow Copy Service Components
| Volume Shadow Copy Service || A service that coordinates various components to create consistent shadow copies of one or more volumes. |
| Requestor || An application that requests that a volume shadow copy be taken. A backup application is an example. |
| Writer || A component of an application that stores persistent information on one or more volumes that participate in shadow copy synchronization. Typically, this is a database application like SQL Server or Exchange Server, or a system service like Active Directory. |
| Provider || A component that creates and maintains the shadow copies. Examples are the system provider included with the operating system and the hardware providers included with storage arrays. |
| Source volume || The volume that contains the data to be shadow copied. |
| Storage volume || The volume that holds the shadow copy storage files for the system copy-on-write software provider. |
Components Used for Creating Shadow Copies
Requestors: Initiating Shadow Copy Creation
The requestor also communicates with the writers to gather information about what should be backed up and how it should be backed up.
Writers: Preventing Data Inconsistencies
- When applications and services are running, the writer responds to signals provided by the Volume Shadow Copy Service interface to allow applications to prepare and quiesce their data stores for shadow copy creation and to ensure that no writes occur on the volume while the shadow copy is being created. (During quiescence, applications make data on the disk consistent. For example, an application might flush its buffers to disk or write out in-memory data to disk.)
- The writer also provides information about the application name, icons, files to include or exclude, and a strategy to restore the files.
A writer is associated with one or more components. A component is a group of files that must be backed up as a unit. For example, a database and set of log files. For a backup to be successful, all files associated with the component must be backed up. Writers also provide information about restoring the data on a component-by-components basis.
If an application has no writer, the shadow copy will still occur and all of the data, in whatever form it is in at the time of the copy, will be included in the shadow copy. This means that there might be inconsistent data that is now contained in the shadow copy. This data inconsistency is caused by incomplete writes, data buffered in the application that is not written, or open files that are in the middle of a write operation. Even though the file system flushes all buffers prior to creating a shadow copy, the data on the disk can only be guaranteed to be crash-consistent if the application has completed all transactions and has written all of the data to the disk. (Data on disk is “crash-consistent” if it is the same as it would be after a system failure or power outage.)
Under this design, the responsibility for data consistency has been shifted from the requestor application to the production application. The advantage of this approach is that application developers — those most knowledgeable about their applications — can ensure, through development of their own writers, the maximum effectiveness of the shadow copy creation process.
Applications that are not shadow copy–enabled
While the crash-consistent state does not fully deal with all the issues associated with defining a stable backup set, it has several advantages over the backup set that conventional backup operations would have to use.
- For example, a shadow copy of a volume, even in crash-consistent state, still contains all files. A backup set created without a shadow copy would not contain all files open exclusively at the time of the backup. Files held open at the time of the backup operation are excluded from the backup.
Providers: Creating Shadow Copies
Alternatively, other hardware and software vendors can develop their own hardware or software providers to provide point-in-time imaging functionality. Windows Server 2003 supports multiple hardware and software providers that can be used in combination to solve many different IT operational scenarios.
The Volume Shadow Copy Service uses the following hierarchy to select the provider to use during shadow copy creation:
- Hardware provider
- Software provider
- System software provider.
Hardware providers always take the shadow copy of an entire LUN, but the Volume Shadow Copy Service will only expose the shadow copy of the volume or volumes that were requested.
While a hardware-based shadow copy provider makes use of the Volume Shadow Copy Service functionality that defines the point in time, allows data synchronization, manages the shadow copy, and provides a common interface with backup applications, the Volume Shadow Copy Service does not specify the underlying mechanism by which the hardware-based provider produces and maintains shadow copies.
These providers are implemented as a user-mode DLL component and at least one kernel-mode device driver, typically a storage filter driver. The work of creating these shadow copies is done in software.
A software-based shadow copy provider must maintain a “point-in-time” view of a volume by having access to a data set that can be used to recreate volume status prior to the shadow copy. An example of this is the copy-on-write technique of the system provider. However, the Volume Shadow Copy Service places no restrictions on what technique software-based providers use to create and maintain shadow copies.
A software provider will be applicable to a wider range of storage platforms than a hardware-based provider and should be able to work with basic disks or logical volumes equally well.
This implementation sacrifices the performance that might be available by implementing shadow copies in hardware and does not make use of any vendor-specific features.
To maintain the “point in time” view of a volume contained in a shadow copy, the system provider uses a copy-on-write technique. Copies of the blocks on volume that have been modified since the beginning of the shadow copy creation are stored in a shadow copy storage area.
The system provider can expose the production volume, which can be written to and read from normally. When the shadow copy is needed, it logically applies the differences to data on the production volume to expose the complete shadow copy.
For the system provider, the shadow copy storage area must be on an NTFS volume. The volume to be shadow copied does not need to be an NTFS volume, but at least one volume mounted on the system must be an NTFS volume.
How Shadow Copies Are Created
Shadow Copy Creation Process
- The requestor asks the Volume Shadow Copy Service to enumerate the writers, gather the writer metadata, and prepare for shadow copy creation.
- The writer creates an XML description of the backup components to the Volume Shadow Copy Service, and defines the restore method. The Volume Shadow Copy Service notifies the application-specific writer to prepare its data for making a shadow copy.
- The writer prepares the data in whatever way is appropriate, such as completing all open transactions, rolling transaction logs, and flushing caches. When the data is prepared for shadow copy creation, the writer notifies the Volume Shadow Copy Service.
- The Volume Shadow Copy Service initiates the “commit” shadow copy phase.
- The Volume Shadow Copy Service tells the writers to quiesce their data and temporarily freeze requestor (application) I/O write requests (I/O read requests are still possible) for the several seconds required to create the shadow copy of the volume or volumes. The application freeze is not allowed to take longer than 60 seconds. The Volume Shadow Copy Service flushes the file system buffer and then freezes the file system, which ensures that file system metadata is written and that the data is written in a consistent order.
- The Volume Shadow Copy Service tells the provider to create the shadow copy (a maximum of 10 seconds).
- The Volume Shadow Copy Service thaws the file system. After the shadow copy is created, the Volume Shadow Copy Service releases the writers from their temporary inactive phase and all queued write I/Os are completed.
- The Volume Shadow Copy Service queries the writers to confirm that write I/Os were successfully held during shadow copy creation.
- If the writes were not successfully held (meaning that the shadow copy data is potentially inconsistent), the shadow copy is deleted and the requestor is notified.
- The requestor can retry the process (go back to step 1) or notify the administrator to retry at a later time.
- If the copy is successful, the Volume Shadow Copy Service gives the location information for the shadow copy back to the requestor.