Windows Server Hacks: Backup and Recovery

Work with Shadow Copies

Shadow copies are a new feature of Windows Server 2003 that lets you save point-in-time copies of your files—an excellent complement (but not a replacement) for your regular backup plan.

Windows Server 2003 includes a new feature called the Volume Shadow Copy Service (VSS) that can save administrators time when users are concerned. When shadow copies are enabled on an NTFS volume, Windows makes point-in-time shadow copies (or snapshots) of files on the volume at predefined intervals. Users can then access these shadow copies to recover accidentally deleted or overwritten files without requiring the administrator to intervene to restore these files from backup media. This feature also allows users to compare current versions of documents with previous versions, to check for differences without requiring that users actually save separate versions of these documents along the way. Either way, administrators are freed from the hassle of responding to users' requests for restoring their files from backups, and any time gained nowadays for the harried network administrator is an asset.

On the other hand, implementing shadow copies on file servers is not a replacement for a regular backup program, because shadow copies are stored on disk in the same way the original files are stored. So, if a disk goes on your file server, it could mean that both the original files and shadow copies might be gone, depending on how you've configured your file server. Also, shadow copies are read-only copies and can't be edited directly. In fact, a shadow copy of a file isn't really a file at all; it's a block-by-block record of changes that were made to the file since the last shadow copy was made. So, to protect your business from data loss, be sure to combine shadow copies with regular tape backups using the Windows Backup utility or some third-party product.

Implementing Shadow Copies

Like most successful IT initiatives, implementing shadow copies starts with good planning. Disk space considerations are a good place to start, since shadow copies require a minimum of 100 MB of free space for each volume on which you enable them. That minimum can also grow quickly, depending on how actively users modify their files and how aggressively you've scheduled shadow copies to occur. In fact, even if you only have a few kilobytes of files on your file server, the first time a shadow copy of a volume is made, it takes up the full 100 MB space allocated to this feature.

By default, the maximum amount of disk space used for shadowing a volume is 10% of the size of that volume. So, if you shadow a 20 GB data volume on your file server, up to 2 GB of space will be needed to store the shadow copies of files on this volume. However, if the need arises, you can increase this maximum at any time. This is important, because if the maximum is reached, then shadow copies start dropping the oldest versions to make room for the new.

TIP: If this 10% limit reminds you of the default settings for Recycle Bin, you're right. Shadow copies are designed to function as a kind of network-enabled recycle bin for your users. In other words, if you enable shadow copies on a volume, any shared folders on the volume automatically save point-in-time versions of documents in these shares. Actually, it would be nice if the Recycle Bin automatically did that locally as well. (Perhaps in Longhorn?)

One planning option to consider seriously is to store shadow copies on a different volume than the one where users' data files reside, preferably on a different physical drive as well. That way, you can plan separate disk-space needs for original files and their copies. However, many administrators don't realize that if you discover later that your shadow volume is insufficient and you want to move the shadow copies to a different volume, doing so causes you to lose all shadow copies of user files. Backing up the shadow volume in this case and restoring it to the new volume won't work, because VSS can't be configured manually to find its copies in a moved location. To work around this problem, you can store your shadow copies on a dynamic volume, which you can extend later by adding free disk space on the same drive or another drive.

Also remember that shadow copies are enabled on a per-volume basis. So, when you enable this feature on a data volume, all shared folders on that volume will have shadow copies created for files within them. This is an important issue that is usually not considered in the planning stage. In fact, this issue should actually be considered before you even set up your file server in the first place. In other words, to implement shadow copies effectively, you need to ensure that shared folders on your file server are grouped together appropriately onto separate volumes, according to the level of user activity for those shares. Group together shares within which users frequently modify files according to how often they modify them: high-activity shares on one volume, medium activity on another, low activity on a third. This will help you plan separate shadow-copy schedules for each volume: frequent copies for high-activity volumes and infrequent copies for low-activity volumes. If you are planning on upgrading your Windows 2000 file servers to Windows Server 2003, consider reorganizing the volumes and shares on your servers as part of the upgrade process.

