On Thursday 13 February 2003 02:53, Michael Robbert wrote: >Gene Heskett wrote: >>On Wednesday 12 February 2003 19:23, Michael Robbert wrote: >>>Here is an update on the problem that I sent yesterday. I had >>>entered my DDS4backup into cron and last night the backup >>>actually worked, sort of. It looks like it wrote to the tape in >>>slot one, which I labeled DDS4backup01, but the report says that >>>it was labeled DDS4backup05. Below you'll find the results of >>>todays amcheck, all tapes appear to be labeled DDS4backup05, but >>>that is not how I labeled them. I am guessing that tonights >>>backup will fail because it can't seem to find another tape. >>>A second question I have is about the number of slots to put >>> into my changer.conf. I am using the first 5 slots for backup >>> tapes and slot 6 is always a cleaning tape. If I configure >>> lastslot=5 and cleanslot=6 then "amtape DDS4backup clean" gives >>> the following error: amtape: device 0 not clean: Slot 6 is out >>> of range (1 - 5) If I then change lastslot=6 then I get the >>> problem that you'll notice below. Amanda will cycle through the >>> cleaning tape thinking that it is a normal tape. I am using >>>tpchanger=chg-zd-mtx in my amanda.conf. >>> >>>----- Forwarded message from Amanda user >>><[EMAIL PROTECTED]> ----- >>> >>>Date: Wed, 12 Feb 2003 16:04:15 -0700 > From: Amanda user <[EMAIL PROTECTED]> > >>>To: [EMAIL PROTECTED], [EMAIL PROTECTED] >>>Subject: DDS4backup AMANDA PROBLEM: FIX BEFORE RUN, IF POSSIBLE >>>X-Spam-Status: No, hits=-98.9 required=5.0 >>> tests=DOUBLE_CAPSWORD,USER_IN_WHITELIST >>> version=2.31 >>> >>>Amanda Tape Server Host Check >>>----------------------------- >>>Holding disk /holding/amanda: 6128768 KB disk space available, >>>using 6026368 KB Holding disk /storage/amanda: 40446788 KB disk >>>space available, using 40344388 KB >>>amcheck-server: slot 2: date 20030212 label DDS4backup05 (active >>> tape) amcheck-server: slot 3: date 20030212 label DDS4backup05 >>> (active tape) amcheck-server: slot 4: date 20030212 label >>> DDS4backup05 (active tape) amcheck-server: slot 5: date >>> 20030212 label DDS4backup05 (active tape) amcheck-server: fatal >>> slot 6: Cleaning Cartridge Installed and Ejected >> >>Gaack! Either its not advancing the magazine, or you've labeled >> all tapes alike. If the latter, I'm fairly certain that amlabel >> would have had a litter of kittens over that. >> >>Which is it? > >Neither, I have watched it advance the tapes and you can tell by > the fact that it loaded a cleaning tape from slot 6 that > different tapes are getting used. And I am sure that I labeled > all these tapes properly, I had to use -f because amlabel thought > they were labeled even before I labeled them. I also know that > this isn't acurate because when I watch the drive it loads the > tape, but never rewinds or reads the tape to see what label is > actually on it.
Thats odd unless this changer has a barcode reader or some other means of identifying the tape. The tapes should be labeled with some sort of a unique label per tape, and one that satisfies the regex pattern in your amanda.conf. When labeling new tapes with a never before used label, one shouldn't need to use the -f option. If they are in fact labeled as DDS4Backup01, DDS4Backup02, DDS4Backup03 etc then the -f option shouldn't be needed. Please post the label pattern line from your amanda.conf. >>>ERROR: new tape not found in rack >>> (expecting a new tape) >>>NOTE: skipping tape-writable test >>>NOTE: info dir >>> /var/lib/amanda/DDS4backup/curinfo/ito/_usr_local: does not >>> exist NOTE: index dir >>>/var/lib/amanda/DDS4backup/index/ito/_usr_local: does not exist >>>NOTE: info dir /var/lib/amanda/DDS4backup/curinfo/ito/_u1: does >>>not exist NOTE: index dir >>>/var/lib/amanda/DDS4backup/index/ito/_u1: does not exist Server >>>check took 254.892 seconds Ahh, I missed that line. Can I blame it on the poor formatting as it was rx'd here? Ny apologies in any event. >>>Amanda Backup Client Hosts Check >>>-------------------------------- >>>Client check: 1 host checked in 0.510 seconds, 0 problems found >> >>This settles it. >> >>Its not advancing the tape then, and it obviously read all that >>from the drives buffers. So something is amiss in the changer >>script setup. This amount of tape checking should have taken a >> time measured in minutes, not just fractions of a second. > >The tape check took 254.892 seconds(over 4 minutes), it was the > client host check that only took 0.510 seconds -- Cheers, Gene AMD K6-III@500mhz 320M Athlon1600XP@1400mhz 512M 99.23% setiathome rank, not too shabby for a WV hillbilly