The plan is to create a shadow copy of a quite large, I/O-heavy volume. It's 350GB, containing a filesystem-based fulltext index organized in hundreds of folders and hundred-thousands of tiny files that need to be in a consistent state for a successful restore.
Currently the indexer is stopped, the backup task runs, and then the indexer is restarted. This results in the index being unavailable for hours during the backup. I'd like to make consistent backups via shadow copy, ideally without ever having to stop the indexer at all.
So, I've switched on Shadow Copy for that volume and configured it to make a snapshot once every night, to a different volume.
Now I'm a bit at a loss - how can I access the shadow copy as a whole, so that I can make a backup? I envision a read-only drive that contains the files as they were at the time of the last snapshot, but maybe things work entirely different.
OS is Windows Server 2003 SP2, backup software is CommVault Galaxy 7.0.
EDIT: Note that - in the meantime - two answers have been created that implement the necessary functionality in form of a script:
- VBScript (by myself)
- PowerShell (by John Homer)
So in the spirit of reinventing the wheel, I present to you Tomalak's excellent script (see above) but completely rewritten in Powershell!!! The main reason I did this was to evangelise the awesome powers of Powershell, but also because I despise vbscript with my entire being.
It's mostly feature to feature identical, but I did implement some things a little differently for various reasons. The debugging output is definitely more verbose.
One very important thing to note is that this version detects the OS version and bitness and calls the appropriate version of vshadow.exe. I've included a chart below to show which versions of vshadow.exe to use, where to get them, and what to name them.
Here's the usage info:
Here's the script:
Here are the vshadow.exe versions to use:
So… I have been working on a little VBScript that can:
It relies on
vshadow.exe
(documentation), part of the Volume Shadow Copy Service SDK 7.2 as available from Microsoft. I've been working with this version: "VSHADOW.EXE 2.2 - Volume Shadow Copy sample client, Copyright (C) 2005 Microsoft Corporation."Basically, it is a neat little wrapper around these four vshadow commands:
Here is its help screen:
Here some sample output:
And here is the script itself. The usual disclaimer applies: The software is provided as is, I give no warranties, use at your own risk, if something breaks the only one to blame is yourself. I have tested it quite thoroughly, though and it works fine for me. Feel free to notify me of any bugs via the comments below.
I hope this helps somebody. Feel free to use it in accordance with cc-by-sa. All I ask is that you leave the link intact that points back here.
vssadmin list shadows
to list all the available shadow copies. You'll get an output like this...Note the
Shadow Copy Volume
name for the shadow copy you want (easiest to the clipboard).Mount the Shadow Copy
On Windows 2003...
You will need to download the resource kit tools for 2003 if you don't already have it.
Enter the command...
...where
c:\shadow
is the path where you want the shadow copy to appear and\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy69
is the name you copied above. Note that you must add a backslash at the end of the shadow copy name!On Windows 2008 and up...
Enter the command...
...where
c:\shadow
is the path where you want the shadow copy to appear and\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy69
is the name you copied above. Note that you must add a backslash at the end of the shadow copy name!XCOPY
) to access the files fromc:\shadow
.You're misunderstanding how VSS works with the filesystem (how it works with databases is completely different). On the file system, VSS is used to implement the "Previous Versions" feature, which is solely used for snapshotting changes to files and folders at predefined points in time for recovery via the Previous Versions tab in clients. These changes then get merged with the data on the volume for building the recovery set. So it's dependent on the original volume still being there in order to perform the recovery, which is in other words useless for the purposes of proper backup and restore.
I think you need to step back from how you want to do this and think again about what it is you want to do.
350 GB of data is not a lot really, and I'm willing to bet that the percentage of that which gets actively used on a day to day basis is quite low. Have you considered doing nightly differential backups with full backups only on weekends? Or using scheduled DFS replication to alternative storage in order to get a "snapshot" (which is then backed up)?
Hope this is what you want:
diskshadow -s vssbackup.cfg
vssbackup.cfg:
Using the VSS API, it's possible to take a "snapshot" of the volume. Then you'd have to mount that snapshot in order to copy from it. I'm familiar with a now-dead product which used this technique to replicate data despite files being exclusively opened by other processes in the live file system. Valid questions can be raised about whether the files in the VSS snapshot are self-consistent if they're being written by apps that aren't integrated with the VSS APIs. There may be other products which offer similar capabilities.
Short answer: You can't.
Slightly longer answer: The shadow copy service can be used programatically via its API to allow backing up of open files but the service doesn't create complete snapshots of the system, only partial snapshots.