How to Backup Subversion Repositories

No matter how clued up you are on Subversion, disasters do happen, so it’s important to make backups of your repository data. There are two major issues to bear in mind, when creating your backups:

1) You are making a copy of a live repository – if another developer makes a change to the repository during backup, it could result in the backup missing data, or being corrupt. This can be avoided either by restricting access to the Subversion server while the backup is being performed, or performing a hot copy.
2) Unversioned revision properties can cause problems – for example, modifications to unversioned properties will not trigger any post-commit hooks you have in place.

There are two options available to Subversion developers: an incremental backup, or a full backup.

Incremental backup

An incremental backup makes a copy of all the changes that occurred since the last backup. To perform an incremental backup, you must specify a “starting_revision” revision number:

svnadmin dump {repository} -r {starting_revision} -incremental.

This creates a dump file with information about the revisions that took place between the “starting_revision” and the latest revision. This file can then be loaded into Subversion, following any data loss.

Full Backup

A full backup of a repository is essentially a copy of the entire repository, and it can be created in several ways. You could use:

svnadmin hotcopy {repository} {destination}

This command will create a local directory containing a complete copy of the repository, including hooks, configuration files and database files, while compensating for anyone who may be writing to the directory at the same time. The –clean-logs switch can optionally be used to clear up any unused Berkeley DB logs in the original repository.

Alternatively, a full dump can be performed using the ‘hot backup’ script located in the tools/backup directory:

The {repository} {destination}

Once the repository and backup locations are entered, this script backs up the repository without requiring the administrator to temporarily restrict access to the repository. The script can also be added to a program scheduler, or post-commit hooks can optionally be set to call, which will automatically backup the repository whenever a new revision is created.

Some alternative solutions for creating a full backup, include:

  • svnadmin dump – creates a dump file of the content of an entire repository. This dump file can then be loaded into a new repository (using ‘svnadmin load’) as required.
  • svnsync – creates and maintains a read-only mirror of your repository, by relaying commits that occur in one repository, and committing them into another. svnsync can be used to create a duplicate of any repository to which you have read access.

The key benefit of a full backup, is the creation of a functional Subversion repository that can be used as a drop-in replacement. On the downside, if you are maintaining multiple full backups of a repository, then disk space could be an issue, which encourages infrequent backups – a potentially risky strategy if you suffer data loss just before a scheduled backup! Of course, it’s also possible to mix both solutions, to suit your particular needs; for example, some teams perform a full dump at defined intervals, and intersperse them with frequent incremental backups. There is also the option of supplementing your backups with additional solutions, such as an archive of all the commit and property change notification emails, which can be a useful resource when disaster strikes.

0 Responses to “How to Backup Subversion Repositories”

  • No Comments

Leave a Reply