Volume Shadow Copy Service (VSS) Express Writers

[#1]

First published on TECHNET on Jun 16, 2009

In this article, we'll take a look at a new class of VSS writers enabled in Windows 7 and Server 2008 R2 that lower the cost for applications to participate in backups. Before we get there though, let’s briefly recap the role of VSS writers in backups.

VSS and backups

The Volume Shadow Copy Service or VSS as its better known is the backup infrastructure in Windows. Data protection applications ( requesters ) use VSS to create snapshots of volumes for various purposes including data mining and backups. Backup agents rely on VSS writers to ensure that application data is in a consistent state on disk before creating a snapshot or point-in-time image of one or more volumes. The snapshot itself may be used as the backup or the data may be copied from it to tape.

Snapshots facilitate online backups i.e. the application can continue to process and write to disk, while the requester copies data from the snapshot to backup media. Absent snapshots, the requester would have to contend with open files and constantly changing data. All of this is described in more detail here .

VSS writers help backups and restores in one or more of the following ways.

·       Discoverability: VSS writers make it possible for a requester (backup agent) to discover the location of an application's data stores and requirements for their backup and restore. For example, the writer may indicate in its metadata that the application needs to be re-started after the data is restored.

·       Data Consistency:  Writers ensure that the application’s data on disk is in a consistent state prior to the creation of the snapshot. In some cases, writers may rollback incomplete transactions on the snapshot during the auto-recovery phase.

·       Post backup processing : Writers may perform clean-ups like truncating logs after the backup is complete.

·       Restore processing : Some applications may require preparation prior to a restore like releasing handles or dismounting databases. In other cases the writer performs fix-ups like applying logs, after the restore.

Motivation for Express Writers

As we've just seen the traditional VSS writer model offers a great deal of functionality and supports rich semantics which are often necessary for sophisticated applications and services like databases and line- of-business workloads.

On the other end of the spectrum are several applications and OS components with relatively simple storage layouts. These applications may have their data and metadata contained in a few files and occasionally a local database. They are usually capable of recovering from a system crash because they transact updates or maintain logs. For this reason, there isn't anything to be done in the way of ensuring data consistency for a backup since they can recover from a crash consistent image of their data.  Similarly these applications do not require any processing after a backup or restore either. They still do need to identify the locations of their data and metadata though.

For such applications, the traditional VSS writer model may present a relatively high overhead because of the need to host the writer in a long running service, deal with COM+ registrations and run-time issues like security context mismatches etc.

The new Express Writer APIs are intended for precisely these kinds of applications and present a much simpler interface with minimal run-time interactions.

Express Writer overview

The Express writer APIs are designed to address discoverability of application data and metadata for backups. Using the new APIs an application can register the location of its stores during an install. Similarly, in the event of a configuration change or servicing, the application can update this information.  All the metadata is presented to the requester at the outset of a backup without the involvement of the application. In fact the application doesn’t even need to be running at this time. When the application is un-installed, it unregisters its metadata and is thus no longer reported to a requester.

It’s important to note that the Express Writer APIs are completely transparent to requesters . A backup application cannot tell the difference between a conventional VSS writer and an Express Writer and doesn’t require any changes to work with these new writers.

The Express writer APIs thus lower the bar for most applications to participate in VSS backups. The simpler APIs results in lower development, test and maintenance costs. There are also fewer moving parts in the system which ultimately leads to greater reliability and a better customer experience.

Incidentally the system state components, Performance Counters and Task Scheduler implement Express Writers in Windows 7 and Server 2008 R2.

Express Writer workflow and APIs

In this section we'll take a high level look at the APIs; you can find detailed documentation on MSDN and sample code in the Windows 7 SDK. You may notice that some of the APIs are similar to those for traditional VSS writers and in-fact they are a subset.

There are two workflows supported. In the first case, the backup metadata is built and registered at run time. This approach offers the most flexibility as the application can alter its metadata as needed at runtime - one example might be in response to configuration changes.

In the second approach, an application developer may build the metadata ahead of time, during the development phase and save the XML which is shipped with the application bits. During installation the application registers the previously created metadata with VSS. This workflow is ideal for applications that require metadata updates only in the event of servicing, if at all.

Here's the sequence of steps an application must follow for the first workflow.

1.        Call CreateVssExpressWriter to instantiate the IVssExpressWriter interface

2.        Invoke IVssExpressWriter::CreateMetadata to instantiate the IVssCreateExpressWriterMetadata interface.

3.        Use the IVssCreateExpressWriterMetadata interface to build the component hierarchy including defining the backup and restore schema.

4.        Register the metadata with the Volume Shadow Copy Service using

[DarkBlue100]

This post is not done.. Could it be completed? 

Can you elaborate about the relation of that and system restore point?