On Thursday 22 May 2003 15:12, Per von Zweigbergk wrote:
>torsdagen den 22 maj 2003 kl 20.06 skrev Stephen D. Lane:
>> On Thu, May 22, 2003 at 07:23:59PM +0200, Per von Zweigbergk
>> wrote: ---cut---
>>
>>> From what I've understood, Amanda should be run from a cron
>>> job, for example at at midnight, once a day. I've also
>>> understood that you can configure Amanda to only run on
>>> weekdays.
>>>
>>> So, basically, the ideal scenario is to have someone go in to
>>> the server room every morning, remove the ejected tape from the
>>> previous day, and store it in a safe. The operator should then
>>> put in the next tape in the cycle. The operator could even take
>>> the tapes home as a crude off-site backup.
>>
>> I do this every weekday (without the take-home part :) The job
>> runs every weekday morning at 02:03am. When I come in in the
>> morning (which varies from 6am to 11am :), the job is done, and
>> the first thing I do is swap the tape (I find that if I don't do
>> it _first_thing_ it doesn't always get done...)
>
>What happens if you don't? Will it e-mail you pestering you to
> change the tape, forcing you to do two tape runs on one day?
>
>Or will it simply drop that run, noting the problem... i.e. just
> fail gracefully, and try again the next day, effectively delaying
> the backup?
>
>The reason I ask is, what happens in a school holiday, when nobody
> is on site working the backup units? Of course, the "proper"
> solution is to disable the cron job during school holidays, but
> what is someone forgets?
>
>>> However, is it possible to tell Amanda to never ever use more
>>> than one tape per day, circumventing the lack of a tape changer
>>> or tape operator? Basically, it might be able to fully dump one
>>> filesystem, and
>>> only do incremental dumps on the rest of them, never performing
>>> more than one full dump per tape.
>>
>> This is also exactly my setup. One tape per day, 5 (week)days
>> per week. We were doing all level zeros, but one of the
>> filesystems has grown too big to do this, so now we're doing
>> incrementals as well, with a level zero every other day for each
>> filesystem:
>
>Ah, I think I've finally understood the meaning of "dumpcycle" and
>"tapecycle" now.
>
>Tapecycle == amount of tapes. Has to be a multiple of dumpcycle
> for optimal conditions. (?)
>
Yes, 2 to 4x runtapes*runspercycle
>Dumpcycle == amount of tapes in a "cycle"... i.e. one extended
> backup dragging on several days. Each tape will typically contain
> one or more full backups, as well as incremental backups of most
> (all?) filesystems.
Close, but not quite. Dumpcycle is the number of days (or weeks if
you specify it in weeks) you give amanda to do a full on
everything.
Then runspercycle is the actual number of runs in this "dumpcycle"
time that it has to actually do it. For a monday-friday, the
runspercycle would be 5, not 7, if dumpcycle was 7 days or 1 week.
If you have a changer, then "runtapes" is the number of tapes
allowed to be used in one run.
"tapecycle" then is the number of tapes in the pool that amanda can
use before amanda has to start re-useing older tapes. Note that
when amanda re-uses a tape, the indices it kept on the hard drive
for that tape are deleted, and replaced with a new index for the
newly recorded tape. This is automatic.
I run dumpcycle=7, runtapes=1, runspercycle=7, and tapecycle=28
here. I have a changer and could let it do runtapes=2 at times,
but its never more than 2 days late with any scheduled level 0, so
its keeping up for the most part. But if I keep downloading iso's
of the various distro's, I'm going to have to let runtapes=2 one of
these days just to keep up since the tapes are only DDS2's,
arbitrarily set at about 3.7 gigs to make sure there is room on the
end of the tape for a current, backup copy of the indices and
configs that actually generated the rest of the tape, and all
previous tapes in the tapecycle.
However, doing 2 tapes per session seems counter-intuitive for
dependability reasons, so if I needed to expand, I would probably
increment dumpcycle and runspercycle by 1 rather than stepping up
runtapes. But thats just personal opinion.
>Correct me if I'm wrong. :-)
You're close, and I hope this helps, and not too much of it gets
lost in the translation.
--
Cheers, Gene
AMD K6-III@500mhz 320M
Athlon1600XP@1400mhz 512M
99.26% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attornies please note, additions to this message
by Gene Heskett are:
Copyright 2003 by Maurice Eugene Heskett, all rights reserved.
|
