Windows Insider

Freeze Frame

Windows Server 2003’s Volume Shadow Copy Service can help you stop time. Here’s how to take full advantage of it.

• By Bill Boswell
• 03/01/2004

Stopping the clock.... The idea has universal appeal. Who wouldn’t like to wedge the sweep hands for awhile? Just think of the wonderful things you could accomplish. If you could freeze time at a server, you could take a complete backup of all its data without a single worry about locked files or block inconsistencies or backup windows. You could snatch a replica of the server’s data so your developers could play without disturbing production. Or you could truck the replica to a server room buried deep under a mountain where, protected from bombs and floods and careening asteroids, you maintain an identical server ready for emergency use.

The ability to freeze time is not just a science-fiction plot device. The Volume Shadow Copy Service in Windows Server 2003 has the ability to freeze time, in a manner of speaking, by capturing the point-in-time content of a data volume and then making that content available to applications such as backup programs, data warehouse applications and file recovery utilities.

Say Cheese
Point-in-time technology has been around for a while in hardware storage solutions. Two methods for capturing point-in-time content are commonly used: split-mirror and copy-on-write.

Split-mirror: These solutions first create a full block-by-block copy of a volume. Then, when the mirrored volumes have synchronized, the mirror is broken to produce a faithful point-in-time replica.

Copy-on-write: These solutions avoid the large storage requirements of split-mirror by mapping out the data blocks on a volume then saving the content of a block that is about to be modified. The file system can provide an historical copy of a file by aggregating the unchanged blocks on the main volume with the saved blocks in the copy-on-write repository.

A major challenge for either point-in-time solution involves data consistency. You can appreciate this challenge if you’ve ever gotten together with your family for a holiday. An uncle with a camera waves all the aunts and uncles and cousins into position then commands you all to keep still and smile. You know from experience that if you move or blink during the taking of this photograph, the next family newsletter will feature your smeared features and closed eyes, so you’re careful to stand very still until you hear the shutter snap.

To avoid “blurred” data, a point-in-time service needs a way to tell applications to suspend operations and flush their buffers so it can capture consistent content in the database files, transaction logs, checkpoint files and other support files. The Volume Shadow Copy Service acts as this communications middleman. It works with the file system to flush and hold cached data across multiple volumes while coordinating point-in-time operations with three groups of players: Providers, Requestors, and Writers.

Providers communicate more or less directly to the hardware, making device calls that initiate the split-mirror or copy-on-write transactions. VSS can work with both types of point-in-time copy solutions—split-mirror and copy-on-write—so long as the hardware vendor has written VSS support into the provider.

Requestors need point-in-time services. Examples include backup applications, real-time file recovery utilities and off-site storage solutions, among others.

Writers are applications that store data on the volumes that VSS manages. VSS communicates to the Writers, telling them to flush buffers and do other data prep necessary to support a point-in-time operation. Microsoft databases include VSS support and are considered VSS Writers. If you run a third-party application, be sure to look for VSS support in the next round of upgrades.

Most of the hardware storage solutions from companies such as EMC, IBM and HP either include a VSS provider or will have one very soon. Microsoft recognizes that many of its customers don’t have the budget for high-end arrays with point-in-time capabilities, so Windows 2003 includes a software-based VSS provider called the Microsoft Software Shadow Copy Provider, Swprv. The driver for this provider is Volsnap.sys. This provider can perform copy-on-write operations using directly attached drives and block-based storage area networks such as Fibre Channel and iSCSI. Network Attached Storage devices based on Windows Storage Server also have VSS support.

Shadow Copies of Shared Folders
One of the most compelling features enabled by VSS is called shadow copies of shared folders. This feature enables users to recover historical copies of files quickly if they accidentally delete or overwrite the current copy. This relieves the IT staff of the necessity to do individual file restores from tape.

Although the feature includes the phrase “shared folders,” it’s implemented as a snapshot of an entire volume. You can’t make shadow copies of individual shares on the volume. Enable the feature by opening the Properties window for an NTFS volume in Explorer, then selecting the Shadow Copies tab (see Figure 1). You manage shadow copies for any volume on the server from the main interface.

