On Thu, Sep 23, 2004 at 01:23:59PM -0500, Ivan Petrovich wrote:
> Jon,
> 
> > To be accurate, the tapecycle is NOT a time period,
> > it is an integer value, the number of tapes in rotation.
> > Or from amanda's perspective, the number of tapes that
> > must be used before a tape can be used again.  In my
> > case I have 18 tapes in rotation and have tapecycle
> > set to 12.  Most sites probably have the tapecycle
> > set to equal the actual number of tapes in rotation.
> 
> Okay, I could have had "runspercycle = 2" and "tapecycle = 5", but it
> doesn't change the fact that I can't save any tape if I want to keep 5
> run's worth of backup on hand.

Kind of; "saving tape" is a rather meaningless term for amanda
unless it refers to reducing the number of tapes.

With a dumpcycle of 1 wk (aka 7 days),
       runspercycle of 4, and a
       tapecycle of 5, 
you are correct that you would have five "dumps" on hand.

But that would consist of barely more than one complete
system backup.  For some disklist entries (DLEs) you would
have a level 0, 3 incrementals, and another level 0, from
the most recent dump.

But consider a DLE that did not backup with a level 0 on
the last run, but had a level 0 two runs ago.  It would
have that level 0 plus one incremental after it.  The three
older incrementals would not have a level 0 to recover from
and thus have relatively little value.

If instead you had a shorter dumpcycle (say 3 or 4 days)
and runspercycle of 2 you would then get a level 0 for
each DLE on alternate dump runs and would have two or
three backup cycles for each DLE rather than barely
over one backup cycle.

For shortened dumpcycles you may have to introduce software
or hardware compression to fit the nightly dumps on a single
tape.
-- 
Jon H. LaBadie                  jon AT jgcomp DOT com
 JG Computing
 4455 Province Line Road        (609) 252-0159
 Princeton, NJ  08540-4322      (609) 683-7220 (fax)