Building the foundation: Volume Shadow Copy Service

By Jerry Cochran 01 Nov 2004 | SearchExchange.com

Digg This!     StumbleUpon     Del.icio.us

The following is tip #17 from "20 tips on protecting and recovering Exchange data in 20 minutes," excerpted from the book, "Mission Critical Microsoft Exchange 2003" (Digital Press, a division of Elsevier, Copyright 2004). For more information about this book and other computing titles, please click here. Return to the main page for more tips on this topic.

Third-party hardware and software developers have implemented snapshot and clone technology solutions with little of or no exposure or integration with the operating system and applications. This has led to the current status quo of varied and noninteroperable solutions from hardware and software vendors that are not supported by Microsoft.

While Microsoft has acknowledged that these technologies are available, they have limited support and put the primary support responsibility on the vendors of these solutions.

The storage technology investments made by Microsoft in Windows Server 2003 are substantial and VSS is one of those investments. Shadow copy is the term that Microsoft uses to describe the snapshot or clone technology. VSS provides a framework that makes snapshot and clone technologies available to applications and provides some operating system -- level support for the synchronization and coordination required to implement them. These services can be used by Windows Server 2003 components (including AD and the Windows Certificate Server), Microsoft and third-party applications, and third-party backup, data integrity, and SAN product build solutions that leverage snapshot or clone technology.

The Windows VSS has three primary goals:

• Provide application synchronization so that backup programs do not have to be intimately aware of how a particular application stores or recovers its data;

• Provide a way for tools and utilities to discover and enumerate shadow copies; and

• Provide a framework where hardware and software vendors can plug-in interoperable shadow copy providers.

With these goals in mind, Windows Server 2003 delivers a robust architecture that enables a hardware vendor to supply a shadow copy creation component (called a provider), an application devel¬oper to expose shadow copy "packages" called writers that provide XML-based metadata to VSS, and backup vendors that can build applications (called requestors) that can initiate backup and restore operations that leverage these components on a common infrastructure.

VSS providers
VSS exposes APIs that enable vendors to VSS-enable their solutions. In order for a particular vendor's snapshot/clone technology to function within the VSS framework, each vendor must develop a VSS provider. Providers are the components that manage volumes and create clones and snapshots per a specific vendor's technology and implementation -- think of the provider as the agent that actually writes the shadow copy data on a particular storage platform. Typically, a provider is a process (some kernel-mode and user-mode code) that persists data about a physical shadow copy in order for that shadow copy to be exposed to the operating system and/or applications. Providers must be built regardless of whether the vendor's solution is hardware based or software based. In the case of a software-based provider, the implementation is usually a user-mode process coupled with a kernel-mode device driver. Both types of solutions (hardware and software) and the implementation details of the provider are left to the discretion of the vendor as long as they follow the implementation rules of the VSS framework (this is what makes VSS supportable from a Microsoft perspective).

Windows Server 2003 includes a software-based shadow copy provider (implemented as a copy-on-write software snapshot) as part of the operating system; various other vendors have written providers that make their storage products compatible with VSS.

VSS writers
The most important player in the VSS framework is arguably the application. The application must carefully expose recovery "packages" that are specific to an application's technology, implementation and disaster-recovery requirements and constraints.

For example, since Exchange Server is a transacted database engine, it will have requirements that are unique when compared even with applications similar in nature (such as SQL Server or Oracle). VSS writers are code and data that is embedded in applications and components of those applications to enable VSS compatibility.

Application writers respond to the shadow copy interface to ensure data integrity and consistency during shadow copy operations. Writers respond to requestors (via the VSS interface) by supplying writer metadata that includes the details of what is required to perform shadow copy operations for the specific application.

When a requestor asks for a shadow copy, the writer will prepare its data to be copied, normally by freezing incoming write requests and flushing any cached data that has not been written to disk. After those preparations are complete, the writer signals the VSS framework that it is safe to copy the application data; after the copy is finished, VSS notifies the writer that it is safe to resume normal I/O operations. The goal of this implementation is to ensure that no writes occur on the volume during shadow copy operations (when the shadow copy is created). A backup operation performed using VSS is a systematic and well-orchestrated process that involves the interaction of each of the components in the VSS framework.

VSS requestors
Backup and disaster-recovery solution vendors participate in the VSS framework by developing their applications to make use of the VSS architecture, APIs and implementation rules. These vendors must develop VSS requestors.

A requestor is a process or application (automated or GUI-based) that requests that one or more shadow copy sets be taken from one or more volumes. The requestor is the main process that communicates with the VSS interface; VSS coordinates requests by passing them to writers and providers as necessary. The requestor also communicates directly with writers to gather backup components, files, and metadata managed by the writers. This allows a requestor to select the volumes that should be shadow-copied to complete the requirements of the backup operation.

With the advent of VSS, I look to the day when all Windows backup solutions are based on VSS -- otherwise, they will find it increasingly difficult to be supported by Microsoft.

Get more "20 tips on protecting and recovering Exchange data in 20 minutes." Return to the main page.

About the author: Jerry Cochran is a contributing editor for Windows IT Pro and Exchange & Outlook Administrator and a group program manager for Microsoft. He is the author of Mission-Critical Microsoft Exchange 2000 (Digital Press).

Digg This!     StumbleUpon     Del.icio.us