Figure 1. The Volume Properties window showing the Shadow Copies tab.

The shadow copy provider puts the shadow copy files in a super-hidden folder called System Volume Information. The shorthand term for this folder is the “diff area.” The files inside this folder are called the “diff files.” Each of the diff files represents a snapshot of the data volume.

One of the critical decisions you need to make when configuring shadow copies for a volume is the location for the diff files and how much space to set aside for them. You do this using the Settings window for the shadow copy properties of an individual volume (see Figure 2).

Figure 2. The Shadow Copy Settings window shows the size limit on shadow copy files.

By default, the system places the diff area on the volume you’re shadowing, but for best performance, you should use another drive. There are no hard and fast rules governing the size of this drive. The shadow copy provider saves changes based on blocks rather than entire files, which reduces the size of the diff files somewhat, but many applications write an entire file when saving changes to a document. This can fill the diff area faster than you might expect.

Microsoft recommends having enough space in the diff area volume to handle up to 10 percent of the storage capacity of the data volume, so shadowing a 1TB volume requires something over 100GB of additional storage. To be on the safe side, you might want to budget a little additional storage capacity until you get a feel for your actual production ratios. If you shadow multiple data volumes on a server, you can save the diff files to a common volume.

Seven Volume Shadow Copy Tips 1. By default, a shadow copy snapshot occurs twice a day, Monday through Friday. You can change this interval or the times at which the snapshots occur by clicking the Schedule button in the Settings window. Regardless of the size of the volume holding the diff area, the shadow copy for share folder feature has a limit of 64 shadow copy files. If you use the default snapshot schedule, users can look back at approximately a month of file history. To create a larger window, take fewer snapshots and minimize the manual shadow copies you perform using the Create Now button. 2. Personal applications that maintain a random access file repository, such as an Access database or an Outlook .pst file, aren’t good candidates for previous version recovery. These applications don’t have a writer, so the snapshots might not be in a consistent state. It’s difficult to know if users have these sorts of files somewhere in a volume, so you should do a bit of end-user training to set expectations. 3. If you move a file to another folder, the file no longer has any items in the Previous Versions tab. That’s because you’ve essentially created a new file and deleted the old one. If you need a previous version of the file, recover it from the original folder. 4. If you make a change to the permissions list for a file, either directly or by inheritance from the parent folder, then recover a previous version; the recovered copy gets the same permissions as the file it overwrites. If you choose to copy the previous version rather than recover it, then the copy inherits the permissions from the folder where you put it. 5. The shadow copy provider uses 16K blocks, so if you defrag a volume that has 4K clusters, you’ll cause a lot of changes to the internals of the shadowed blocks and quickly fill the shadow copy file to its maximum capacity. To avoid this problem, format the data volume with a block size of 16K. This allows the defragger to move the blocks around without changing their content, which doesn’t trigger a copy-on-write. 6. If you use a backup program that takes advantage of the Microsoft shadow copy provider, it’s important to have sufficient storage to hold the differential content for the duration of the backup. For example, if you decide to do a backup of an Exchange or SQL server in the middle of the work day, and the backup takes three or four hours, then the shadow copy files must hold all the blocks that change during the backup. This could be a substantial quantity of data on a large server. 7. FAQs for shadow copies can be found at www.microsoft.com/ windowsserver2003/techinfo/overview/scrfaq.mspx.

Recovering Previous Versions
Users can view and recover volume shadow copies using an extension to the Explorer shell called the Shadow Copy Client, available as a Windows installer package, ShadowCopyClient.msi, downloadable at www.microsoft.com/downloads. The shadow copy client runs on Windows XP and Windows 2000 SP3 or newer. Be sure to get the most current version, which fixes a bug that prevented viewing deleted items in the root of a shared folder from a Win2K desktop.

