Learn how to prevent data loss using VSS.
The only reason you have a network in the first place is to have a repository to store business data. As a network administrator, you want to make sure that the data users store on the network is always available and safely housed. One way that Microsoft helps you achieve this goal in Windows Server 2003 is with the new Volume Shadow Copy Service. Here's how it works.
Why do I need shadow copies?
Although I really like Windows 2000, I always thought that Microsoft dropped the ball when it came to file recovery. For example, let’s take a look at the simple act of a user deleting a file. The Recycle Bin has been around since Windows 95. However, there's no Recycle Bin for network volumes. If a file is deleted locally, the file is moved to the Recycle Bin. But if that same file is deleted from across a network, the file is gone for good.
It’s inevitable that every once in a while a user is going to accidentally delete a file. If this file happens to be on a network drive, the user is going to call you to help retrieve it. Normally, your course of action would be to mount a backup tape and restore the file. However, if the user left the file open while the backup was running, the backup most likely skipped over the file without backing it up. So you've just wasted an hour looking for a file that doesn't even exist within the backup, and the user has no way of getting the lost file back.
In a way, the above example illustrates another problem with Windows 2000 file management. Suppose a user created a file yesterday, and the file was successfully backed up last night. Today, the user made two dozen changes to the file, saving between each change. Now imagine that the last five changes were incorrect. The user would have no way of going back five versions to retrieve the last correct version of the file. The user has only two versions available: the current (incorrect) version and the version that was backed up last night, which is now significantly outdated.
For years, administrators have either just accepted these limitations or have invested in expensive third-party software to help them overcome some of the limitations. However, Windows Server 2003 solves all of these problems with the Volume Shadow Copy Service (VSS).
VSS makes automated backups of network volumes. These backups are different from your nightly backups. VSS backups are online, which means they're always available without your ever having to mount a tape. At the same time, though, they can never take the place of a traditional backup because they exist on the same physical hard drive as the volume they are backing up. This means that if the drive were to go bad, you would lose the data and the VSS backup that goes along with it.
Instead of thinking of a VSS backup as a true backup, think of it as a snapshot in time. A couple of times a day, VSS takes a snapshot of all the data that’s on the drive. This way, if users need to recover a previous version of a specific file, they can do so without having to get you to restore the file from backup tape.
VSS helps to protect against the problems caused by users leaving files open during nightly backups. If a user had a file open when the backup ran, previous versions of Windows Backup would have just skipped the file rather than back it up. In Windows Server 2003, however, Backup pulls the most recent version of the file from VSS and backs it up. Of course, none of the changes that have been made to the file since the most recent shadow copy backup will be included in the backup, but then again that isn’t really the point. The point is that rather than just skipping the file, you're backing up a reasonably current version of it even though the file is being held open.
Before I show you how to implement the service, I want to discuss some of the limitations you'll run into. As I briefly alluded to earlier, VSS is not a substitute for a normal backup. Instead, it's a convenience feature. If a user needs a file restored quickly, VSS is perfect for the job. However, there are a few restore operations that VSS simply isn't suited for.
The general rule of thumb is that if Windows is not functional, then VSS can’t be used to perform a restoration. For example, if a system’s registry became corrupt, you wouldn’t be able to restore it with a shadow copy because Windows can’t run without a valid registry. Likewise, if a hard disk failed, you wouldn’t want the shadow copy to be your only backup because, by default, the shadow copy backup exists on the same partition that contains the original data. Therefore, if a hard drive failed, not only is the data gone, but the shadow copy is gone as well.
Another limit you need to be aware of is the amount of data that can be stored by VSS. As I explained earlier, the shadow copy of the data exists on the same partition as the data itself. As the hard disk accumulates more and more data, there's less and less available space for shadow copy data. Windows won't hesitate to delete shadow copies to make room for more data.
Even if you had an infinite amount of hard disk space, VSS does not store an unlimited number of backups. At a maximum, Windows will retain the last 64 versions of a file. After this limit is surpassed, older versions of the file are deleted to make room for newer versions.
You should also note that shadow copies are read-only because one of the service's main jobs is to protect older versions of files. If it were possible to modify older versions, then they wouldn't be truly protected. If you find yourself needing to restore a previous version of a file and make changes to it, you must copy the shadow copy to an alternate location and then make the changes to the copy rather than trying to change the actual shadow copy.
Although shadow copiers of files are always flagged as read-only, shadow copies retain the original permissions set on the file. Therefore, if you restored a file that had been backed up by a shadow copy, the restored file would have all of the same permissions as the original (with the exception of the read-only flag). If you plan on modifying the file, you must copy it to an alternate location. The minute you move the shadow copy, it inherits the NTFS permissions of its destination folder and combines those with the existing permissions.
One last limitation that you need to know about is that VSS can be enabled or disabled only at the volume level. It cannot be applied individually to files and folders.
To enable VSS, open the Disk Management console by entering the DISKMGMT.MSC command at the Run prompt. When the Disk Management console opens, right-click on the volume for which you want to enable shadow copies and select the Properties command from the resulting shortcut menu. This will display the disk’s properties sheet. Now, select the Shadow Copies tab, as shown in Figure A.
|The disk’s properties sheet contains a Shadow Copies tab.|
If you select a volume’s properties sheet and there is no Shadow Copies tab, it's because the hard disk is configured to act as a basic disk rather than a dynamic disk. You can easily convert your hard disk to a dynamic disk by right-clicking on it and selecting the Convert to Dynamic Disk command from the shortcut menu. However, converting might not be a good idea if you have a dual boot server. Also note that converting to an alternate disk type requires you to reboot the server.
As you can see, there really isn't a lot to the Shadow Copies tab, and enabling VSS is as simple as selecting a volume and clicking the Enable button. Before you click the Enable button, though, I recommend taking some time to customize the various shadow copy options. You can do this by clicking the Settings button. When you do, you’ll see the Settings dialog box, shown in Figure B.
|The Settings dialog box allows you to configure the way the shadow copies behave.|
The first setting you must configure is the storage location. The default setting tells Windows to place the shadow copies onto the same volume as the original files. While you can certainly use the default options, this may not be a good idea for a couple of reasons. First, if the hard disk goes bad or the volume gets corrupted, you lose your shadow copies too. This may not sound like a big deal if you're making a nightly tape backup, but think about it. During the day, the shadow copy will usually be more current than your nightly backup. Therefore, if you have to restore a backup tape from the night before, users may lose a full day's worth of work. If you're able to restore the shadow copies, users may lose only a few minutes' or a couple of hours' worth of work (depending on the backup schedule and the time of day when the crash occurs). It’s also good to be able to recover shadow copies after a crash because doing so allows you to maintain multiple versions of the files in the shared folders.
Another reason for moving the shadow copies to a different location is that placing the shadow copies on a volume that’s already very busy with user requests can degrade performance. Regardless of where you choose to store the shadow copies, there is one very important point to remember: If you move the shadow copy location once shadow copies have already been enabled for the volume, all of the existing shadow copies for that volume will be lost. For example, if you have shadow copies enabled for drive F, and you decide that you want to move the copies to drive Q, then all of the shadow copies that currently exist for drive F will be lost during the move.
The next setting you can configure is the maximum shadow copy size. By default, shadow copies are given 10 percent of the volume space. I recommend giving this some serious thought before simply accepting the defaults. Remember that you want to set aside enough disk space, but not too much.
When I say that you must set aside enough disk space, I'm talking about the minimum shadow copy size enforced by Windows and the minimum amount of disk space you can use for practical results. Windows requires that you use at least 100 MB of disk space for shadow copies. At the same time, though, 100 MB is probably nowhere near enough space for most applications. In fact, that may not even be enough space for a single shadow copy of a file.
To figure out how much space you’ll really need, you must determine how much space is being used by shared folders on the volume in question, how many shadow copies you want to use, and how much you expect the data in the shared folders to grow in the foreseeable future.
For example, I have a production server on my network that stores everything I've ever written, all of the financial records for my various businesses, the source code for my Web site, and a lot of other material. All of this data takes up about 3 GB. Therefore, I know that I must set aside at least 3 GB of space if I want to be able to successfully use a shadow copy on that volume.
If I wanted to use the maximum number of 64 shadow copies so I could retain lots of old versions of my documents, I could multiply 64 shadow copies by 3 GB. This means that I'd need 192 GB on that volume for shadow copies. Of course, this accommodates only my current needs. On average, I consume about 1 GB per year on that volume. Given that Microsoft comes out with new server operating systems about every three years, I can predict how much space I'll need if I continue to write the same amount of material. By the time I’m ready to upgrade server operating systems around 2007, I'll probably have 6 GB of data online. Therefore, I'd try to set aside 384 GB in shadow copy space.
Although you don't want to use too little disk space, you don't want to use too much either. I estimated that 384 GB of disk space would hold me for the next three years and allow me to have 64 shadow copies available at a time. However, 384 GB is almost half a terabyte of disk space, and that server holds my personal data only. Can you imagine how much disk space you might need to configure shadow copies for a server that handles 1,000 users who are doing nothing but creating documents day in and day out? Although my estimate was based on a single volume, my network actually has dozens of server volumes—that one just happens to be the most important. As you can see, you can quickly burn through a whole lot of disk space if you try to use shadow copies to their full potential.
In spite of the hefty disk space requirements, there are some environments where you might want to use shadow copies to their full potential. For example, medical offices require very precise patient records to be kept. In such an environment, it could be beneficial to keep the last 64 versions of a patient's medical records available in case someone tries to file a malpractice suit. Of course, full-blown archival applications are better suited to this type of work.
The final element you might want to configure is the shadow copy schedule. You can do this by clicking the Schedule button. By default, Windows is configured to create a shadow copy of the data every weekday at 7:00 A.M. and at noon. I’m assuming the idea behind this schedule is that you can create the shadow copy before everyone shows up in the morning and while everyone is at lunch.
I recommend modifying the shadow copy schedule to meet your needs. If everyone in the office shows up for work at 8:00 or 9:00, there's little reason to create a 7:00 A.M. shadow copy. The shadow copy would be backing up the same data that you already have on tape from the night before. Instead, you might create a shadow copy at 11:00, 2:00, and 5:00. That way, you'd have data restore points from throughout the day.
There are other considerations to keep in mind when setting up a schedule. The primary factor is performance. If the volume you're shadow copying is heavily used, there’s a good chance that creating a shadow copy during business hours will slow the server to a crawl. Therefore, I recommend manually creating a shadow copy to see what impact it has before setting up a schedule. You can manually create a shadow copy by clicking the Create Now button shown in Figure A.
Another factor to consider is the amount of time it takes to create a shadow copy. For example, I suggested making a shadow copy at 11:00, 2:00, and 5:00. However, if it takes more than three hours to create a shadow copy, it will be time for the next shadow copy to begin before the last one has even finished.
Finally, decide how many days' worth of shadow copies you want to have available in your archives. For example, if your server is storing 64 shadow copies and you're creating shadow copies three times a day, you have only 21 days' worth of shadow copies available.
So far, I've shown you how to set up VSS on the server, but you must also do some configuration on the client end before clients will be able to restore shadow copies. To install the client software, you must make the server’s %SYSTEMROOT%\SYSTEM32\CLIENTS\TWCLIENT folder accessible to users who should have access to shadow copies of their files. Once you’ve done so, have clients run the TWCLI32.MSI file found in the server’s %SYSTEMROOT%\SYSTEM32\CLIENTS\TWCLIENT\X86 subfolder. The installation process is extremely simple and is automated for the most part.
Once the client component is installed, clients have access to previous versions of the files as long as they're passing through a network share point to access those files. Obviously, users should not attempt to get to their files directly from the server console. But if they did, the shadow copies of their files would be inaccessible because users would be attempting to access the files through an absolute path—C: rather than through a UNC-based network share point (\\servername\sharename).
To access a previous version of a file, right-click the file and select the Properties command from the resulting shortcut menu. In the file’s properties sheet, select the Previous Versions tab to see which versions are available, as shown in Figure C.
|The Previous Versions tab allows users to revert to previous file versions.|
As you've seen, VSS can be extremely beneficial since it can store up to 64 versions of each document. Unfortunately, VSS is a convenience feature, not a full-fledged document archival feature. If your company needs to be able to keep multiple versions of each document, don't rely on VSS. Remember that archived versions can be deleted without warning if Windows decides that it needs the disk space. If you're looking for a more stable file archiving solution, I recommend checking out Microsoft’s SharePoint Portal Server or its little brother, SharePoint Services for Windows Server 2003.