Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I setup a cron for taking backup of my SVN repo( 8 GB) to another server. But some times I get errors and I feel that this is not the proper way to back an svn to a remote server.

I used the command rsync -avz myrepo.

Please suggest me a good way to do svn backup to a remote server. I cannot zip the files and transfer it daily since it's 7 GB.

Thanks

share|improve this question
    
give more detail (error messages) –  hop Apr 19 '10 at 18:01
add comment

5 Answers

Summary: rsync should be perfectly fine for backing up an svn repository, as long as you are not backing up a repository that is currently active. I suspect that you are trying to backup an active repository which is problematical.

Detail:

You don't say what errors are reported, which makes any attempt at diagnosis difficult. This is something I regularly moan about our users for - if an application gives you a specific message report that specific message to the people you are asking for diagnostics/support from, even if the message is in fact "an error occurred" or similar (as this does happen).

I'm guessing that the problems being reported are relating to files going missing (they were present during the initial scan but moved/renamed/deleted before that backup was complete), being locked, or apparently changed while rsync was reading them. You will see similar errors (or much worse: related but unreported problems) with most backup techniques if backing up a live svn service and you do not completely stop the svn service before starting the backup run.

Stopping all access to the repository while the backup run takes place may not be on option for you even if it is done in the dead of night (as you might have remote developers who work at different hours). If this is the case then there are a few options, including:

  1. Use hot-backup.py to do a full backup of the repository while it is live as described in this section of the freely available Version Control with Subversion which is generally considered recommended reading. This will not be suitable directly for your remote backup as it will result in the full repo being sent over the line each time, but you can do the backup to a temporary local area and perform the rsync (or anything else) based backup on that rather than the live repository.

  2. If you are running on Linux and use LVM for your drive partitioning you could use LVM's snapshot facility to perform a similar feat as described in option 1. See here and here for example documentation of the technique. This does mean stopping access to the SNV service for a short while, for the length of time that the snapshot takes to be created, but this is near instant so much less likely to be an issue than needing to stop it for the whole backup operation.

  3. Use incremental backups of the live repository, also mentioned in the above SVN book.

The LVM technique will be faster than hot-backup.py-then-sync, but is not available to you without a chunk of extra work and learning unless you already use and are familiar with LVM. Its advantages are that it will be almost certainly be significantly quicker, and will use less disk space (though disk space is pretty cheaply available these days). LVM snapshots do affect write performance while they are present, but the difference is unlikely to be noticeable unless your repository is very very busy and performance will return to normal anyway at the end of the backup run when you drop the snapshot.

The hot-backup.py method has the advantage of giving you a local backup too if you don't already have one - if you store the "hot copy" version on another machine you can restore this much more quickly than you can restore the remote copy if the primary machine dies in an event that doesn't affect the other (a drive controller failure, for example). It is also likely to be simpler to implement, unless you already use LVM and are familiar with it.

Incremental backups will be faster than both of these techniques, but less simple than hotcopy-then-sync and restoration after a complete disaster is potentially more complex unless you use the incremental backups to build a full repo copy at the other end (rather than just storing the incremental information). Rebuilding the repo at the other end is recommended anyway though, as this is a way of testing that your backup is in fact valid - even with the other techniques you should test your backups regularly (mantra: a backup is not a good backup unless it has been tested).

In summary, rsync should be perfectly fine for backing up an svn repository (as would many other techniques but I'm quite a fan of rsync in most use cases myself) as long as you are not backing up a repository that is currently active - you need to stop the service or backup from some form of snapshot.

share|improve this answer
    
Hi, Thanks for the detailed reply. I apologize for not posting the errors. Your assumption on error is exactly what I got. I will try the hot-backup.py and get back to you. I am so happy and thankful to get a good response like this. Thanks so much.... –  user37143 Apr 20 '10 at 11:01
    
@user37143 - did that do the job for you? –  warren Aug 17 '10 at 15:05
    
You may want to put a note that SVN 1.8 has new svnadmin freeze command: subversion.apache.org/docs/release-notes/… –  bahrep Nov 19 '13 at 13:22
add comment

How about svnsync (part of svn) to another server also running svn? As transport you could use ssh+svn.

share|improve this answer
    
Hi, I will try this too, my back server is rsync.net they got the svn+ssh setup so this would be useful I hope. –  user37143 Apr 20 '10 at 11:04
    
This works very well, plus when you are planning for disaster recovery it provide a hot standby server that is ready to be used without having to restore a backup, which for large repositories can take a very long time. –  pfranza Apr 30 '10 at 17:24
    
I think I am going with rdiff-backup --force or --retry-changed-files –  user37143 Apr 29 '11 at 21:23
add comment

Directly copying a live svn repository is never a good idea.

You could look into svnadmin dump --incremental to a folder and rsync that. This way you would only have to transfer the increments.

An alternative is svnadmin hotcopy which makes an identical copy of the live repo, and you rsync that.

share|improve this answer
    
I am much impressed about all these responses and for sure I will try out all these options and get back to you guys. Thanks so much –  user37143 Apr 20 '10 at 11:05
add comment

You can live-backup an active SVN repository, also with rsync, provided that:

  • fsfs storage backend is used
  • you copy the files in right order (the db/current file first)

There is also no point in copying contents of the transactions/ subdirectory as current transaction cannot be copied reliably.

Repository copied this way will be consistent and containing the data up to the last commit before the the db/current file was copied.

share|improve this answer
    
I am going to try rdiff-backup with --force or --retry-changed-files options. I guess this would work. –  user37143 Apr 29 '11 at 21:24
add comment

(one of the problems of hotbackup is that if you use the option to retain the least backups, all nightly backups will be synced, since they always have a new number, even if the repo didn't change.)

share|improve this answer
add comment

Your Answer

 
discard

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.