Best way to do Subversion backups?

Question

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.

Solution 1

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.

#!/bin/bash

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

#Keeps the last 10 revisions
REPODIR="/var/repos"
BAKDIR="/data/backup/svn"
PROG="/usr/local/sbin/svn-hot-backup"
REPOLIST='repo1 repo2 repo3'

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

for repo in ${REPOLIST}
do
    # 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" ]
    then
        echo "svnbak: Hot backup on '${repo}' failed with message:"
        /bin/cat /tmp/svnbak.$$
    fi

    /bin/rm /tmp/svnbak.$$
done

exit 0

Solution 2

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.

Solution 3

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.

Solution 4

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

Solution 5

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.

View more solutions

Comments

[Johan]

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?

[Atulmaharaj]

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.

[Andrioid]

'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.

[Johan]

svnbook.red-bean.com/en/1.5/…

[Johan]

From the manual "And while there are few ways to do that, its primary strength is that it can operate remotely".

[geekyaleks]

@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/…

[geekyaleks]

+1 for mentioning svnsync - like dump and hotcopy it certainly has its uses. It can be quite handy also for local incremental backups.

[Zac Thompson]

And if the backup server is at a different location, you resolve a lot of recovery cases in a single step

[Robert Calhoun]

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!)

[tgharold]

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.