Configuring shadow copies is basically a three-step process: configure it on the server, configure it on the client, and educate users how to use it. The last step is often forgotten from the IT perspective, because it's not strictly in the "techie" realm of things, but it's just as important as the other two steps. For increased security, shadow copies are disabled on all NTFS volumes until you enable them on the server. If you're logged on locally, the easiest way to enable shadow copies is to right-click on any volume, select Properties, switch to the Shadow Copies tab, select the volume on which you want to enable shadow copies, and click Enable (see Figure 10-7).

Actually, before you enable this feature on a volume, it's a good idea to first review the default settings for shadow copies by clicking on the Settings button shown in Figure 10-7. The default settings store the shadow copies on the same volume as the one you are enabling, use up to 10% of the volume to store copies, and make new shadow copies of files every weekday (Monday through Friday) at 7 a.m. and noon. The rationale behind the schedule is to save copies before users arrive at work (when they open their files) and around lunchtime (when they are halfway through their workday).

You can create almost any schedule you want for when shadow copies should occur, but avoid scheduling it to occur too often (e.g., once an hour), due to the excessive load it will place on your server. When planning your schedule, also remember that shadow copies will save a maximum of 64 different versions of a file before deleting older versions to make room for new versions. So, if you leave the default twice-a-day schedule in place, users will be able to restore a version up to 32 days old. Anything older than that you'll have to restore from backup for them.

Be sure to clearly communicate to users your schedule of when shadow copies will be made so that they don't rely on this feature excessively. Users should still consider themselves responsible for making versioned copies of files they work on and should view shadow copies only as a tool of last resort—just in case they accidentally delete a file or overwrite it—rather than something they'll use to save versions of their work. As administrator, you can also force a shadow copy to occur at any time; just select the volume and click the Create Now button shown in Figure 10-7. This can be a useful feature if there are certain times when user activity is high, such as year-end finalization of budgets. Instead of modifying your schedule, you could manually create an extra shadow copy or two during the days just before the deadline.

You might be wondering where shadow copies are stored on a volume. If you create a new 5,000 MB data volume E:, enable shadow copies on the volume, and click Create Now to generate shadow copies immediately (even though there are not files yet on your volume), then, when you select the E: drive in My Computer, you should see around 4,900 MB of free space. In other words, shadow copies immediately use the minimum 100 MB allocated to it the first time they operate. But your drive is still empty when you open it in Windows Explorer. If you use Tools→Folder Options→View to show hidden files and unhide hidden system files, you'll see a folder named System Volume Information that has System and Hidden attributes enabled; that's where your shadow copies are all stored. This volume is accessible only to the built-in system account on your server, not to administrators.

Once you've reviewed and modified the shadow-copy settings for a volume and enabled shadow copies on that volume, your server begins to save shadow copies of all files stored on the volume. That includes all files, not just ones in shared folders on the volume. In other words, even if you modify a file locally on the volume and the file is stored in a folder that isn't shared, a shadow copy will still be created for that file. That way, if you later decide to share the folder for others to access, a history of versions of files in the folder will be displayed.

In a network environment, where it's not convenient to log on locally to your file server, you can still enable shadow copies by using Computer Management. Just open Computer Management on your administrator workstation, connect to the remote file server, right-click on the Shared Folders node, and select All Tasks→Configure Shadow Copies.

TIP: This works only from workstations running Windows XP Professional with Service Pack 1 and the Windows Server 2003 Administration Tools Pack or, alternatively, from another machine that is running Windows Server 2003.

Once shadow copies are enabled on the server, they still have to be enabled on the users' client computers. By default, only Windows Server 2003 has shadow-copy functionality built right into it; all previous versions of Windows require that special client software be installed on them before users can use this feature to access previous versions of files. If your desktop computers are running Windows XP Professional (the desktop operating system that most closely integrates with Windows Server 2003 on the back end), you can install shadow client software on them easily. Just share the %Systemroot%\System32\clients\twclient\x86 folder on your server, and then instruct users to connect to this share and double-click on twcli32.msi to run the Windows Installer File. Alternatively, you could use the software-installation feature of Group Policy to deploy this feature automatically to all desktop machines in an organizational unit, domain, or site. You could even email the installer file to your users, along with instructions on how to install and use it.

