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
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,
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.
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/
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
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.
Contributing Editor Bill Boswell, MCSE, is the principal of Bill Boswell Consulting, Inc. He's the author of Inside Windows Server 2003 and Learning Exchange Server 2003 both from Addison Wesley. Bill is also Redmond magazine's "Windows Insider" columnist and a speaker at MCP Magazine's TechMentor Conferences.