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

I have a huge subversion repository and want to create a slave repository for live backup purposes.

However I do not want to replay the revision history into the slave because this will literally take days due to the size of my repository. I already have the usual infrastructure in place such as hook scripts and two web servers that serve the master and the soon to be slave repository.

How do I do this?

share|improve this question
up vote 2 down vote accepted

Subversion has the ability to support one or more slave repositories which you can cynchronise using hook scripts or you could use a cron job that runs svnsync for you. When you create a slave repository the procedure involves, amongst other things, creating a repository with only revision 0 and then you replay all the commits from the master to that slave. Depending on your bandwidth and the size of the repository this can take a very long time.

There is a quicker way to do this. It involves copying the current master to the new location and then perform some tricks to turn it into a slave. I'll leave the actual implementation of automatic or live synchronisation up to you.

In this answer we assume:

  • The repository's name is "repo"
  • The master server is reachable through the filesystem
  • The slave server is reachable at

I have used this method many times with a 20+ GB subversion repository, I also successfully recovered a broken master a few times by copying a slave, created in this way, back to the master.

We will copy the master and transfer it to the remote server, in the directory where your repository resides do:

svnadmin hotcopy repo repo_bak
tar -cjf repo_bak

The hotcopy command allows you to safely copy a repository that's currently in use and keep it consistent.

Unpack the tarball on the slave server and all that...

We assume that on the slave server you are running a web server that is configured to serve the repository in the usual way. In addition it needs hooks scripts which prevent any account except the synchronisation account to commit, for obvious reasons, we want the repositories to be exactly the same. Again how to do that is outside the scope of this answer.

We run all the below commands on the master repository.

Bind the master repository to the slave repository:

svn propset svn:sync-from-url --revprop -r 0 file:///example/path/repo

Find out the revision of the slave repository, this will also give you the UUID which you will need below:

svn info

Use the revision you found above in the following command:

svn propset svn:sync-last-merged-rev --revprop -r 0 REVISION_OF_SLAVE

We need to use the UUID we found above to add to the master repository:

svn propset svn:sync-from-uuid --revprop -r 0 UUID_OF_SLAVE

If everything went well you can now successfully synchronise the slave:

svnsync sync
share|improve this answer
-1 Errors and inaccuracies. Not usable and unsafe. – Lazy Badger Mar 22 '12 at 9:50
It's a working method and I have done it many times with a 20+ GB repository. Besides that your comment is not constructive, you don't point out the error(s) you apparently detected. – aseq Mar 22 '12 at 19:07
@LazyBadger Perhaps you could clarify where you think this answer is wrong?? – Chris S Mar 22 '12 at 19:08
@ChrisS - at least all propset from "We run all the below commands on the master repository. Bind the master repository to the slave repository" because correct binding is on slave to master (as Paul wrote "...sets several revision properties on the $TOREPO" - my 2-nd URL) and as logic tells me. Also missing mandatory part of hooks. – Lazy Badger Mar 22 '12 at 19:20
I actually say in my answer that you need hook scripts, however that is not part of this answer or question (questioner says he has all that in place :-). And the error you found is a semantic error, not an actual error in procedure. All commands are run on the master, as I state. – aseq Mar 22 '12 at 19:30

The Right Places to read about running Subversion's repository-replication over svnsync:

  • svnsync.txt in Subversion repo (starting point)
  • using svnsync in blog of Paul Querna (if troubles appear in some moment)

PS - you must to have full mirror of master-repo on slave, but you can try start not from empty repo, but cloned over svnadmin dump to some point (not hotcopy!)

share|improve this answer
I think using svnadmin hocopy is better suited, because it makes an exact full copy of the repository while it is being used and while it's getting updates, safely. I don't think svnadmin dump will do that as well. The idea is to get a complete exact copy to use as a slave, not to get a dump to store away as backup, neither to get a dump and import it into an existing fresh repository. Besides I think the dump and load procedures will take MUCH longer. With hotcopy the time it takes is mostly transferring the tarball. – aseq Mar 22 '12 at 19:20
With hotcopy the time is mostly used in transferring the tarball AND of course copying the repository in the first place. – aseq Mar 22 '12 at 19:50

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.