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.
10 tips in 10 minutes: Fundamentals of Exchange Server disaster recovery
Tip 1: Defining Exchange disaster recovery
Tip 2: How Exchange backs up data
Tip 3: Choosing a backup type for Exchange
Tip 4: Online vs. offline Exchange Server backups
Tip 5: Basic Exchange backup and restore
Tip 6: Exchange vendor snapshots and point-in-time copies
Tip 7: VSS for Exchange
Tip 8: Exchange Server replication
Tip 9: Exchange design choices and issues
Tip 10: Exchange disaster recovery planning
The Definitive Guide to Exchange Disaster Recovery and Availability Realtimepublishers chapter download download all available chapters here