On Thu, 18 Jan 2001, Hurf Sheldon wrote:
> Our amanda was set up by set up by someone who has moved on.
Well now that would be me...
> 1: When we move the Overland to the FreeBSD PC and run amlabel, we get
> errors in the system log file and the DLT goes out to lunch - we setup
> an HP SureStore 2300 6 tape DDS as a test and saw some similar errors
> but
> after the tapes were labeled they subsided:
> (ch0:ahc0:0:0:1): MOVE MEDIUM. CDB: a5 20 0 0 0 3 0 1 0 0 0 0
> (ch0:ahc0:0:0:1): ILLEGAL REQUEST asc:3b,d
> (ch0:ahc0:0:0:1): Medium destination element full
> ch: warning: could not map element source address 0d to a valid element
> type
> (sa0:ahc0:0:0:0): tape is now frozen- use an OFFLINE, REWIND or MTEOM
> command to clear this state.
>
> Neither the FreeBSD list nor Overland has had any insight into this...
Which FreeBSD list did you ask? Each has a different focus. Anyhow
this one looks pretty obvious. "Move medium" means the changer received
a command to move a tape, "Illegal request...Medium destination element
full" means the destination of the move command, either a tape drive or
a changer slot, already has a tape in it.
What would cause this? Offhand I can think of a couple possibilities,
though there may well be others I'm missing. 1) Changer scripts maintain
knowledge (in a file) of a "current slot", which is which slot the
currently loaded tape came from. If you're moving the changer back and
forth between the HP-UX and FreeBSD machines you might be confusing the
changer scripts if you're not putting the changer back in the same state
it was in when it last came off that machine. Also if you move tapes
around in the changer without using amtape commands this could cause the
same sort of confusion. 2) Whatever changer script you're using may just
not be sending the right commands.
To debug this I think I would start at the lowest level of software you
can, chio if that's what you're using, and make sure you can send
commands to the changer and see it do the right thing in response. Once
that works, move up a level to your changer script and do the same thing.
Once that works move up to amtape. if the changer script is happy,
amtape probably will be, too.
> 2: We can't directly access the NAS disks - how would we give dump
> instructions
> to a system that has it mounted via NFS or SMB? I thought Amanda used
> tar
> on Unix but a dump request to an Irix system with the NAS mounted failed
> "disk /remote/nas01/2 offline on nimble". A remote SMB mount can't be in
> turn shared so when trying to backup via smbclient we get:
> "PC SHARE //lassiter/N access error: host down or invalid password?"
Amanda will use either dump or tar, whichever is specified in the
dumptype you specify in the disklist for each filesystem. All the
unix systems were using dump when I left. For the NAS you'll have
to use tar.
> 3: How can we configure amanda to do only level 0 or only incremental
> backups?
> We'd like to (say) run level 0 over the weekend to one tape set and
> incrementals to
> another, with an eye to adding a second tape machine and do level 0 to
> one and
> incrementals to the other.
David has already given you some ideas on this. I would just add that
in deciding if you really want to do this, you should think carefully
about what would be involved in performing a multi-level restore, and
then ask yourself if you're really willing to live with that.
If your daily run is taking too long I'd think about a few
alternatives... a) upgrade the DLT 4000 to a DLT 8000, b) add more
tapes to the tape rotation and increase dumpcycle so that level 0s are
spread over a greater number of days. For the archive runs you're
looking for I'd do that as a separate config with no-record, but I
wouldn't eliminate the level 0s in the regular daily config. But
that's just my preference. It's your call now of course.
> 3a: To use a second 15 tape magazine, is there a way to setup
> amanda.conf to count
> all 30 tapes sequentially? The problem seems to be that Amanda thinks
> there is
> 30 slots if there are 30 tapes, so the chio routines fail. We'd like to
> have it stop
> the tapers, ask for the next magazine and start at slot 1 again.
I don't have experience with this type of setup yet, and it's been too
long since I've looked at the code so I'm not sure what happens. What
happens if the tape it wants isn't in the changer? Does it keep rotating
through the changer until you stop it? Does it make one rotation and
give up?
As far as I can remember Amanda doesn't have a notion of magazines, so
it doesn't know internally what the inventory of the changer is. This is
knowledge that would have to be built into the changer script, which you
could write or have a student tech to write.
I wrote the one on the HP server and it didn't take very long. You
could probably use that as a starting point. It should be pretty
straightforward to rip out the "mc" commands and replace with chio
commands. Then just have it check whenever it wraps from last slot to
first slot whether the requested tape is outside the current range, and
if so do something to get your attention (send e-mail and retry until
magazine is changed, write a message to console, return an error status,
whatever). Samples of some of these ideas are in chg-manual, which you
could copy from.
> 4: We compiled the latest Amanda for FreeBSD (VERSION="Amanda-2.4.2")
> which included
> patches for Windows 2000 via smbclient - that works fine now. We are
> getting "auth"
> errors on the cd /usr/local/amanda/FreeBSD system that we built as the
> tape server:
> " ERROR: vermeer: [access as backup not allowed from
> [EMAIL PROTECTED]]\
> amandahostsauth failed " - Did we miss something - I'm not able to track
> this down.
Amandahosts authorization is now the default for amanda. I started with
BSD security and never changed over to amandahosts security. It looks
like you built amanda on vermeer with amandahosts security. You probably
should go ahead and switch to amandahosts, but doing it while you're
changing servers is really going to complicate life. The simplest way
to get from where you are to where you want to be would go something
like this:
1. Rebuild amanda on vermeer with BSD security.
2. Finish the server transition.
3. Install .amandahosts files on all clients. This is easy with
cfengine.
4. Rebuild amanda server and all clients with amandahosts security.
5. Use cfengine to remove the .rhosts files from all the clients.
FYI, the config file I used for configuring my amanda builds is in
/pcg/local/amanda/etc/config.site.
> 5: What other Amanda guidance/support resources are available?
Start from the web site www.amanda.org. It gives you directions to
everything else.
> 6: Just out of curiosity, is anyone working on a gui configuration
> interface for Amanda?
Dunno but I doubt it. Check the ongoing projects list on the web site
or ask on amanda-hackers.
> my apologies for the "laundry list"
>
> thanks in advance for any help
>
> hurf
-Mitch
