Re: svn 1.8 migration - svnadmin hotcopy

[Thomas Harold <th...@nybeta.com>]

On 6/11/2013 10:20 AM, Stefan Sperling wrote:
> On Tue, Jun 11, 2013 at 10:13:15AM -0400, Thomas Harold wrote:
>> Right now, the size of our dumpfile directory is 207G, while the
>> hotcopy is only 104G.  So the size savings could be big for us.  The
>> hotcopy backup is still our preferred solution, with the dump files
>> being a worst-case fallback.
>
> Please try the new svnadmin hotcopy --incremental.
> It should accelerate your backup process.
>

Yes, I'm looking forward to that feature in 1.8.  We currently tackle 
the time issue in two ways:

1) We only svnadmin hotcopy repositories which have changed in the last 
N days (typically 3 days).  Since we have about 300 repositories 
currently, but we don't do work on things in all 300 constantly, this 
means we only backup a few dozen repositories each night.

BASE="/var/svn/"
DAYS=3

# Directories get randomized with the perl fragment, so that
# they get processed in random order.  This makes the backups
# more reliable over the long term in case one directory
# causes problems.
DIRS=`$FIND ${BASE} -maxdepth 3 -name current -mtime -${DAYS} | \
     $GREP 'db/current$' | \
     $SED 's:/db/current$::' | $SED "s:^${BASE}::" | \
     perl -MList::Util -e 'print List::Util::shuffle <>'`

2) We read the svn repositories from one set of spindles and write the 
hotcopy to a second spindle set.  Even with the 104GB and 300 
repositories that we have, this only takes ~37 minutes.

It still takes 4-5 hours to perform the rdiff-backup step that pushes 
the hotcopy folder over to our internal backup server, but that's more 
because of the tens of thousands of revprops files in some of the 
repositories.  Which is another feature in 1.8 that I'm looking forward to.