Jon LaBadie wrote:
> On Mon, Jul 02, 2007 at 01:48:59PM -0400, Chris Hoogendyk wrote:
>
>>> Paul Bijnens wrote:
>>>
>>>
>>>> Instead of making it a different configuration, and running into trouble
>>>> on which full to base an incrmeental, why don't you run an additional
>>>> amdump of the normal config in the weekend, but which has options to
>>>> override the config:
>>>>
>>>> amdump daily -o reserver=100,tapedev=/no/such/tape
>>>>
>>>> With the option "tapedev /no/such/tape" we force Amanda to fall back
>>>> to degraded mode, making backup to holdingdisk only, and with the
>>>> "reserve 100", we avoid wasting holdingdisk space for full backups in
>>>> the degraded mode.
>>>>
>> ok, tried this over the preceding weekend.
>>
>> the amanda user's crontab has these entries:
>>
>> 0 15 * * 1-5 /usr/local/sbin/amcheck -m daily
>> 45 0 * * 2-6 /usr/local/sbin/amdump daily
>> 45 0 * * 0-1 /usr/local/sbin/amdump daily -o
>> reserve=100,tapedev=/dev/rmt/0n
>>
>> however, the weekend runs looked exactly like the weekday runs. They
>> used an AIT tape off /dev/rmt/1n and ran fulls and incrementals
>> intermixed. I searched the report, the log files, the debug files, etc.
>> for any error messages about the command line options or any references
>> to /dev/rmt/0n. none. I even tried
>>
>> # find /tmp/amanda -type f | xargs grep '/dev/rmt/0'
>>
>> and got nothing except the alternative "weekend" configuration I had
>> played with the previous weekend.
>>
>> 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.)
>>
>> 2. There is a bug in amanda, and it doesn't work?
>>
>> 3. Amanda is being too "smart" and reverting to /dev/rmt/1n when my
>> override to /dev/rmt/0n fails? Doesn't seem likely.
>>
>> 4. There are additional parameters in my configuration that end up
>> overriding my attempt to override tapedev?
>>
>>
>
> Maybe an additional possibility:
>
> 5. /dev/rmt/0n == /dev/rmt/1n
>
> I think by tapedev=/no/such/tape Paul meant that literally, or at
> least some string that could not be a legit tape device.
>
> Two ways I can see the 0 and 1 devices being equivalent. My HP-DDS
> changer shows up in Solaris 9 x86 as two /dev/rmt devices, 0 and 1
> for me. They are the same SCSI ID but different LUNs (the d# in
> c5t3d0 scsi dev nomenclature). One is for the changer mechanism
> and the other for the tape drive. At least that is what it is
> supposed to be. Only one can be used for the changer, but either
> seems to work for the tape drive. I don't think that is common,
> but who knows.
>
> The other way is if you "installed" the tape drive multiple times.
> /dev/rmt/#xxxx are not cleared at boot to allow for persistant
> names for the same device. For example, you could have two tape
> drives and only one powered up at boot time. Which was rmt/0
> would vary. This is handled by recording the /devices data in
> /etc/path_to_inst and is only updated by a reconfigure reboot
> or options to the /usr/sbin/devfsadm command. Maybe there is
> a stale entry in there that makes rmt/0 and rmt/1 the same.
>
> You might also check what the symlinks in /dev/rmt point to
> with an ls -l and what the targets in /devices have for
> maj/min device numbers with ls -lL of /dev/rmt.
>
/dev/rmt/0n is actually my internal dds/3 drive. It exists and works,
but does not have a tape in it. I've used it recently to do some tests
of the behavior of ufsdump for incremental recoveries (checking how
ufsdump deals with deleted, moved, etc. files and directories -- the
answer being "quite well" :-) ).
When I tried a separate "weekend" configuration the previous weekend, I
used tapedev "/dev/rmt/0n" in amanda.conf, and it worked as expected --
found the drive but no tape and just spooled to holding disk.
My AIT drive is /dev/rmt/1n, and the changer for it is addressed as
/dev/scsi/changer/c7t0d0 in amanda.conf.
They all work just fine from mt, mtx, ufsdump, various scripts and
amanda (amtape, amdump, etc) -- except for the above "-o" command line
override failure.
---------------
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
|
