Attack of the clones: how to assign a drive letter or directory to a shadow copy

In one of my previous posts I mentioned a simple script to copy a file from a shadow copy. This allows you to access files that are opened exclusively by some application.

You won't have enough drive letters...

Here I present a similar script (let's call it CreateShadow.cmd), which creates a persistent shadow copy and assigns it a drive letter. However, this will work only in Windows Server 2003, and not in Windows XP since in XP it is not possible to expose a shadow copy to a drive letter with the VSS API. The script works in a very similar manner with the one explained in detail in my previous post. So I won't repeat again the techniques used here...

set TEMP_GENERATED_SCRIPT=GeneratedVarsTempScript.cmd
%~dp0\vshadow.exe -nw -p -script=%TEMP_GENERATED_SCRIPT% -exec=%CALLBACK_SCRIPT% %SOURCE_VOLUME%
@goto :EOF
%~dp0\vshadow.exe -el=%SHADOW_ID_1%,%DESTINATION_VOLUME%
@echo *******************************************
@echo To delete the shadow copy, run the command:
@echo *******************************************

Here is a sample usage, that creates a shadow copy of the drive X: and assigns the drive letter O: to it. I also cut & pasted a fragment of its output:

Y:\util>CreateShadow.cmd x: o:
To delete the shadow copy, run the command:
    VSHADOW.EXE -ds={c8b7c7cc-9903-4a78-b353-7b1b0d14c343}

The script also prints out the command needed to delete the shadow copy. Note that the VSHADOW.EXE tool is available in the latest VSS SDK.

Attack of the clones

You can also use the same script to assign a shadow copy to a directory. The directory must be empty, though. As an example, here is another script (named CreateShadowDir.cmd) that creates a unique directory in the root of the volume, and assigns it to the newly created shadow copy:

@set BACKUP_DATE=%date:~4%_%date:~0,3% 
@set BACKUP_TIME=%time:~0,8%
md %1\%UNIQUE_DIR%
call CreateShadow %1 %1\%UNIQUE_DIR%

This very simple script takes only one parameter (the drive letter of the shadowed volume) and creates unique directories into the root. Each directory points to its shadow copy created at that time. As an example, I ran the script multiple times on my Y: drive letter. Here is what I've got:

I expanded the latest shadow copy folder, so we can see its contents:


How about Shadow Copies for Shared Folders?

There are a number of differences between Shadow Copies for Shared Folders and regular, persistent shadow copies that were used in these scripts. First of all, SCSF is nicely integrated with the shell, and you can use the Previous Versions tab to see all the previous versions of a file. SCSF is very powerful since you have a fully integrated solution for restore from shadow copies that works remotely. Finally, SCSF is transparently integrated with clusters and it creates its own task schedules under the cover, etc. Obviously, these advantages are missing in this hand-made solution. 

On the other side, with the solution presented above you can have direct access to the contents of the shadow copies from your local drives. You don't need to go to a remote path. Second, you can have maximum 512 persistent shadow copies per volume (as opposed to maximum 64 for SCSF).

But, in the end, I feel that we barely scratched the surface in this post. There are many more things you can do - you can even put in this script in your scheduled tasks, and create shadow copies on a periodical basis. The posibilities are endless...

Comments (17)
  1. Luc Geurts says:

    GREAT stuff Adi. Gonna use this.

  2. Xavier says:

    Thank you ! I’m looking for this solution since the release of Windows Server 2003.

  3. says:

    Adi Oltean posted on his blog a guide concerning the assignment of a drive lette

  4. Dan says:

    Absolutley fantastic! No need for sql and exchange backup agents anymore!

  5. Adi Oltean says:

    Please note that if you want to make sure that Exchange and SQL databases are involved in the shadow copy then you must:

    1) Remove the "-nw" option above. -nw stands for "no writers". So, if this option is not specified, the writers present on this machine (Exchange/SQL, etc) will be involved.

    2) The database + logs must be on the same volume. If this is not the case, VSHADOW must take as parameters all the volumes involved.

    3) With the current version of the VSS writers it is not possible to perform incremental/differential backups for SQL or Exchange. For more details, please see the VSS Exchange documentation.

  6. Tom Pesik says:

    Very Nice – Might I make suggestion that would make this a truely awesome program…

    Add the functionality to mount the Shadow Copy to an existing directory.

    What I’m looking for is a tool that would allow me to the following.

    An Example of where I’m looking to do would explain what I and I think other administrators would find useful.

    Image I have a directory on my Server’s C Drive called Backups. Underneath that Directory could be 7 folders called. "1 Day Old", "2 Days Old", etc.

    Each Directory would be a mount to the apporiate Shadow Copy. This could be shared out and users could access these directories to do there restores from…

  7. Antimail says:

    A while back, I wrote a post on how to assign drive letters to shadow copies. On Windows Server 2003,…

  8. Last week, I completely virtualized my life. Well, at least my server life is all virtualized. I’d been

  9. We’ve been putting the finishing touches to our new remote data backup solution (we’ve decided on synching files over an openSSL link), and boy have we run into a lot of headaches! Backing up open files… VSS + RobocopyRobocopy is very good, though i

Comments are closed.

Skip to main content