On Monday 01 September 2003 03:41 pm, Jon LaBadie wrote:
> > They are, with their approximate sizes...
> > //mrima1/HistologyCon 4.5GB
> > //mrima1/MRI 37GB
> > //mrima1/users 35GB
> > //mrima1/VIL_Library 7GB
> >
> > The tapes I'm backing up to are 40GB.
>
> Based on a later line it seems like they are twenty, not forty.
>
> And unless MRI and users compress (Software or Hardware) to
> less than twenty GB, you will never be able to back them up.
That's correct, 20 Raw, 40GB compressed. My dumptype is set to use fast
compression on the server, since there's no compression program on the
client. I guess I was just assuming that I would get at least 50%
compression and that the 35GB and 37GB disks would fit. I'll break them up
more in the disklist to make sure.
> > I have nine tapes that I'm using for my backup...
> >
> > DailySet1-001 through DailySet-009. The backup starts running on the
> > first tape (DailySet1-001), and when it's full, chg-manual sends me an
> > email and asks me for the next tape. When I insert the next tape
> > (DailySet1-002) into the drive, it reads for a minute, then spits it back
> > out and sends me another email asking me for the next tape. It continues
> > to do this repeatedly, each time increasing the slot number.
>
> What do the debug logs say about the tapes it "spits out"?
Here's what shows up in an amdump log file from the very first attempt...
changer: opening pipe to: /usr/local/libexec/chg-manual -info
changer: got exit: 0 str: 1 99 1
changer_query: changer return was 99 1
changer_query: searchable = 0
changer_find: looking for DailySet1-002 changer is searchable = 0
changer: opening pipe to: /usr/local/libexec/chg-manual -slot current
changer: got exit: 0 str: 1 /dev/nst0
taper: slot 1: date 20030827 label DailySet1-001 (active tape)
changer: opening pipe to: /usr/local/libexec/chg-manual -slot next
changer: got exit: 0 str: expr: syntax error
taper: slot expr:: tape_rdlabel: tape open: syntax error: No such file or
directory
changer: opening pipe to: /usr/local/libexec/chg-manual -slot next
changer: got exit: 0 str: expr: syntax error
taper: slot expr:: tape_rdlabel: tape open: syntax error: No such file or
directory
changer: opening pipe to: /usr/local/libexec/chg-manual -slot next
changer: got exit: 0 str: expr: syntax error
taper: slot expr:: tape_rdlabel: tape open: syntax error: No such file or
directory
...any thoughts on this?
>
> I haven't used chg-manual. What happens if you set 'lastslot=1'?
>
I tried this on one attempt, and it just didn't ask me for another tape. It
just finished and sent me the report. The report that I had originally
included in this email was from that run.
> I wonder how well the request() function you uncommented has been tested.
> I presume the first fails when run from cron because there is no "tty"
> attached to the program. Perhaps you could change the original request
> function to write to /dev/console (or its equivalent) and make sure you
> have a writable console window open.
I actually haven't tried running it from a cron job yet. I found in the
FAQ-O-Matic that amdump has to be run manually when using the chg-manual
script, so my attempts have been done directly from the command line, and
then log out of the server. There are actually two request() functions in
the script. The first one sends output to /dev/tty and the second one that
I've uncommented sends an email. I opted for the second, since I don't
expect to be sitting at the console when amanda needs another tape, and for
security purposes, I don't want to leave a user logged in when I leave the
lab.
> > The following is a copy of the latest email report that amanda sent from
> > my most recent attempt. Any suggestions would be greatly appreciated.
> >
> > NOTES:
> > planner: Adding new disk vilbu://mrima1/users.
> > planner: Adding new disk vilbu://mrima1/VIL_Library.
> > driver: WARNING: could not create /mnt/dump/20030829: Permission denied
>
> Sounds like it could not work with its holding disk.
> Better figure out this one.
Yeah, I fixed this...wrong permissions set on the holding disk.
> One of your dumps (MRI I think) fails because the tape fills
> (the "no space left" message). Amanda has to abort that dump and
> start over again from the start of MRI - remember no holding disk,
> so all those 10 or 19GB of MRI that were sent over the network
> were not saved anyplace. Amanda sends you email asking for a new
> tape. You are hardly as fast as a tape changer. By the time you
> get the new tape inserted, the client has gotten tired of waiting
> so it drops the session ("connection reset" message). Amanda notes
> this and has nothing else to do with the tape so spits it out and
> considers it used (shows the next 4 tapes to be used message).
>
> Might be other things, but that is a guess.
I guess I'll re-tool a little bit, break up the large dumps in the disklist,
and have another shot. Thanks for all your insight Jon.
--
Thanks,
Sak.
|
