Tag: testing

Subversion is great, but like any data repository, it must be backed up regularly. Many people have tried to implement version control without really understanding how it works, only to later discover that their backup strategy wasn’t working.

The svn backup script I use is run every night as part of a cron job. Each morning I get an email telling me if everything went ok or not. Here is a list of what I want to happen with each backup:

Dump all the data out of the repository

Name the file with a timedate stamp in the filename. Something like YYYYMMDD-HHMM will work.

gzip the file to save space

Move a copy of the file to another server using scp

Seems pretty basic, but when I’m doing a backup by hand, I like to go a step further and verify the backup by creating a new repository, filling it with the backed up data and then checking it out. This lets me verify that my backup works and that I can get my code back if necessary. So for this verification stage I want to do the following:

Pull the zipped file back down from the remote server

Unzip it.

Create a new repository

Load all of my content into the new repository

Checkout a copy of trunk into a directory

Cleanup

The following perl script accomplishes everything I need in a svn backup script. When it is run with cron, I get a short email everyday telling me that it completed. The output is intentionally terse. If I get a long email I know something went wrong, but I don’t have to wade through a bunch of logging information if everything went as planned. If you want more output, take the -q off of the Subversion commands. The emails that cron sends me look like this if nothing went wrong:

If you want to use this on Windows, you’ll need to make a few changes. First the way we generate the time and datestamp for the file name will need changed. You’ll probably want to use something other than scp and gzip as well.

Eric Wilhelm has another subversion backup method that is worth checking out as well. His method is based on dumping out a backup at every X number of commits instead of based on a specific period of time. This has some advantages particularly with large repositories that don’t change very often.