The Exchange product team has long known that Exchange administrators want the benefits of point-in-time copies. However, building support for these backups into Exchange was problematic because Exchange doesn't handle its own disk I/O; that is delegated to the Windows I/O manager component of the kernel. Without a way to freeze I/O requests to a set of Exchange volumes, there wasn't a good way to enable Exchange to take safe point-in-time copies.

Enter VSS, introduced in WS2K3. Exchange Server 2003 supports VSS; together with a VSS-compatible backup program, these two products give you a safe and Microsoft-supported way to make point-in-time copies of your Exchange databases and transaction logs.

How VSS works

VSS is conceptually pretty complex. There are several interlocking components, some provided by the OS, some by Exchange, and some by the vendor of your backup hardware and software. Figure 2.1 shows a static representation of how these parts work together. However, a better way to understand how VSS pieces interact is to step through an actual VSS backup. The Microsoft article Exchange Server 2003 data backup and Volume Shadow Copy Services describes the process in fairly dry detail.

Figure 2.1: How the VSS components work together.

The following list highlights the VSS process:

The administrator launches a VSS-aware backup tool and starts a backup. In this case, "VSS-aware" means that the backup tool incorporates a VSS requestor, the component that is responsible for telling VSS which data should be backed up and when the backup is starting.

VSS accepts the request and finds the requested application, returning a list of data sources (in Exchange's case, storage groups) that can be backed up. Only those applications that have registered their writer components with VSS will have data available to the backup tool. The writer is responsible for performing application-specific actions to prepare the application data for copying by VSS.

The backup application selects the data it wants to back up, then tells VSS to start the backup. VSS in turn notifies the Exchange writer, which Microsoft ships as part of Exchange Server 2003, to prepare its data to be backed up. The writer turns around and asks VSS to freeze write requests to the volumes that hold the Exchange data to be copied. Read operations, and any writes that are already partially complete, can continue; new write operations are queued.

After VSS finishes freezing I/O for all target volumes (the logs and databases are probably on separate volumes but need to be backed up together), it notifies the writer that it's clear to proceed. In Exchange's case, the writer will close the currently active log file, rename it, then create a new temporary log file. The writer also calculates the range of log files that need to be included in the storage group backup and passes that information to the requestor.

When the writer is finished preparing the application data, it signals VSS, which notifies the requestor that it can proceed with the backup. The requestor then asks a VSS provider to actually copy the data. VSS includes a basic provider for copying data between disk volumes; SAN hardware vendors such as EMC and Xiotech often ship their own provider to enable additional kinds of backup mobility.

When the provider finishes making its copy, it notifies VSS, which notifies the backup application. Once the backup tool decides that it's finished, it tells VSS to release the application data, at which point I/O to the relevant volumes is unfrozen and normal operation resumes.

VSS: Pros and cons

VSS was designed to provide the fast backup and recovery of third-party snapshot solutions in a way that would be supported by the Windows kernel and Microsoft applications such as Exchange and SQL Server. The biggest pro of VSS is that it delivers this capability in a way that is guaranteed to always produce consistent backups; because Exchange is integrated with VSS, you can directly restore a VSS backup to an Exchange server in the same manner (although with a different API) as the online backup mechanism.

Getting this degree of support required some fairly extensive changes both to Windows and to Exchange, which is why you must be running Exchange Server 2003 on WS2K3 to use VSS. This requirement can be a pro or a con, depending on the combination of versions you're using and what your upgrade plans look like.

In the same vein, to use VSS, you will need to have compatible hardware and backup software. This requirement might mean upgrading what you've already got. VERITAS, CommVault, Yosemite, and other major vendors support VSS in their latest versions. Depending on what type of SAN you have, you might be able to take VSS shadow copies and logically move them between hosts on the SAN, which enables off-host backup. When considering VSS deployment, factor in the cost of upgrades required to your SAN and backup infrastructure.

Start the conversation

0 comments

Register

I agree to TechTarget’s Terms of Use, Privacy Policy, and the transfer of my information to the United States for processing to provide me with relevant information as described in our Privacy Policy.

Please check the box if you want to proceed.

I agree to my information being processed by TechTarget and its Partners to contact me via phone, email, or other means regarding information relevant to my professional interests. I may unsubscribe at any time.