We use the native afs backup. We currently do a full backup of the
whole cell weekly followed by daily incrementals until we cycle
back to Monday midnight and start the next full.
As the size of the cell (user vols ) grows our backup window is
getting way too big. Often it stretches into late Wed before it
completes.
I am wondering how many are doing weekly fulls? I am considering a
monthly full with incrementals the rest of the month but thats
kinda scary if maybe your full is not good.
We do every-other-week fulls rotating across 10 very large file
servers, and
the fulls still take too long. We're in the process of implementing
dump to disk, and are actually going to a 28-day cycle of a full,
three level 1 at week intervals, and daily level 2s from the previous
weekly or full, depending on day of the month:
M D D D D D D Cycle 1
W D D D D D D
W D D D D D D
W D D D D D D
M D D D . . . Cycle 2
We will be holding on to two cycles. At the moment we are doing this
with vos dump, using a heavily modified version of the afsdump script
that Matt Hoskins so kindly posted a month or two back. Yes, we will
publish when done
(another week or two), and I want to offer advance apologies to Matt
for how unrecognizable it's going to be.
Because it uses vos dump rather that backup, we are going to do full
backups of 1/28th of the volumes every day. This will be a bit of a
hands-on nightmare to get rolling, but once in place it'll be largely
self-sustaining (handwave, handwave).
So the short answer is 'don't do all your fulls at once.' It
complicates your restores and requires you do more tracking or very
sensible naming, but that's what dbs are for, right?
Also I often need to move volumes during the backup time and I am
unsure how this affects the backups
My seat-of-the-pants experience is that if a volume is scheduled for
backup
and is moved after the backup starts but before it is actually backed
up, no backup occurs because there is no .backup volume. Create one
after the move, and all is fine.
One of the many nice things about Matt's script is that it seems to
be relatively impervious to move issues. Yes, you can get bitten by
race conditions, but the worst thing that happens is that you get an
extra level 0 when a volume is moved. Er, assuming I'm reading his
code right.
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
