tutorial on recovering a good copy of this tapes index's

Hi All;

I've been playing with the tape made last night, with an eye toward 
trying to make the recovery of the index that made this tape a bit 
more intuitive.

1:  This script is being run after the amdump run, and assumes the 
tapetype has been reduced in size sufficient to leave room on the 
tape for the index and config that made the tape.
========================
#!/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
# first, recover the name of the tape in the drive, without
# rewinding it and re-reading it.
TAPELIST=/usr/local/etc/amanda/DailySet1/tapelist
if [ -f $TAPELIST ] ; then
        read TAPEDATE TAPENAME TAPESTATUS junk < $TAPELIST
        TAPENUM=${TAPENAME##*-}
        echo $TAPENAME
fi

# now get rid of recycled data
rm -f configuration.tar.$TAPENUM indices.tar.$TAPENUM \ 
dd.report.$TAPENUM

# Lets see if its safe to write to the tape by generating a new 
dd.report$TAPENUM
mt -f /dev/nst0 tell >dd.report.$TAPENUM
# and, so it gets into the email
echo `mt -f /dev/nst0 tell`
# if that worked, we should have a current one
if [ -f dd.report.$TAPENUM ] ; then
# this next requires another dummy file as we must get rid of the *&$ 
period at the end of the tell
        cut -f1 --delimiter='.' <dd.report.$TAPENUM >dd.report1.$TAPENUM
        read TAPEAT TAPEBLOCK LOCATION junk <dd.report1.$TAPENUM
        rm -f dd.report1.$TAPENUM

# Now generate the two new files that correspond to this tape
        tar -cpsb 32768 -f indices.tar.$TAPENUM /usr/local/var/amanda
        tar -cpsb 32768 -f configuration.tar.$TAPENUM /usr/local/etc/amanda

# Now, do we have room on the tape for these?
# 119188 blocks for 3.9 gigs.  Diddle to suit your tapetype of course
MAXLOC=119180
# 119180=3.905290240 decimal Gigabytes so a 70 meg file should fit
        if [[ $LOCATION -gt 1 ]] ; then #its the right tape, wrong will be=1
                if [[ $LOCATION -lt $MAXLOC ]] ; then
                        dd if=indices.tar.$TAPENUM of=/dev/nst0 bs=32768
                        dd if=configuration.tar.$TAPENUM of=/dev/nst0 bs=32768
                        mt -f /dev/nst0 tell >>dd.report.$TAPENUM
                        echo `mt -f /dev/nst0 tell`
                else
                        echo `mt -f /dev/nst0 tell`
                        mt -f /dev/nst0 tell >>dd.report.$TAPENUM
                        echo "No room on tape for indices" >>dd.report.$TAPENUM
                fi
# with the above data, we can try to troubleshoot if it fubars.

# 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
                mt -f /dev/nst0 rewind
        fi
fi
cd ..
=========================================
and there is another line in the main script that advances the tape by 
ejecting it without the reload, so the tape is stored in its cassette 
when done instead of left cooking in the drive.  Minor detail, 
really.

The above generated this dd.report.nn file, where nn is the tape 
number:
=================================
DailySet1-15
At block 113210.
tar: Removing leading `/' from member names
tar: Removing leading `/' from member names
2125+1 records in
2125+1 records out
1+1 records in
1+1 records out
At block 115338.
amtape: changed to slot 3
===========================
To recover these files if they are written, I'll assume your drive is 
a full scsi2:
[amanda@coyote amanda]$ mt -f /dev/nst0 seek (to the 113210 obtained 
from the above report)

Now, as root, "touch /indices.15", and chmod it to 0777 so amanda can 
write to it.

[amanda@coyote amanda]$ dd if=/dev/nst0 bs=32768 count=2125 skip=1 
of=/indices.15
dd: warning: working around lseek kernel bug for file (/dev/nst0)
  of mt_type=0x72 -- see <sys/mtio.h> for the list of types

A "tar -tf /indices.15" indicates this file looks ok.

A fresh 'tell' says the tape is now at block 115335, and the end is at 
115338, so theoreticly another read of 3 blocks should get the last 
of it.  But its not working reliably.  By tommorrow I should have a 
better addendum on  that tape as this one wasn't specing the block 
size to tar till today, and all I can get is a maximum of tars 
default of 10240 bytes even though the config.15 file originally 
written is about 41k.  If that then works, I'll repost.  In the 
meantime this appears to be a useable method of making sure that 
uptodate indices are on the same tape.

Make of it what you want.. :)

-- 
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.