On Fri, Sep 24, 2004 at 08:53:32AM -0500, Ivan Petrovich wrote:
> Gene,
> 
> > I'm puzzled, 4 days, but 5 tapes?  Whats the 5th tape?
> 
> I thought that's what you're supposed to do: (tapecycle >=
> runspercycle + 1). This will keep the 5th run from writing over the
> first tape.
> 
> > Bear in mind that a full backup isn't any one tape, but every tape for 
> > the most recent dumpcycle days will be required to do a full bare 
> > metal recovery.
> 
> True. I didn't think of that. But this point to what I believe is a
> weakness of Amanda:
> 
> Say I have a 1 week dumpcycle, runspercycle = 7. And for simplicity,
> say I have 7 files: file_0 .. file_6. Also assume that every file is
> changed everyday so that a level 1 is needed everyday.
> 
> Also assume that we only do levels 0 and 1.
> 
> On Sunday, Amanda does a level 0 for file_0, and level 1 for all other
> files; on Monday, Amanda does a level 0 for file_1, and level 1 for
> all other files, and so on.
> 
> At the end of the week, I will have tapes from Sunday through
> Saturday. Let's call them "tape zero" .. "tape six."
> 
> Then my customer calls and asks me to restore a file as it was on
> Wednesday. I can do that easily for file_0, since the level 0 for that
> file is on "tape zero," backed up on Sunday; and I also have all the
> necessary level 1's for it. So I grab tape zero (Sunday's level 0) and
> tape three (Wednesday's level 1), run amrecover, and voila.
> 
> But if I were to need to recover file_5 "as it was on Wednesday," I
> would be out of luck. This is because among these 7 tapes, the only
> level 0 for file_5 is on tape five, backed up on Friday. All level 1's
> from tape zero through tape 4 for file_5 are useless unless I happen
> to have preserved the level 0 from the previous cycle.
> 
> What this means is: unless I preserve tapes from the previous cycle,
> tapes for one cycle can only guarantee that a file can be restored to
> its state _sometime_ in that cycle.
> 
> The more traditional full/incremental backup scheme allows you to,
> in the case of a 7-day cycle, have the confidence that you can restore
> a file to its state on any of the last 7 days. But that isn't true
> with Amanda. :(
> 

Which is why your earlier statement was incorrect:

> I thought that's what you're supposed to do:
> (tapecycle >= runspercycle + 1).

That is the minimum you should even consider,
not the number you are "supposed" to have.

As to your customer who is "out of luck", I think the same situation
would arise from any backup scheme.  If they ask for a file outside
the stored period they are out of luck.

But in your proposed situation that might not be the case.  You are
setting things up from the start of the contract and beginning with
level 1 for some things.  That would never happen in reality.  Any
DLE must begin, when first added to the disklist, with a level 0.

So, if Sunday to Wednesday's tapes contain level 1's, their level 0's
must be in Thursday to Saturday's tapes.

You are correct that once a level 0 tape is overwritten the incrementals
after that, til the next level 0, have reduced value.  Thus, if you are
promising the availability of any file in a single dumpcycle worth of days,
you better keep more than one dumpcycle's number of tapes in rotation.
A lot more.  I used to have 4 dumpcycles number of tapes in rotation.
Some tapes have worn out and I've not replaced them so I'm down to 3.

-- 
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)