Using Shadow Copies

Let's say you've enabled shadow copies on volume E: on a Windows Server 2003 file server, and this volume is used to store users' files in a series of shares named Budgets, Projects, and so on. How can a user access previous versions of her files in these shares, and what actions can she perform on them? Say a user uses Start→Run→\\servername\budgets, where servername is the name of the file server where the Budgets share is located. This will open a window on the user's desktop, displaying all files stored in that share.

Users can right-click on a particular file in that share, select Properties, and switch to the Previous Versions tab shown in Figure 10-8. If this tab is missing, then the user's computer doesn't have the shadow-copy client software installed.

All previous point-in-time versions of the selected file are displayed in this tab (if no previous versions are displayed, the file hasn't been modified since it was created). The View, Copy, and Restore buttons enable the user to perform different tasks with these versions. For example, to view the contents of a previous version, click View. This is helpful when you're not sure which previous version is the one in which you wrote that lovely paragraph but later deleted in a fit of writer's despair. Once you've found the previous version of the file you want, you could save it to your My Documents folder and give it a descriptive name.

Alternatively, if you already know which version you're interested in (such as the most recent previous version) you could click Copy to copy that version to a different location. If you're really confident, you could click Restore to overwrite the current version of the file (the one you're working with as a user) with the previous version specified.

If you're not even sure which file had that wonderful paragraph you wrote, but you know it's in the Budgets share, you could right-click on an empty area within the open share window, select Properties, and switch to the Previous Versions tab of the share itself. This displays all previous shadow copies made of that share and lets you view previous versions of individual files within the share, copy a previous version of all files in the share to another location, or roll back all files in the share to the specified previous version.

The bottom line is, when educating users on how to use shadow copies, tell them to ignore the Restore button and always use View and Copy instead. One user carelessly restoring an entire shared folder to its previous version could result in lost work and its accompanying frustration for other users who have access to the same share. Of course, if users work only with their own files but store them in the same share, this might not be an issue, depending on how NTFS permissions are configured on the shared folder. But if users have collaborative access to a document, problems can result when using shadow copies. Of course, such problems can result even without shadow copies functionality.

Here's something else to consider that is often forgotten: NTFS permissions change differently, depending on whether you copy a file or move it. So, in the case of shadow copies, if you restore a previous version of a file, it overwrites the original file in its original location but maintains the same NTFS permissions as the original file. But if you copy a previous version of a file to a different location on your drive, the copy inherits the permissions of the folder you copy it to.

Traps

In addition to poor planning and scheduling, resulting in insufficient disk space, there are a few other things you need to watch out for when implementing shadow copies. The first thing has to do with the block-based mechanism by which the VSS makes copies of changes made to files. If the filesystem cluster size is smaller than this block size, some of your shadow copies might disappear when you defragment your volume using the built-in Disk Defragmenter node in Computer Management. To prevent this from happening, always ensure that volumes on which shadow copies are stored have cluster sizes of 16 KB or greater. By default, on Windows Server 2003, any volumes larger than 2 GB will have a cluster size of only 4 KB, which is insufficient.

To solve this problem, when you format the volume, specify an allocation unit size of 16 KB instead using either Disk Management or the /a switch with the format command. On large volumes, you could use even higher cluster sizes of 32 or 64 KB. But if the volume will be used to store many small files, this can result in much wasted space on your drive. So, 16 KB is probably the optimal solution in most cases.

If you upgraded your server from Windows NT 4.0 Server and the volume was converted from FAT to NTFS by using the convert command, you're out of luck. Because convert always uses an allocation unit size of 512 bytes to optimally align with FAT filesystem boundaries, don't use a converted volume for storing shadow copies on a server. However, if your machine was previously running Windows 2000 Server, you might be in luck, because that platform allowed you to format FAT volumes with larger cluster sizes.

Here are some other things to watch for: