Home / server / Questions / 321419
Accepted
Sparsh Gupta
Asked: 2011-10-15 02:24:35 +0800 CST

Move and Upgrade Subversion server

  • 772

I have a very old server slow (ubuntu 9.04) which has a hell lot of other things running on it along with SubVersion.

I now plan to move subversion to a better faster server but ofcourse dont want to lose any data or history. Loads of people have access to the SVN and I dont want any changes at their end (I will also move the domain to new server).

What is the best way to do this. While moving, I also want to update the old svn version 1.5.4 to the latest stable version 1.7.0

Is there any possible issues I should be aware of before doing this? Any guide which can help me here

Thanks

svn

2 Answers

  1. Best Answer
    • Install latest subversion on target server
    • svnadmin dump|svnadmin load (maybe after create repo, can't recall) OR
    • svnadmin hotcopy

    for each repo on source server

    • move servers configuration files from source to target (users, groups, ACLs)
    • change hostname of target to source-hostname
    • open used for SVN ports
    • test commit+checkout
    • 2

  2. I would recommend first to install a SVN 1.7.0 instance on the new server. Then, you can start to copy all the information stored in your old SVN repository to the new one.

    As David Spillet explain it on this answer, rsync should be perfectly fine for backing up / copy 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.

    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 or copy an svn repository 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.

    Allways remember to test if everything it's ok by compare the information is both SVN Repositories, using relocate options, check log files, etc.

    • 2