SVN Mirror for Live back-up & SVN High Availability

Here are three ways to create a full mirror of a Subversion repository:

  1. Treat the repository like any other filesystem and recursively copy it to the mirror location.
  2. Use svnadmin dump and svnadmin load.
  3. Use svnadmin hotcopy.

There are important differences between these three strategies.

Treating the Repository as a Filesystem

You can of course:


This is a bad idea if the repository is in use — you’re copying a moving target — so you’ll have to take down the Subversion server while making the mirror. If you’re prepared to accept this downtime, netcat, nc, combined with tar is a neat way to recursively copy a directory across a network connection using TCP/IP.

# On the destination "mirror" machine
nc -l -p 2345 | tar xv
# On the source machine
tar c PATH_TO_REPOS > /dev/tcp/DOTTED.IP.OF.MIRROR/2345

Here, 2345 has been chosen as a suitable port for the data transfer.

Using Svnadmin Dump and Load

Perhaps the most obvious way to mirror a Subversion repository is to combine svnadmin dump with svadmin load.

svnadmin dump PATH_TO_REPOS | svnadmin load PATH_TO_MIRROR

Run on its own, svnadmin dump is designed to create a portable repository dump. The resulting dumpfile can be loaded into a new Subversion repository — even if the new repository is using a different database backend, or even a different revision of SubversionSvnadmin dump will happily run on a live repository (no need to take the server down).

In short, combining svnadmin dump with svnadmin load is probably more powerful than we need if we just want to mirror our repository to a new location. Svnadmin dump — on its own — is the best way to fully backup a repository, since the dumpfile it creates is portable (as described above). If we replicate a repository by piping svnadmin dump to svnadmin load, we lose the dumpfile in the pipeline and do far more work than we need to.

Actually, it’s the computer which does the work — we just type a command and let it run. As a rough guideline, I have worked on a repository which occupies about 10Gb on disk, contains ~50K files and maybe a hundred branches. To dump and load this repository takes about 4 hours. A recursive copy completes in a few minutes.

One more point: svnadmin dump does not dump your repository configuration files and hook scripts. If your backup strategy is based around these commands, you will need separate arrangements for backing up hook scripts and configuration files.

Using Svnadmin Hotcopy

The third option combines the best features of the previous two. Using svnadmin hotcopy doesn’t require any server downtime, completes in minutes, and replicates server configuration and hook scripts.


The command is disconcertingly silent — no indication of progress, no verbose option. As is usual in UNIX-world, however, no news is good news. I just ran:


to confirm the hotcopy was running and to check on its progress.


File CopyYesYesQuickest

Checking the mirror

Svnadmin provides another option, svnadmin verify to check a repository. This basically iterates through all revisions in the repository by internally dumping all revisions and discarding the output — so it takes a while.

svnadmin verify PATH_TO_MIRROR


Software developers don’t feel secure unless their source repository is safely backed up – or at least they shouldn’t – and they are reluctant to suffer repository downtime or excessive maintenance overheads. Live Subversion repositories can be mirrored quickly and safely using a simple command. With a little extra effort, this command can be scheduled to run automatically, every week, say.

As a next step, by using the Subversion post-commit hook every check-in to the repository can instantly and incrementally be copied to the repository mirror. I’ll provide details of how to do this in my next post.


Rajesh Kumar
Follow me
Notify of
Inline Feedbacks
View all comments
Would love your thoughts, please comment.x