Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

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 svn server on our lan locally its on windows. The developers use and check in/out from that. Just to be on the safer side we have took up a server from rackspace a linux one. Is it possible to do an automatic weekly synchronise from the local svn server to the remote one. The remote one will be mainly used as a remote backup but just in case if somebody wants to access then they can do as there is no static or external IP for our lan.

share|improve this question
up vote 1 down vote accepted

You can have a post-commit command updating automatically your backup repository. That way, you have real time backup.

Alternatively, you can set up a cron job to update your backup repository at periods you like.

share|improve this answer

Just to add on Veynom's answer, you could use the built-in svnsync tool to create a consistent backup of your local repository. Using tools like rsync are not recommended as you can rsync an inconsistent version which might be unusable when you really need it.

share|improve this answer
You can set up a scheduled task in Windows to run svnsync at a regular interval. You can even sync to multiple locations at different intervals. When setting up the sync though, check to make sure that all the repositories have the same guid. This makes switching to one of them easier when you need to, otherwise things get messy. Also make sure that the backup repositories are exactly that, backups. Nobody should be writing to them at all. They're to be used only when your primary repo fails. – RichieACC Jan 22 '10 at 15:54

You can easily rsync the files in one direction, but nobody must use the repository at the other end.

There would be no way of reconciling merge issues - you'd end up having two revisions with the same rev number and different content committed - it would be havoc.

Either use a distributed VC such as Bazaar, or treat the offsite backup as strictly a backup - don't write to it.

Distributed systems typically allow the developer to work on a branch hosted locally (which they can commit changes to as normal) and subsequently merge changes down/up to a "higher" repository. History of the changes is of course, maintained.

share|improve this answer
Then i guess the changes from the remote SVN will need to be added to the lan first and then the auto weekly sync will take care of the rest. – zapping Jan 22 '10 at 7:57
Using rsync on an SVN repository is a really, really bad idea. If a file were to change in the middle of a sync it could corrupt the destination repository rendering it useless. – RichieACC Jan 22 '10 at 15:51
In which case take a consistent filesystem snapshot and rsync that. I'd assumed that the backup would be taken out of hours when commits were unlikely; this is not going to work if there are lots of developers in multiple time zones working on it. – MarkR Jan 26 '10 at 7:51

There is a svn tool that will keep two svn servers in sync, sorry I can remember it’s same etc. It makes use of the same protocol as the svn client uses to talk to the server.

You are likely to find a lot more svn users on stackoverflow

share|improve this answer

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.