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: [EMAIL PROTECTED] 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. [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 320M [EMAIL PROTECTED] 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.