[EMAIL PROTECTED]:
That got brought to my attention today, but unfortunately, my tape cycle
is only eight days, so the last good backup of the file was erased
quite some time ago.
I've seen others near me have this sort of problem, and I've only
narrowly avoided it myself. This need to notice/restore before the
tape cycle runs out is a recurring theme in amanda usage.
Partly to avoid this problem, I write an extra set of tapes
periodically. Amanda's automatic balancing wins big in normal
operation, but is a bit problematic for the straightforward notion of
grabbing a week's tapes for archives. (If runspercycle is 5, you
can't assume a set of 5 tapes has a full dump of every fs.)
I avoid this behavior for the 'archive' runs by setting dumpcycle to a
few weeks. Then if I did a set of archive tapes (onto fresh tapes)
once a month, all dumps will be late and the tapes get filled up.
Basically, I keep going until there are no more deferred dumps. This
works pretty well, but it feels too manual. Another strategy would be
to have three tapecycle's worth of tapes, and swap them out every
month or so.
One feature that might be nice would be to have the compression rate
estimates be separate from the log of dumps, so that two
configurations could share them. Right now I manually move them over
with export/import.
Another feature would be to flush to the tape at the beginning of a
dump run, and then do more dumps to fill the tape. That way when the
compression estimate is off and the last dump doesn't fit, you can
move forward without either redoing the dump or only using part of a
tape. Using a strategy of biggest dump first would help, too; I think
that would lead to the greatest likelihood of using more tape. (Speed
doesn't bother me too much on these, usually.)
Any other ideas for how to address this issue with Amanda in the
current form, or other suggestions?
Greg Troxel <[EMAIL PROTECTED]>
