On Wed, Oct 26, 2011 at 7:23 AM, Neil Bird <n...@jibbyjobby.co.uk> wrote: > > Whilst suffering a subversion server outage, it's made me wonder: we > currently produce nightly backups of our repos via 'hotcopy' from the > server's local drive to a network store. > > If the server were to die, would I be able to take those copies and place > them under a server on a new box *with a different OS*? Or would I have to > create a temporary server with the original OS, copy them to that, and > svndump them and import them elsewhere? > > In this case, it's a Solaris server, dunno what processor [I'll check when > it's back up!], and I'd consider moving it to an x86 Linux server.
Never do this by direct filesystem replication. "hotcopy" is somewhat better. Issues with transfer via hotcopy include the fact that hotcopy *does not* replicate file permissions and file ownership, it simply copies them as whoever runs the "svnadmin hotcopy" command. That can cause *enormous* problems in various configurations. And between operating systems, the "hook" or "conf" tools that are incompatible between the system's scripting languages. Worse, if your new OS does not have an equal or greater Subversion major release, the hotcopy will likely be incompatibile with the new OS. I spent one *hell* of a time last year, when someone had been running a handbuilt Subversion binary with a manually built and awkwardly configured service, and I was prevented by "policy" from updating the Subversion on RHEL 5.x, which was Subversion 1.4.x, to the publicly available Subversion 1.6.x from RPMforge. So I was compelled for political reasons, not techinical reasons, to continue to support the older and more fragile environments, and not permitted to migrate them for quite a long time. That said, you also face a very dangerous "split brain" issue if you simply set up the replicated, up to 24 hours out of date copy elsewhere and set up the same uuid, so users who've already checked out or checked in changes since the last snapshot will have a local working copy that is dangerously out of sync with the replica. Two diferent working copies can wind up with different ideas of whatever revisions occurred, and may wind up out of sync between the two repositories. All that said, Solaris=>Linux is fortunately a fairly easy migration. Similar releases of Subversion are available, unless you have a seriously out of date system that policy forbids you from updating. The trick is to keep the *non* db files, the hooks and conf files, mirrored separately and regularly, and keep a Linux read-only repository mirrored with "svnsync", Properly managed, the "svnsync" can even be triggered to occur after every successful commit, and always keep you within one revision of the master repository. If you have to do the replica, *use a new uuid* and inform your users that they have to deal with a new repository.