If you find the inner workings of Exchange data backups using Volume Shadown Copy (VSS) a bit mystifying take comfort in not being alone. Administrators may ask, “What’s all the “freezing” and “thawing” I’m seeing in my event logs? What is the Exchange VSS Writer really, and what is it doing to my databases? How does it create a snapshot of a 135GB database in less than 60 seconds?”

If you ever asked these questions but only felt more confused with the answers, here’s a guide to clear some of that up. To understand how a VSS backup of Exchange works it’s critical to understand the basics of VSS itself. There is some excellent documentation on TechNet and MSDN on this, as well as the Windows Server Core Team blog, “Ask the Core Team.” My esteemed colleague Randy Monteleone sums up the basics of VSS very nicely early in his post, while also providing links (repeated here) to some good TechNet primers on VSS:

How To: VSS Tracing – Randy Monteleone
http://blogs.technet.com/b/askcore/archive/2012/04/29/how-to-vss-tracing.aspx

How Volume Shadow Copy Service Works
http://technet.microsoft.com/en-us/library/cc785914(WS.10).aspx

Volume Shadow Copy Service
http://technet.microsoft.com/en-us/library/ee923636.aspx

If you’re already familiar with at least the basics of VSS, then look forward to Part 2 in this series, where we will break down the events that occur in a VSS Exchange backup, and how Exchange logs them in the application event log.

If you need a quick primer or refresher on VSS basics and the Exchange Writer I’ve condensed them into some visual points below to complement the references above.

Snapshots

Bear in mind that VSS solutions for Exchange, and for all applications, vary greatly between different hardware and software configurations. There are clone and COW snapshots, hardware and software solutions, just a very wide variety of technologies based on the core VSS subsystem. For the purposes of understanding Exchange backups we’re only going to illustrate one specific type of solution out of the multitude. Detailed below is what’s called “copy-on-write”, or “COW” snapshots.

In a COW snapshot-based VSS backup of Exchange we have the creation of snapshots of the disks where Exchange data is hosted. No matter what is getting backed up, even if it’s a single database file and a few logs, VSS creates a snapshot of the entire disk where any data is stored. If the data resides across multiple disks, such as when an Exchange database is on one disk, and the logs are on another, VSS will create snapshots of any and all of those disks.

So what is a “snapshot”? A volume snapshot is an area of space inside what’s called “shadow storage”, which is itself a typically small area of space on the disk located in its System Volume Information folder.

After a disk snapshot is created a change to any data block from that time forward cannot get written until a copy of that block’s data before the change (as it was when the snapshot was created) gets written to the differencing area in shadow storage. In this way the data on the disk at the time the snapshot was created is preserved, block by block, in the shadow storage area. The snapshot data is then available either from the original disk, if the data blocks requested haven’t changed, or from the differencing area if they have. The fundamentals of this are illustrated below:

Disk E: has a snapshot created at 1PM:

A minute later one of the blocks gets written to, but not before the data as it was at 1PM gets preserved in the differencing area:

As the actual disk changes the data as it was at 1PM gets written into shadow storage, preserving a record of the disk as it was in that moment:

The following step:

In the figure above a backup server requests data from the snapshot of blocks 2 and 53. Block 53 from 1PM is preserved in the snapshot, so it’s copied directly from shadow storage. Block 2 is unchanged since 1PM, so it is copied via the VSS driver VOLSNAP.SYS, which operates much like a filter driver underneath the NTFS.SYS file system driver. By working in the IRP stack (the part of kernel memory that manages disk I/O) underneath the file system it can read blocks of data without NTFS objecting that a file is in use. VOLSNAP.SYS is also responsible for ensuring blocks are copied over to shadow storage if a write is requested to them, hence the name “Copy On Write”. Here is more about VOLSNAP.SYS from Tim McMichael:

Exchange / VSS / and differential block size…
http://blogs.technet.com/b/timmcmic/archive/2011/07/12/exchange-vss-and-differential-block-size.aspx

Now that we’ve got the basics of a COW snapshot down let’s look at how it works with Exchange, along with some other major concepts:

Microsoft Exchange Writer

So we know that any disk that stores Exchange data gets a snapshot created of it by VSS. How exactly, though, does a backup application find out which disks those are? Oftentimes an administrator selects databases for backup without specifying anything about what disks their data files are stored in. So something is required to provide the information about where the data files are, and therefore what disks VSS needs to create snapshots of. This information also tells a backup application, also known as a VSS requestor, what specific data files should be copied out of the snapshots for preservation on backup media, as we don’t want to copy out anything from the disk we don't need.

The mechanism at work here is the Microsoft Exchange VSS Writer. Like any application’s VSS writer (there are many, just run VSSADMIN LIST WRITERS to see them) its first job is to tell the backup application about the data needed for backup, especially the EDB file, logs, and checkpoint file for each database requested. The information about these specific Exchange data files is known as writer metadata.

(click thumbnail for full size version)

In the figure above we see the initial steps of an Exchange backup. The Exchange Writer tells the backup server (the requestor) that there is a database located in a folder on volume E:, and that transaction logs for that database are in a folder on D:. Based on that information the backup application will request snapshots of the D: and E: volumes when the job progresses.

The Exchange VSS Writer serves another critical role besides providing metadata to VSS requestors. It also has the job of stopping writes to the databases and logs on disk, or “freezing” them, for the time it takes to create the necessary snapshots. A COW snapshot typically takes a small amount of time to create, as all it consists of initially is the designation of an area in shadow storage for blocks to be preserved in when they change on the actual disk. Despite this relatively quick operation it can still take up to a minute, which is plenty of time for blocks of data to change on a disk between the start and the end of its snapshot creation process. If blocks of data change but don't have the originals preserved from the exact time the snapshot creation begins those blocks may become inconsistent with other snapshot data, especially between logs, database, and checkpoint files. Hence, the Exchange Writer prevents the Information Store Service, or the MS Exchange Replication Service, from writing what’s in RAM to the frozen database files. In the case of the Information Store Service, the current transaction log file (Exx.log) gets rolled and closed out before the Exchange Writer allows VSS to take the snapshot. This ensures nothing changes in the file data between the beginning of the snapshot and the completion, at which point the databases are “thawed”. When databases are thawed write I/O held in RAM is allowed to go to disk again.

Here's more information on how an application's VSS writer interacts with VSS with regards to freeze, thaws, and the time needed to get a snapshot completed:

CVssWriter::OnFreeze method
http://msdn.microsoft.com/en-us/library/windows/desktop/aa381563(v=vs.85).aspx

The last major responsibility of the Exchange Writer is to tell the Information Store Service (MS Exchange Replication Service in the case of a passive copy backup) that the backup was completed and, if applicable, carry out post-backup tasks like log truncation, marking the database as no longer with a backup in progress, etc.

In the part two and part three of this series we’ll look at a play-by-play breakdown of how the elements described above all come together in an Exchange backup, the application log events that get generated, and compare the process for a mounted database to that for a passive database copy.

Thanks go out for the collaboration on the content in these posts to Michael Blanton, Tim McMichael, Randy Monteleone, Dave Vespa, and Tom Kern.

Source: MSExchangeTeam