Marc Muehlfeld wrote:
> Gerrit A. Smit -TI- schrieb:
>>> If you don't want to have the full dumps seen by amrecovery why
>>> don't you create a separate set for it?
>>
>> Having a separate set means having a separate configuration, right? 
>
> Not a full separate configuration. In ~/KDD/amanda.conf (KDD is one of
> my two sets) I have all set specific information (diskfile, dumpcycle,
> indexdir, tapetype, Changer Configuration,...) and also in the end a
> include statement, where I include a ~/Global/global-amanda.conf with
> all other parameters, I use in both sets (holding disk, tapetype
> definitions, dumptype definitions,...). For my second set I just
> copied the KDD/amanda.conf to KMS/amanda.conf and changed the
> parameters. So most settings remain inside the global configuration
> file and e.g. new holdingdisks or other global parameters have only to
> be configured at one place.
>
> The disklist file you can define by a symlink or having the same
> parameter in both set specific amanda.conf
>
>
>
> > Or can I have more than one set of tapes in the same configuration?
>
> What do you mean with "one set of tapes in the same configuration"?
>
>
>
>> I am looking for means to have 1 set of tapes for all purposes. Which
>> also means
>> that the number of tapes needed for a full dump is part of the total
>> number of
>> tapes in a set, and so it can get bigger or smaller as needed. Users
>> don't have
>> to bother about a different configuration.
>
> Here I use a separate set for off-site full dumps since 5 years. Works
> fine. And all administrators who restore had no problem with that.
> Just looking at their calender. If the day they wanna restore was the
> full-dump-day then they have to choose the second set.
>
> Also it's easy to see what kind of backup is on a tape if you have
> different sets. Here I use different colors for the barcode lables too.
>
>
>
>> This might seem strange, but I still want to give it a try. They only
>> remaining
>> point is the use of amrecover with this setup.
>
> I think, you can't switch amrecover to not seeing/showing the tapes.
> Mabye by manipulating the database files. But I'm sure, you don't want
> this! I think the easiest way is to use a different set.


Well, just about everyone but the folks at zmanda have chimed in on this
one (they are in the Pacific Time Zone, so they might be showing up in
an hour or so ;-)  ).

A couple of comments:

Forcing full doesn't seem to me to be the best way for off site
archives. For one thing, that would end up making your incrementals
dependent on your off site archive if forcing was the only change you
made to do it. Then your incrementals for the next few days are fairly
useless if you don't want to run off site to get that archive tape.

As far as marking tapes off site and having that stored somewhere by
amanda, there is a suggestion (aka "bug") posted by me on SourceForge
for physical tape tracking. Integrating that into options for amrecover
would be a further feature tied in to that. It isn't necessarily an easy
addition in part because of the user logic that would have to be ironed out.

In my opinion, a sysadmin is in a need to know position when doing a
recover. You need to know what tapes can be used for recovery, which are
the most recent, etc. amrecover will assume the most recent full and
subsequent incrementals. If you have forced all the fulls onto one tape
and then put that tape off site as an archive, then you need to be aware
of that and tell amrecover to use a previous date. It will, of course,
tell you the specific tapes it needs based on the options you give it.

As mentioned by a couple of others, probably the cleanest solution is an
alternate configuration. I have an archive configuration. It is
essentially a clone of my daily configuration. However, and this is a
critical point, I didn't want it to interfere with my regular daily run
of fulls and incrementals. So, I modified the dump types to not record
the dump date (in /etc/dumpdates for me, in
/usr/local/var/amanda/gnutar-lists for those using gnutar). This allows
me to run a separate full backup easily at the end of semesters and put
it off site without affecting my regular daily cycle. Since I run a five
day cycle in a week, I have the weekend free to run an archive if I want
to. My archive configuration has a dumpcycle 90 days, runspercycle 1,
tapecycle 5 tapes. With runspercycle 1, force is not required.

Keeps things clean and goes with the flow of amanda's inherent logic.  ;-)


---------------

Chris Hoogendyk

-
   O__  ---- Systems Administrator
  c/ /'_ --- Biology & Geology Departments
 (*) \(*) -- 140 Morrill Science Center
~~~~~~~~~~ - University of Massachusetts, Amherst 

<hoogendyk AT bio.umass DOT edu>

--------------- 

Erdös 4