Amanda-Users

Re: Failure because of missing tapes.

2003-08-10 17:20:01
Subject: Re: Failure because of missing tapes.
From: Gene Heskett <gene.heskett AT verizon DOT net>
To: Stephen Carville <stephen AT totalflood DOT com>, Amanda Users <amanda-users AT amanda DOT org>
Date: Sun, 10 Aug 2003 17:15:24 -0400
On Sunday 10 August 2003 14:59, Stephen Carville wrote:
>Whenever Amanda has to roll over to a new tape and the first tape in
>the expected list is missing, the backups fail.  For example, last
>night, the expected tapes were:
>
>C83166
>C83259
>C83170
>
>The tape C83166 was not in the changer so my wrapper script loaded
>C83259, fired off amdump, and the backup started up fine.  However,
>when the tape ran out, Amanda tried to load C83166 but couldn't find
>it and failed.  C83170 was available but Amanda apparently did not
>try to load it.
>
>This condition is caused by our offsite storage facility not alway
>returning tapes on schedule so, until I can get managment to dump
>their worthless arses, I need a workaround for a chronic missing
> tape problem.
>
>Is there a configuration option I can use to tell Amanda to try the
>next tape if the desired tape is not avaialble?
>
>$ amadmin daily1 version
>build: VERSION="Amanda-2.4.3b2"
>       BUILT_DATE="Fri Jul 25 16:50:11 PDT 2003"
>       BUILT_MACH="Linux chena 2.4.18 #6 SMP Wed Jul 23 10:08:38 PDT
>2003 i686 unknown"
>       CC="gcc"
>paths: bindir="/usr/local/bin" sbindir="/usr/local/sbin"
>       libexecdir="/usr/local/libexec" mandir="/usr/local/man"
>       AMANDA_TMPDIR="/tmp/amanda" AMANDA_DBGDIR="/tmp/amanda"
>       CONFIG_DIR="/usr/local/etc/amanda" DEV_PREFIX="/dev/"
>       RDEV_PREFIX="/dev/" DUMP="/sbin/dump"
>       RESTORE="/sbin/restore" SAMBA_CLIENT="/usr/bin/smbclient"
>       GNUTAR="/bin/gtar" COMPRESS_PATH="/bin/gzip"
>       UNCOMPRESS_PATH="/bin/gzip" MAILER="/usr/bin/Mail"
>       listed_incr_dir="/usr/local/var/amanda/gnutar-lists"
>defs:  DEFAULT_SERVER="chena" DEFAULT_CONFIG="DailySet1"
>       DEFAULT_TAPE_SERVER="chena"
>       DEFAULT_TAPE_DEVICE="/dev/null" HAVE_MMAP HAVE_SYSVSHM
>       LOCKING=POSIX_FCNTL SETPGRP_VOID DEBUG_CODE
>       AMANDA_DEBUG_DAYS=4 BSD_SECURITY USE_AMANDAHOSTS
>       CLIENT_LOGIN="amanda" FORCE_USERID HAVE_GZIP
>       COMPRESS_SUFFIX=".gz" COMPRESS_FAST_OPT="--fast"
>       COMPRESS_BEST_OPT="--best" UNCOMPRESS_OPT="-dc"
>
>---- from amanda.conf ----
>dumpcycle 7 days
>runspercycle 6
>tapecycle 14 tapes
>runtapes 3
>---- end  -----
>
>I actually have 19 tapes allocated for this backup.

This is something thats always bothered me too.  What it will take is 
for the search algorythm to do one more search than the magazine 
capacity.  I've had it email me for new tapes, I put them in, but for 
some reason it starts its scan the next time on the first slot (in 
amands mind, but the tape in the drive came from slot 1, not 0) so of 
course it finds the wrong tape, goes onto the next, which is still 
the same tape, then 2 and 3, without ever finding the tape in slot 0, 
which is of course the correct one.

By having the check code go back and recheck the first slot it 
*thought* it checked, after the slots and amanda have gotten into 
synch, such foolishness could be avoided.

However, I'll leave that bit of tweaking to someone who knows the code 
much better than I.

-- 
Cheers, Gene
AMD K6-III@500mhz 320M
Athlon1600XP@1400mhz  512M
99.27% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attornies please note, additions to this message
by Gene Heskett are:
Copyright 2003 by Maurice Eugene Heskett, all rights reserved.


<Prev in Thread] Current Thread [Next in Thread>