Consistent live fsfs backups without copy

We want to get consistent backups of an fsfs repository [*], and
we've got a couple of major constraints:

1. We have automated nightly builds, so it's impractical to find a
time to shut down the server entirely.
2. This repository will be likely grow to larger than half the
capacity of the drive, so an "svnadmin hotcopy" will fail. We need to
transfer the data off the machine directly.

 From looking over the source, I see a couple interesting things:

1. It looks like write locking is done by holding flocks on the file
"write-lock" or maybe "locks/<whatever>". Probably doesn't help us much.

2. it looks like svn_fs_fs__hotcopy copies stuff like this:

    a. check format file - must be fsfs version 1 or 2.
    b. copy current file
    c. copy uuid
    d. get youngest revision from current file
    e. copy revisions, oldest to youngest listed in current_file
    f. copy revprop files, oldest to youngest
    g. make transactions directory - all actual transactions are
discarded "for now".
    h. copy locks tree
    i. make format file

    ...all without any sort of locking. Correct? (I guess files must
be changed with the atomic rename() trick so this works?)

How much of this care is necessary? I'm not sure yet if it's possible
to get our backup software (NetVault) to copy stuff in a pre-defined
order. I could easily do this on backup:

1. pre script - copy current file to a location where it won't
change, erroring out if it already exists
2. copy everything
3. post script - remove my copied current file

and on restore,

- throw away revisions and revprops newer than in my copied current file
- throw away all transactions
- copy the current file back to its proper location

is this good enough?

Regards,
Scott

[*] - We could probably switch to Berkeley DB, but I _know_ it needs
the log files to be copied _after_ everything else. As mentioned
midway through this message, I'm not sure yet if our backup software
can do that.

-- 
Scott Lamb <http://www.slamb.org/>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org