Leveraging VSS and Robocopy for Robust Backups

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