svnadmin hotcopy hangs indefinitely

Question

I'm implementing a backup strategy for a Subversion repository.

I chose incremental backup on local NAS. I mounted the NAS over Samba and tried to hotcopy my test repository (that has few commits and weighs 320KB).

svnadmin hotcopy --incremental /path/to/original /path/to/backup

The problem is that the program hangs indefinitely!

How to fix? CTRL+C won't work

[Edit] Seems that this happens ONLY when I push to Samba storage. If I hotcopy to my local drive it will just complete successfully

Answer 1

Ran into this same issue today. It is a known issue:

https://issues.apache.org/jira/browse/SVN-4177

"You cannot hotcopy a repository that uses SQLite to a filesystem that does not support SQLite. The only reason 1.6 "works" is that 1.6 is buggy and does a "dumb" copy that does not guarantee that the copy is valid.

The use of SQLite can be disabled by disabling rep-caching and removing the rep-cache file.

You can make a hotcopy to a filesystem that does support SQLite and then make a dumb copy to the other filesystem.

You can take the main repository offline and then make a dumb copy to the other filesystem.

I suppose Subversion could itself make a copy of the SQLite file inside the repository, i.e. on the same filesystem, and then make a dumb copy to the other filesystem but I have no desire to see that sort of code in Subversion."

Another fix is to add an option to mount.cifs - nobrl. This is not recommended if you are trying to share a SQLite3 db using the cifs share but should work for a backup.

nobrl - Do not send byte range lock requests to the server. This is necessary for certain applications that break with cifs style mandatory byte range locks (and most cifs servers do not yet support requesting advisory byte range locks).

Answer 2

Can it be that your test repo was on BDB fs?

As described in the section called “Berkeley DB”, hot-copied Berkeley DB repositories are not portable across operating systems, nor will they work on machines with a different “endianness” than the machine where they were created.

If you attempt to use Berkeley DB on a noncompliant remote filesystem, the results are unpredictable—you may see mysterious errors right away, or it may be months before you discover that your repository database is subtly corrupted. You should strongly consider using the FSFS data store for repositories that need to live on a network share.