共用方式為

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...

 setlocal 
if NOT "%CALLBACK_SCRIPT%"=="" goto :IS_CALLBACK 
set SOURCE_VOLUME=%1 
set DESTINATION_VOLUME=%2 
set CALLBACK_SCRIPT=%~dpnx0 
set TEMP_GENERATED_SCRIPT=GeneratedVarsTempScript.cmd 
%~dp0\vshadow.exe -nw -p -script=%TEMP_GENERATED_SCRIPT% -exec=%CALLBACK_SCRIPT% %SOURCE_VOLUME% 
del /f %TEMP_GENERATED_SCRIPT% 
@goto :EOF 

 :IS_CALLBACK 
setlocal 
call %TEMP_GENERATED_SCRIPT% 
%~dp0\vshadow.exe -el=%SHADOW_ID_1%,%DESTINATION_VOLUME% 
@echo. 
@echo ******************************************* 
@echo To delete the shadow copy, run the command: 
@echo VSHADOW.EXE -ds=%SHADOW_ID_1% 
@echo ******************************************* 
@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_DATE=%BACKUP_DATE:/=.% 
@set BACKUP_TIME=%time:~0,8% 
@set BACKUP_TIME=%BACKUP_TIME::=-% 
@set BACKUP_TIME=%BACKUP_TIME: =0% 
@set UNIQUE_DIR=%BACKUP_DATE%_%BACKUP_TIME% 
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