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.
Received on 2013-06-11 18:35:21 CEST