The shadow copy client adds a new tab called Previous Versions to the Properties window for a file or folder in Explorer (see Figure 3). You’ll only see the Previous Versions tab in Explorer if you connect to a share point. It won’t appear if you connect to the console of the server, either physically or via remote desktop. If you want to see the Previous Version tab at the console of a server, open an Explorer window and connect to the $ share for the volume.

Figure 3. The File Properties window, showing the Previous Version tab with a snapshot of a prior version listed.

If the file contents change after taking a shadow copy of a volume, the date and time of the shadow copy appears in the Previous Versions tab. If the file changes frequently, the user will have several different versions to choose from. The user can elect to overwrite the file or copy the previous version to another folder.

Shadow Copy Operation
When you first enable shadow copies of shared folders on a volume, the shadow copy service maps out the blocks currently in use in the data volume. The service uses 16K blocks regardless of the underlying cluster size.

Following the initial shadow copy, each time the file system is about to make a change to a mapped block, the Volume Shadow Copy Service copies the block’s current content into the diff area then permits the file system to change the block. The shadow copy provider simply appends the block to the main shadow copy file, so this process doesn’t take very long. Over a period of time, the main shadow copy file fills with 16K blocks, each holding content from the data volume that existed as of the moment of the last snapshot.

Because the contents of the diff area contains only changed blocks, new files created after the shadow copy don’t get written into the shadow copy file. Neither does new content added to existing files if the new content extends beyond the mapped blocks.

Now take a manual snapshot by clicking the Create Now button. Several things happen during the snapshot. The volume shadow copy file gets truncated to the point of the last block in the file to recover the file space. The truncated file gets renamed by the addition of a unique identifier to the existing name. A new shadow copy file is created to act as the data repository.

Following the second shadow copy, when a block in the data volume gets modified, the existing content gets copied into the new volume shadow copy file. The original snapshot file remains in place.

At this point, let’s say a user accidentally deletes the file. Thanks to the historical versions saved in the shadow copy repository, the user can recover the file in seconds—without making a call to the Help Desk—by opening the Properties window for the folder that originally held the file. If this is the root folder of a share, the user can right-click on the background of the open folder and open the Properties window from there. The content of the Previous Versions tab appears a little different for a folder. Figure 4 shows an example.

Figure 4. The Previous Version tab from a folder permits selecting folder view from previous snapshots.

Each of the entries on the list represents a shadow copy of the folder contents. Double-click one of the entries to get an Explorer window showing the files and folders that were present at the time of the snapshot. One of these will be the deleted file. You can right-click the icon and select the Copy or Recover option.

Beyond Shadow Copies
As helpful as shadow copy for shared folders might be, this feature only hints at the power of point-in-time solutions. A new generation of shadow copy management applications has begun to appear that promises to resolve a host of different storage challenges. For example, with proper hardware, you can create transportable replicas that can be ferried to a remote location or mounted to another server. You can even use the replica to restore an existing server by remapping the Logical Unit Numbers (LUN) within a SAN. Transportable shadow copies aren’t supported by software providers.

In a more mundane sphere, shadow copies can revolutionize your daily backup grind. Consider an Exchange server supporting a few thousand users. Exchange 2003 can have up to 20 mailbox and public folder stores, each one holding dozens, even hundreds, of GB of data. Backing up such a behemoth challenges your budget and your backup window. But an Exchange backup application that includes a VSS requestor can make a quick snapshot of the Exchange files followed by a leisurely transfer of the snapshot contents to tape. Because the snapshot represents a full point-in-time copy of the mailbox stores, the backup program can use standard MAPI calls to restore individual mailboxes without resorting to a full tape restore.

The same is true for backing up a Microsoft SQL server, where VSS makes it possible to avoid tedious export dumps and resolves any doubts concerning the content of backed up transaction logs and data files because the snapshot guarantees internal consistency.

So in the upcoming months, keep your eye open for hardware that includes VSS support and applications that have VSS writers to help with taking snapshots. And get ready to freeze time on a regular basis.