a good point in backing and restoring FSFS repositories in Subversion
=====
http://web.mit.edu/ghudson/info/fsfs
* Standard backup software
An FSFS repository can be backed up with standard backup software.
Since old revision files don't change, incremental backups with
standard backup software are efficient. (See "Note: Backups" for
caveats.)
(BDB repositories can be backed up using "svnadmin hotcopy" and can be
backed up incrementally using "svnadmin dump". FSFS just makes it
easier.)
* Can split up repository across multiple spools
If an FSFS repository is outgrowing the filesystem it lives on, you
can symlink old revisions off to another filesystem.
Note: Recovery
--------------
If a process terminates abnormally during a read operation, it should
leave behind no traces in the repository, since read operations do not
modify the repository in any way.
If a process terminates abnormally during a commit operation, it will
leave behind a stale transaction, which will not interfere with
operation and which can be removed with a normal recursive delete
operation.
If a process terminates abnormally during the final phase of a commit
operation, it may be holding the write lock. The way locking is
currently implemented, a dead process should not be able to hold a
lock, but over a remote filesystem that guarantee may not apply.
Also, in the future, FSFS may have optional support for
NFSv2-compatible locking which would allow for the possibility of
stale locks. In either case, the write-lock file can simply be
removed to unblock commits, and read operations will remain
unaffected.
Note: Locking
-------------
Locking is currently implemented using the apr_file_lock() function,
which on Unix uses fcntl() locking, and on Windows uses LockFile().
Modern remote filesystem implementations should support these
operations, but may not do so perfectly, and NFSv2 servers may not
support them at all.
It is possible to do exclusive locking under basic NFSv2 using a
complicated dance involving link(). It's possible that FSFS will
evolve to allow NFSv2-compatible locking, or perhaps just basic O_EXCL
locking, as a repository configuration option.
Note: Backups
-------------
Naively copying an FSFS repository while a commit is taking place
could result in an easily-repaired inconsistency in the backed-up
repository. The backed-up "current" file could wind up referring to a
new revision which wasn't copied, or which was only partially
populated when it was copied.
The "svnadmin hotcopy" command avoids this problem by copying the
"current" file before copying the revision files. But a backup using
the hotcopy command isn't as efficient as a straight incremental
backup. FSFS may evolve so that "svnadmin recover" (currently a
no-op) knows how to recover from the inconsistency which might result
from a naive backup.
Naively copying an FSFS repository might also copy in-progress
transactions, which would become stale and take up extra room until
manually removed. "svnadmin hotcopy" does not copy in-progress
transactions from an FSFS repository, although that might need to
change if Subversion starts making use of long-lived transactions.
So, if you are using standard backup tools to make backups of an FSFS
repository, configure the software to copy the "current" file before
the numbered revision files, if possible, and configure it not to copy
the "transactions" directory. If you can't do those things, use
"svnadmin hotcopy", or be prepared to cope with the very occasional
need for manual repair of the repository upon restoring it from
backup.
http://www.farside.org.uk/200703/svnadmin_recover
