11

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.

Improve this question

7 Answers 7

Reset to default
12

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
Improve this answer
4
  • 1
    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, 2009 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, 2009 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, 2009 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, 2013 at 19:58
10

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.

Improve this answer
5

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.

Improve this answer
4

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

Improve this answer
5
  • 1
    svnbook.red-bean.com/en/1.5/…
    – Johan
    Oct 10, 2009 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, 2009 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, 2009 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, 2011 at 0:30
  • 1
    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, 2012 at 3:23
2

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.

Improve this answer
0

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.

Improve this answer
-1

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.

Improve this answer
1
  • 1
    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, 2009 at 23:08

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .