Here are three ways to create a full mirror of a Subversion repository:
- Treat the repository like any other filesystem and recursively copy it to the mirror location.
- Use svnadmin dump and svnadmin load.
- Use svnadmin hotcopy.
There are important differences between these three strategies.
Treating the Repository as a Filesystem
You can of course:
cp -R PATH_TO_REPOS PATH_TO_MIRROR
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
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
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 Subversion.
Svnadmin 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.
svnadmin hotcopy PATH_TO_REPOS PATH_TO_MIRROR
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:
du -sh PATH_TO_REPOS PATH_TO_MIRROR
to confirm the hotcopy was running and to check on its progress.
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.SVN-Mirror-for-Live-back-up-SVN-High-Availability