Leveraging VSS and Robocopy for Robust Backups
January 14, 2009To go with the recent network upgrades and anti-spam system, I have been working on a new way to back all this information up. The solution I’ve come up with is surprisingly simple: VSS Snapshots with Robocopy to mirror the changes. The basic idea is that the backup script creates a Volume Shadow Copy Service Snapshot, and “exposes” (mounts) the snapshot with an unused drive letter. Robocopy then mirrors the contents of this snapshot to the backup drive, allowing even files that are locked to be backed up. Add in a bit of error-checking and status emails, and we have a pretty solid backup system. I’ll run through the details below.
To create the VSS snapshot, I used a script sourced from an MSDN blog called CreateShadow, which I modified slightly to suit my purpose. I had it keep the temporary variables script, so I could use it later on (once the backup has finished) to delete the snapshot.
Once the snapshot is created and exposed, I used Robocopy with the mirror (/MIR) switch, to copy the contents to the backup drive. It just so happens that the backup drive is connected to a Samba server running on Ubuntu. This meant that I ran into a problem with timestamps whereby files were always classified as “newer”, even if they hadn’t changed at all since the last run. I fixed this by using the Fat File Times (/FFT) switch which gives a 2-second granularity on the timestamp of files, which solved the issue straight away.
The backup having completed, the script calls the temporary variables script generated by the CreateShadow script, to reinstate the snapshot ID, which is then used to remove the shadow copy cleanly.
In theory, this is an extremely efficient and robust backup system – not to mention being completely free of any licence fees. I may improve it in the future by adding functionality with multiple backup sets – at the moment I only have one day to recover from any accidental deletions – barring the previous versions.
One thing I am stuggling with at present, however, is the fact that when the backup runs under scheduled task at 3am, a number of files throw access denied errors – namely any files or directories with special characters. This is a particularly strange issue as the process works flawlessly when launched manually. I am still trying to solve the issue, but I’ll be sure to post an update if and when I find the solution.
Very nice. I’ve been looking for a way to utilize shadow copies so as to back up locked files (I have one program running on a pc at night that locks three files I’d like to back up). Presently I have to close the offending program and run the backup manually. Not a big deal as it goes quickly, but it does mean it doesn’t get done each night.
I’ll be trying this solution.
Cool, let me know how it goes. I’d be interested to know of others using similar techniques. I’ve now incorporated this in to backtrac, the backup application I have blogged about in a future post.
I am also using a similar solution based on Robocopy. I am seeing these “Access Denied” messages for a few Exchange mail files. The files have alphanumeric names of 8.3 format and have no special characters in the names. I can “type” the files just fine in their original location but when I try to “type” them inside the snapshot, I get the message. Although, there are several sibling files of similar type and size in the snapshot that I can “type”.
Did you ever happen to figure out the issue with extended characters? I’m experiencing the same issue with an access denied error being thrown when robocopy encounters filenames and folders with extended characters (ex. accented characters). Thanks for the tip about the //FFT switch tip – I was experiencing the same issue with all files being considered “newer” – using that switch fixed the issue for me as well.