In VSS terms, NetWorker software is a requestor an application that needs data from other applications or services. When a requestor needs data from an application or service, this process occurs:
1. The requestor asks for this information from VSS.
2. VSS reviews the request for validity.
3. If the request is valid and the specified application has the requested data, the request goes to the application-specific writer, which prepares the requested data.
Each application and service that supports VSS has its own writer, which understands how the application or service works:
1. After the writer signals that it has prepared the data, VSS directs the writer to freeze I/O to the selected volumes, queuing it for later processing.
2. VSS then calls a provider to capture the requested data.
3. The provider, which is either software-based or associated with particular hardware (for example, a disk array), captures the prepared data, creating a snapshot (or shadow copy) that exists side-by-side with the live volume.
The process of creating a snapshot involves interaction with the operating system. The amount of time it takes to create a snapshot depends on a number of factors, including the writer activity taking place at the time. Once the snapshot is created, the provider signals VSS, which tells the writer to resume activity. I/O is released to the selected volumes and any queued writes that arrived during the provider’s work are processed.
VSS backup process provides a graphical representation of the VSS backup process.
In other words:
Volume Shadow Copy Service (VSS) manages the creation of a point-in-time shadow copy, or snapshot, of a disk volume or set of data. Let us look at how they work together to create a snapshot.
1. The requestor, such as a NetWorker, requests VSS to create a snapshot of a particular volume or data set.
2. VSS notifies the application-specific writer to prepare its data for making a shadow copy. The writer creates an XML description of the backup components and defines the restore method. The writer prepares the data by completing all open transactions, rolling transaction logs and flushing caches. VSS then directs the writer to temporarily freeze requestor I/O write requests for the time required to create the shadow copy. VSS 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.
3. VSS notifies a provider to create and maintain the shadow copy until it is no longer needed. A point-in-time copy of the complete volume mapping is created using XML. The XML file is a bitmap of the current state of the volume but does not contain any file data.
4. Once the snapshot has been successfully created, VSS thaws the file system and instructs the writers to resume normal activities, or thaw. VSS provides the location information for the shadow copy back to the requestor.
5. The requestor (NetWorker) now proceeds with the backup of the point-in-time snapshot that is created.
6. After the snapshot is created, write requests destined for the source volume are first processed by the providers disk I/O interceptor.
7. The interceptor copies the data contained in the original sectors to the virtual volume before the write to the sectors of the source volume is allowed.
8. The requestor determines whether to back up the data from the source volume or from the virtual volume. Data that has not changed since the time the shadow copy was created is read from the source volume; where data has been changed, a copy of the original data is read from the virtual volume.
VSS Recovery Workflow:
The steps performed by NetWorker to recover VSS save sets are:
1. The writers metadata document s recovered and used by Net Worker to determine the writers restore method.
2. Active writers are queried to determine if an alternate recover location will be used; this step is dependent on the type of VSS save set.
3. NetWorker asks VSSto mark each component that will be recovered.
4. A pre-restore warning is sent to all affected writers.
5. The files are recovered to the correct locations as defined by the recovery method for each writer.
6. Once files have been recovered, a post-restore message is sent to all affected writers.
7. Any final steps required to complete the recovery are performed, as detailed in the writers metadata document.