Draconis Software Blog

We maintain a lot of projects in version control, both internal stuff (like our monitoring/management app RSP, and our website), as well as client projects (some of whom have direct access). Originally, we used CVS to handle versioning, but over time, migrated to Subversion, a great replacement. Since moving to Subversion, however, we’ve had to rethink how backups are done, as one of the key differences with Subversion is how it stores information on disk. Instead of storing flat files with versioning information inside each file, it instead uses either the Berkeley database or a custom file system (called FSFS, for a filesystem within the host’s filesystem). It gives the application a lot more flexibility (directories are properly versioned as well as files), but can make backups a bit tricky. Let’s take a look at how to backup a Subversion repository (it’s not too difficult).

The trick here is dealing with a live repository: since users could be making changes to this repository at any given time, doing a recursive filesystem copy isn’t ideal. If a user were making a change while this copy was taking place, the backup could be missing data, or could simply be corrupt, which defeats the purpose of making the backup in the first place! A better way is to either freeze the Subversion server temporarily, until the backup completes, or to do a hot-copy.

Doing a “hot-copy” of the Subversion repository also comes in two flavors: incremental or full. A full backup is a complete copy of the repository, and restoring from this backup is as simple as doing a recursive directory copy. An incremental, on the other hand, stores just the changes that occurred since the last backup. A good solution for a Subversion server is a full dump on a regular basis (say, once a week), with incrementals frequently (once a day, perhaps). This gives you the flexibility to roll back to a previous version if necessary, while minimizing the disk space necessary for these backups.

Since a complete repository dump and load are generally required to upgrade your repository to the new schema, it’s very convenient to already have half of that process (the dump part) finished. Unfortunately, the creation of—and restoration from—incremental backups takes longer, as each commit is effectively replayed into either the dump file or the repository. […]

Performing a complete dump of your Subversion repository is easy, using the “svnadmin hotcopy [repository] [destination]” command. This works by going through the entire subversion repository and creating a local directory containing the complete repository. It works similar to a recursive copy of the repository directory, but it compensates for users writing to the directory at the same time.

There’s an even better way to do full dumps of a repository, however, using the hot-backup.py script created by the Subversion development team. To run it, just do “hot-backup.py [repository] [destination]”. The script implements methods for guaranteeing a valid backup copy of either a Berkeley DB or FSFS repository. In addition, you can configure it to keep a specified maximum number of backups, replacing the oldest each time it runs (take a look at the comments at the top of the file).

An incremental backup works on revision numbers, just like subversion diffs/checkouts/etc. To do an incremental dump, run: “svnadmin dump [repository] -r [starting_revision] –incremental”. This will create a dump file (that can be loaded back into subversion if necessary) with information about the revisions between the starting revision and the latest revision. According to this, the dump command “is reading revision trees from the repository just like any other “reader” process would (svn checkout, for example.) so it’s safe to run this command at any time.”

Keeping your subversion repository backed up is very important - often the code and documents stored in this repository are the backbone of many companies (ours, for instance). Disruptions in this cause all sorts of difficulties for us and our clients, and we do everything we can to minimize these. Backups are critical, and I certainly encourage you to implement these methods wherever possible.

Additional Reading:
Version Control with Subversion
Backup Subversion FSFS with rsync
Cross-platform Automated Backups