Subversion: Repository Backup Script
A few months ago, my Windows installation became corrupt, and despite my best efforts, I had to format the hard drive. I’m the type of guy that makes a whole lot of backups, so I proceeded to format with confidence. I did, of course, make a few last minute exports just in case. Unfortunately, I didn’t realize that there was something wrong with one of the most important items on my checklist: my primary Subversion (SVN) repository. To my surprise, the backups only included the revisions that occurred prior to November 2011. While horrifying, I remembered that I at least had the live version of my working directory.
Unfortunately, I turns out I didn’t. Something strange happened to that directory – all files had disappeared from the root, and only sub-directories (and their contents) survived. It had been a while since I worked on the project, so I didn’t realize that this had happened. My automated backup procedure was therefore copying a broken directory, without my knowledge. Once my panic settled, I began to calculate exactly how much work I lost. Thanks to the remaining sub-directories, I was able to recover parts of certain changes, instead of losing them completely. In the end, I lost approximately 25 hours of work – which thankfully wasn’t much compared to the overall effort that went into the project.
Interestingly, I had previously formatted my drive in November 2011; however, when I imported my repository, it all seemed to be working fine. I was able to commit, revert, and even view the log of revisions through TortoiseSVN. Put simply, the process was so smooth that I felt confident in the procedure – and I had never seen any indication that something was wrong. While I still don’t know what caused the problem, I believe TortoiseSVN might have been related. I recall that the version changed, and I was importing my data into a new version, rather than the same. Until I figure out why exactly why this happened, I’ve taken steps to ensure I am prepared for future disaster scenarios. How have I done this?
With backups, lots of backups. I created batch file that would handle backing up my repository. It creates three types of backups every time it is executed, including:
1. A hotcopy.
This subcommand makes a makes a full “hot” backup of your repository, including all hooks, configuration files, and, of course, database files.
2. A dump.
Dump the contents of the filesystem […] in a “dump file” portable format.
While this command allows for incremental backups, and selecting only a subset of revisions – I’m using it to export all revisions, as a full backup. Excessive? Yes, it most certainly is – but I’d rather not have a repeat of the previous experience.
Due to the excessive nature of this command, the script uses 7-Zip to reduce the resulting dump size.
3. A copy of the working directory.
Just a simple xcopy; the idea is to ensure that I at least have the latest version of the code, if everything else fails.
For now, the script is working well – but I’ll likely run a few more tests to ensure that the backups are truly reliable. Since they’re created by interacting with SVN directly, rather than going through TortoiseSVN, I’m more confident that they can be trusted. In the meantime, I figured some of you might find it useful.
Also, instead of executing the script via Windows Scheduler, I decided to put it in my taskbar instead. It wasn’t as easy as I originally thought, so feel free to read the following blog post for an explanation:
You’ll need to go through and add your own file paths, naturally, including the path to the 7-Zip executable.