On Thu April 24 2003 10:40, Martin Schwarz wrote:
>Hello Gene,
>
>On Thu, Apr 24, 2003 at 10:10:35AM -0400, Gene Heskett wrote:
>> had about 600 megs worth of tape left as I run it a bit small to
>> assure room on the end for a seperate, non-amanda done,
>> uncompressed tarball of tonights indices and the configs that
>> were used. Its part of the wrapper script that runs amdump.
>
>this sounds like a very good idea. Would you mind sharing this
> wrapper script with the list? Here's what I have used so far as a
> wrapper script in my daily cron job:
>
>#!/bin/sh
>#
> -----------------------------------------------------------------
>----- # runbackup - wrapper script for nightly amanda backup at
> tpl #
> -----------------------------------------------------------------
>-----
>
># amanda configuration set name:
>CONFIG=tpl
>
># run the amanda backup command:
>/usr/sbin/amdump $CONFIG
>
># wait a little to make sure tape drive is ready:
># (not sure if this is really needed, but it won't hurt)
>/bin/sleep 300 # 5 minutes
>
># check tape drive status and make sure a tape is online, then
> (and only # then) verify the tape contents:
># (This is needed, because amverify doesn't simply fail if there
> is no # tape, but sits and waits forever, thus grabbing any tape
> that is # inserted later.)
>/bin/mt status 2>&1 | grep -q "ONLINE" && /usr/sbin/amverify
> $CONFIG >/tmp/amanda/amverify.`/bin/date +%Y%m%d`.$$.debug 2>&1
>
># rewind and unload the tape:
># (only when tape is online, to avoid superfluous error messages)
>/bin/mt status 2>&1 | grep -q "ONLINE" && /bin/mt rewoffl
>
>#
> -----------------------------------------------------------------
>-----
>
Sure, but its not doing the same thing I don't believe.
Bash experts will shoot this full of holes of course, and
it has bit me a couple of times because it will do it
regardless of whether or not the correct tape was in the
magazine. If its the incorrect tape, then it gets trashed
by this script as it will then overwrite the tape from
where ever amdump leaves it positioned from its search
for the right tape. What I need is a quick & dirty way to
verify I have the right tape.
Its also failed from an EOT message, but hasn't since I
reduced the tapetype another 75 megs over what I thought
was enough spare space.
There should be a way to prevent all this, but I haven't
given it that much thought, and I'm no bash script guru :(
This script does the configs & indices
------------------
#!/bin/bash
PATH=/bin:/usr/local/sbin
# this is and attempt to derive the tape number for
# a rewrite of the archiving now done
cd /amanda/config-bak # new dir for all this
TAPELIST=/usr/local/etc/amanda/DailySet1/tapelist
if [ -f $TAPELIST ] ; then
read TAPEDATE TAPENAME TAPESTATUS junk < $TAPELIST
TAPENUM=${TAPENAME##*-}
echo $TAPENUM # goes to the mail I get
fi
# get rid of last nights trash
rm -f configuration.tar.$TAPENUM indices.tar.$TAPENUM dd.report.$TAPENUM
# was it at BOT! Record where
# this looks like a good place to error check
# if the tell is >64, it should be safe to write :)
# if <=64, then were gonna get kissed as that tape
# will be trashed...
mt -f /dev/nst0 tell >dd.report.$TAPENUM
# tar the indices
tar -cpsf indices.tar.$TAPENUM /usr/local/var/amanda
# tar the configs
tar -cpsf configuration.tar.$TAPENUM /usr/local/etc/amanda
# write them to the tape
dd if=indices.tar.$TAPENUM of=/dev/nst0 bs=32k
dd if=configuration.tar.$TAPENUM of=/dev/nst0 bs=32k
# and append the new position
mt -f /dev/nst0 tell >>dd.report.$TAPENUM
# now force the drive to flush its buffers to the media,
# noteing that I could have used /dev/st0 in the last dd
# above, but would have lost the 'tell' data then
# the rest is optional
mt -f /dev/nst0 rewind
cd ..
------------------------
Then, here is the wrapper script that is named in the amanda
crontab to run the whole thing. I was real inverntive and called
it 'backup.sh' :)
--------------------
#!/bin/bash
PATH=/usr/local/sbin:/amanda/config-bak:/bin
export PATH
# a shell wrapper for amdump
/usr/local/sbin/amdump DailySet1
# that should run amdump, and when its done, do this next
# to assure we have a copy of the generated indices and configs
# which are not backed by amanda as amdump has a lock on them
# when running. These files when next backed up will be one day
# older in the tape archive than the backup they are part of.
# However, they are now, if there is room on the tape, being appended
# to the amdump made tape by useing dd to put them on the current
# tape if they will fit. If not, well, we tried. There will still
# be a day old copy in the /amanda dir file of the tape.
/amanda/bak-indices-configs # the 1st script above's name
# which will do the housekeeping and generate the new tarballs,
# and append them to the tape if there is room on the tape amdump just made.
# This will have rewound the tape, but the tape is still in the drive.
# JRJ just posted a trick that makes the drive eject the tape.
# sitting in the drive, its 30 degrees warmer, not good.
/usr/local/sbin/amtape DailySet1 slot advance
# but without loading the next one, but the next run will now
# load the next tape without looking at the current one before
# ejectng it, thereby saving amdump and amcheck some time.
--------------------
--
Cheers, Gene
AMD K6-III@500mhz 320M
Athlon1600XP@1400mhz 512M
99.26% 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.
|
