Shadow Copies for Shared Folders: Frequently Asked Questions

This feature requires the Common Internet File System (CIFS) file sharing protocol to work—even if you are working on a server that stores shadow copies locally. Therefore, to see previous versions, loop back: for example, from Start, Run, connect to \\localhost\c$. This will enable the client running on the server to access previous versions.

The client computer user interface (UI) shows only previous versions that are different from the current version. If your file hasn't changed from the previous versions that are stored on the server, then the client UI will not show any previous versions.

You can take shadow copies of any NTFS volume and store shadow copies on any NTFS volume. The volume you choose to take a snapshot of and the one used for storing the snapshot can be the same—this is actually the default configuration.

Although you can take shadow copies of any NTFS volumes and place the shadow copy storage on any NTFS volume, Shadow Copies for Shared Folders is not a backup or archival solution. Microsoft does not recommend that Shadow Copies for Shared Folders be used for DLL recovery.

Shadow copies use a copy-on-write mechanism to preserve the volume image at points in time. This incurs a runtime cost.

For lightly loaded servers, both in terms of input and output bandwidth and disk space used, the cost of maintaining shadow copies should not be noticeable. If the server is lightly loaded overall, there should be no adverse performance effect due to excessively large individual files—for example, a handful of users who store Microsoft Outlook personal file folders (.pst) on the file server.

For heavily loaded servers, you should dedicate a disk for shadow copy storage. This will eliminate extra disk head seeks caused by the copy-on-write algorithm.

It is not possible to give precise metrics on the performance overhead of shadow copies, because performance is highly dependent on workload.

There are two key points with shadow copies and security. First, access control lists (ACLs) are preserved in each shadow copy; these ACLs are used to control who is able to read files on the shadow copy.

For example, if Fred has access to a set of files at 7:00 A.M., he will have access to those files on the 7:00 A.M. shadow copy. Likewise, if he does not have permission to read those files, he won't have access to them on the shadow copy. However, when reverting a file to a shadow copy version, the ACL that already exists on the file is preserved.

Yes, with WS 2003 SP1 revert is possible except of the boot and system volumes. On clusters reverts of volumes on shared disks are blocked.

Two command-line tools enable you to administer shadow copies using scripts. "Vssadmin" lets you create shadow copies and configure settings for the shadow copy storage area. "Schtasks" lets you create and configure scheduled tasks. Using these tools you can automate every administrative task involving shadow copies.

Ever since Windows 95, Windows has provided a way for customers to undelete files: the Recycle Bin. However, two factors limit the usefulness of the Recycle Bin for knowledge workers.

First, it can only be used to recover files that have been deleted by an application that is Recycle-Bin-aware, such as Microsoft Explorer. The Recycle Bin cannot be used to recover files deleted at the command line, for example, nor can it be used to recover old versions of files that have been modified.

Second, and most important for knowledge workers: the Recycle Bin does not work for files stored on network shares.

No. Shadow Copies for Shared Folders is an NTFS feature.