Dustin J. Mitchell wrote:
> Folks -- I looked into this '-o' question, and have some answers for
> you.
>
> On Mon, Jul 02, 2007 at 03:44:55PM -0400, Chris Hoogendyk wrote:
>
>> Jon LaBadie wrote:
>>
>>> On Mon, Jul 02, 2007 at 01:48:59PM -0400, Chris Hoogendyk wrote:
>>>
>>>> I checked the documentation & man pages and the documentation of the -o
>>>> option is pretty sparse. All references say "see the configuration
>>>> override section in amanda(8)". That section is only a few lines long
>>>> and makes no reference to the syntax with a comma separating multiple
>>>> parameter=value pairs.
>>>>
>>>> So, possibilities ...
>>>>
>>>> 1. The syntax is wrong? And I need to use "amdump daily -o reserve=100
>>>> -o tapedev=/dev/rmt/0n"? (In either case, this should be documented,
>>>> since one would typically want to override more than one parameter if
>>>> any at all.)
>>>>
>
> The documentation could use some help there, for sure. FWIW, it doesn't
> seem that comma-separated options are supported, from my look at the
> source.
>
> The basic problem is that, since you're using a changer, tapedev is
> actually supplied by the *changer*, which looks directly in amanda.conf.
> There's no provision to hand configuration overrides (-o) to changers.
> Furthermore, many changers (e.g., chg-multi) supply their own tapedev.
>
> The best solution, in this case, is to completely disable the changer,
> too:
>
> amdump -o tapedev=/no/such/dev -o tpchanger=
>
> I hope that helps. I'll work on the documentation.
>
Thanks, Dustin.
I set that up in crontab yesterday and it ran this morning. Worked.
45 0 * * 2-6 /usr/local/sbin/amdump daily -o reserve=100 -o
tapedev=/dev/rmt/0n -o tpchanger=""
Now, I'll change that entry back so it doesn't do it on weekdays.
Anyway, it gave me a tape error at the top of the report and then fell
back to incrementals on the holding disk -- mostly level 1, but some
level 2.
The one thing that is annoying is that on /var/mail an incremental is
essentially the same as a full. Those mail files (one per account) are
just like a database file -- add or remove one message and you have to
back up the whole file. It would be interesting to write a wrapper to do
incremental mail dumps sort of like the sql database programs that do
incremental dumps. I wonder if there would be any demand for such a
thing. It could get a little messy, and would probably require the
Application API. In our case, we have about 1200 accounts/files. It
would require reading headers and doing proper locking so as not to
collide with the mail programs.
-------------
Comment & Question on the need for the changer script to tell amdump
what is in amanda.conf (thus overriding the override): This behavior
seems rather contrary. I can see that it is reasonable to override
tpchanger as well as tapedev to provide a sort of clean slate. I can
also see the possibility of some thrashing if amanda tries to read a
tape, fails, and asks the changer to bring up the next tape. But
reversing an override is just weird behavior.
I'm guessing that for those changers where it's all tied up in one scsi
address, and/or where there are multiple drives in a library, it might
be desirable to have changer handle it. Then my case becomes the special
case -- the changer is set up in sgen.conf and has a scsi device
address, and the tape drive is set up in st.conf and is /dev/rmt/1 -- so
the changer does not know how the drive got set up. This special case
might require the changer to look somewhere else, e.g. amanda.conf, to
find out. But, then, couldn't it also tell somehow if there had been an
override? Or does that get too messy?
Ok, maybe we just need to document that when someone overrides tapedev
they should also override tpchanger if they have one.
---------------
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
|
