Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top
CentOS 5.3
subversion 1.4.2

I am looking for a strategy to backup our subversion repositories. We have about 30 repositories in a directory like this:


Our requirement is to do daily backups running at 12am.

However, I am not sure about the subversion repositories in order to set things up for rsync.

Do I need to do a hotcopy or svn dump, syn sync, etc? Or do I just copy the repositories as they are?

I have never used rsync before so we will be backing up our repositories to a remote server. Do I need rsync daemon running on both machines?

Can rsync recursively backup all the repositories under the directory repos?

Many thanks for any advice,

share|improve this question
svn database type? fsfs? bdb? Are you running LVM? – Hubert Kario Oct 7 '10 at 10:55
Database is fsfs. I am not running LVM. Thanks – ant2009 Oct 7 '10 at 13:34
up vote 3 down vote accepted

You need to make sure that the repository is not changed at all (i.e. new check-ins) while the backup is taking place. This can be arranged a number of ways but probably the easiest is to use hotcopy to make a new copy of the repository (the process respects subversions versioning/locking system so you get a consistent point-in-time copy of the repository even if people are actively using it) then backing that copy up to the remote site using rsync.

rsync supports syncing full directory structures, and if the remote end is contactable via SSH (or similar) you don't need to be running the rsync in daemon mode (it just needs to be installed so it can be called via ssh).

The rsync command you need is probably of the form:

rsync -a /path/to/hotcopy/copy

This connects to via SSH as user, starts an rsync process, and arranges the transfer with it then closes it before closing the SSH session. The -a option (short for --archive) includes a lot of options including the one that causes rsync to operate recursively over a whole directory structure. You might want to add the --compress option too as no doubt your repository's contents will compress well saving you some bandwidth. See the rsync man page for more details.

share|improve this answer

My favoured way to backup svn repos is to use svnsync. its incremental so you won't lose data between your 12am backups. Its quick (enough) as it replays commits to the live repo onto a backup one. The disadvantage is that you have to set a sync up for each repo - you can't (unlike rsync) copy the entire directory structure. It also doesn't copy your hooks and other settings, so you'll need to copy them separately. I run it hourly for my repos, but I have tried running it in a post_commit hook (which works too) to ensure all commits are backed up all the time.

Its easy to set up though, create a blank repo to hold each backup and set the revprop change hook to allow revprop changes (so you can sync them too)

svnadmin create c:\backup_xyz
echo exit /b 0 > hooks/pre-revprop-change

then initialise the sync (run svnsync on the backup server) to pull changes:

svnsync init svn://svr/svn/remote_live_repo  file:///c:/local_backup_repo

or if you want to push to the remote server

svnsync init file:///c:/local_live_repo  svn://svr/svn/remote_backup_repo

then start the sync

svnsync sync file:///c:/local_backup_repo

easy! If it ever crashes out and you have to restart an nterrupted sync, just delete the property that says what the current syncing revision is and retry:

svn propdel svn:sync-lock --revprop -r 0 file:///c:/local_backup_repo

You can use svnadmin hotcopy to make backups, or rsync - but if you use rsync you should stop the repo server while you perform the backup.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.