Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

What is the best way to do Subversion backups (on a Debian based server).

Is it to use svnadmin?

svnadmin dump /path/to/reponame > reponame.dump

Or maybe just to tar the dir where the repositories are?

tar -cvzf svn.backup.tar.gz /var/subversion/

What are the pros and cons of the above?

Thanks Johan

Update: This is a small server with only a handful of repos. So incremental backups are probably not needed, I think it is better to focus on keeping it simple.

Update: I used packs wrapper script (that in turn was a wrapper for svn-hot-backup) to do a full backup and then did a full recovery on another clean computer. However I removed that "SVN_HOTBACKUP_NUM_BACKUPS=10" part since it was not working for me.

Please note that I feel it was kind of simple and the result was very close to just tar the dir. But as Manni pointed out here to use svn-hot-backup/"svnadmin hotcopy" is a more reliable method, since tar could create corrupt backups from time to time if you are unlucky.

share|improve this question
add comment

7 Answers

up vote 10 down vote accepted

Look for the svn-hot-backup script. It should ship with subversion, and contains all the logic to do what you want, plus automagic rolling out of old backups. I have written the following wrapper script that uses svn-hot-backup to run as a nightly cronjob to backup a single server with multiple repositories, slightly modified to be generalized.


# Dumps the svn repos to a file and backs it up
# to a local directory.

#Keeps the last 10 revisions
REPOLIST='repo1 repo2 repo3'

if [ ! -x "${PROG}" ]
        echo "svnbak: Could not execute \`${PROG}\`"
        exit 1

for repo in ${REPOLIST}
    # Dump the database to a backup file
    echo "svnbak: Dumping subversion repository:  ${repo}"
    SVN_HOTBACKUP_NUM_BACKUPS=10 nice ${PROG} --archive-type=gz ${REPODIR}/${repo} ${BAKDIR}/${repo} &> /tmp/svnbak.$$

    if [ "$?" -eq "1" ]
        echo "svnbak: Hot backup on '${repo}' failed with message:"
        /bin/cat /tmp/svnbak.$$

    /bin/rm /tmp/svnbak.$$

exit 0
share|improve this answer
And since this is a wrapper for svnadmin hotcopy, I guess for recover I just copy the files in under /var/subversion/repos/? Do I need to do something else? –  Johan Aug 10 '09 at 19:38
'svnadmin verify' would also be a good addition to the script in order to verify if the repository you just copied, is in fact valid. –  Andrioid Aug 11 '09 at 8:02
@Johan - yes, just copy them. "The resultant backup is a fully functional Subversion repository, able to be dropped in as a replacement for your live repository should something go horribly wrong." from svnbook.red-bean.com/nightly/en/… –  Jonik Dec 18 '09 at 13:11
You can also use the find command to search for any repositories which have only changed within the previous N days. Just search for 'db/current' in the output of the find command. This has the advantage that you don't need to constantly update that REPOLIST variable. Also, in SVN 1.8, you will no longer need to hotcopy to an empty destination, but will be able to append to a previous hotcopy. This will likely speed up hotcopy backups by 2-3 orders of magnitude. –  tgharold Apr 9 '13 at 19:58
add comment

Have you seen the documentation on this?

Basically, you have two options:

  1. Perform incremental backups using svnadmin dump
  2. Backup your entire repository using svnadmin hotcopy

Simply making a copy of the directory is not an option because your repository might change while the copy is being made.

Whether you are into incremental or full backups depends on your amount of paranoia, the size of your repository, your needs and your infrastructure.

share|improve this answer
add comment

I'm recommending SVNBackup due to the fact that it's capable of doing incremental backups.

Why is this important? Well, if you have a large development team and you have a daily Subversion backup and your system fails 12 hours into the old backup, the entire day's work is lost.

If you do full backups (which SVN hotcopy is) many times a day you're causing unnecessary load to your repository machine, that will irritate impatient developers.

As a bonus; I also recommend Backup-PC as a backup solution. It can do incremental remote backups and is capable of saving a lot of space if you're backing up identical files on different systems.

share|improve this answer
add comment

I use svnsync to backup to an otherwise read-only repository, which is itself backed up with aged copies (day, week, month)

share|improve this answer
svnbook.red-bean.com/en/1.5/… –  Johan Oct 10 '09 at 6:09
From the manual "And while there are few ways to do that, its primary strength is that it can operate remotely". –  Johan Oct 10 '09 at 6:10
+1 for mentioning svnsync - like dump and hotcopy it certainly has its uses. It can be quite handy also for local incremental backups. –  Jonik Dec 18 '09 at 14:01
And if the backup server is at a different location, you resolve a lot of recovery cases in a single step –  Zac Thompson Jan 30 '11 at 0:30
Two things if you are going to go the svnsync route: 1) if you have a large repo start with a svnadmin hotcopy, as it is much faster and backs ups data beyond /db/revs 2) add the svnsync call to the source repo post-commit hook so that the mirror is always up to date. (But keep that out of the mirror's hooks so the mirror does't try to mirror itself!) –  Robert Calhoun Nov 20 '12 at 3:23
add comment

You can make incrementals backup with svnadmin if you wish it, you should run the hot-backup.py prior making your tar archive.

Here's a article about backing up svn repos. Anyway, reading the SVN book is a good starting point as said before.

share|improve this answer
add comment

I backup several 100GB+ svn repositories with plain old rsync. svnadmin dump and svnadmin hotcopy would take days on these repositories.

One other thing to watch is svnadmin dump doesn't backup locks and hook scripts.

share|improve this answer
add comment

Here's what I do with my repositories: use a folder backup service like Dropbox (here's a link to their Linux version). You simply make the Dropbox the root of your repository (or even above it) and it gets backed-up every time a file changes. Not only will it be available across computers, but you'll be able to access it online and have versions of it.

There are several such online backup services - most are free up to 2GB.

share|improve this answer
This is fine for small personal repos, but hardly the "best way" the poster is looking for. One problem is you can't guarantee consistency with concurrent access by multiple developers. The primary goals of a backup should be reliability and consistency, instead of online access and versions. –  Martijn Heemels Aug 10 '09 at 23:08
add comment

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.