Hi Gurus,
I'm trying out the solutions provided,but still thought would summarise before
U guys come with guns..:)) (I'm really scared seeing all those threatening mails
if you don't summarise..):((
Will surely send my inference & I thank you guys for responding..
************************************************************************************************
Original question:-
Hi Gurus,
We have a 8mm mammoth tapedrive attached to our enterprise 4000,with
20-40GB
compressing capabilities.We had a 14-28GB compression 8mm Exabyte tape drive
before & it used to eatup 8-9 tapes for our backups.But after enabling
compression (as per the notes from this mailing list),still I'm ending up using
the same number of tapes.I am wondering if I'm missing any settings in my
script.
I would appreciate if someone would help with the options I'm using for the
existing backup script.
This is the part of the script to give you an idea..
DAY=`date +%a`
TAPE_DRIVE="/dev/rmt/0c"
NR_TAPE_DRIVE="/dev/rmt/0cn" # For no rewind
DUMP="/usr/sbin/ufsdump"
HOSTNAME=`uname -n`
# Let's figure out how many tapes we will need.....
#
LOGFILE=/back/bklog
NUM_TAPE=1
TOTAL[$NUM_TAPE]=0
FS_SLICES[$NUM_TAPE]=""
NUM=""
SLICE=""
$DUMP 0unbsdf 126 26000 54000 $NR_TAPE_DRIVE $SLICE >> $LOGFILE 2>&1
else
echo "Daily incrementals - running level 5 dump...\n"
$DUMP 5unbsdf 126 26000 54000 $NR_TAPE_DRIVE $SLICE >> $LOGFILE 2>&1
fi
Please letme know in case U needed more info..
***********************************************************************************************
Possible Solutions:-
1.Niall O Broin
Hi,
Your problem is in your ufsdump command line
$DUMP 0unbsdf 126 26000 54000 $NR_TAPE_DRIVE $SLICE >> $LOGFILE 2>&1
If you instead use
$DUMP 0unbf 126 $NR_TAPE_DRIVE $SLICE >> $LOGFILE 2>&1
you will use your tape more efficiently. When you give ufsdump s & d arguments,
it uses these to calculate the size of the tape volume, and when it decides that
it's dumped enough, it tells you to change the tape. So, if you had added in a
tape drive with 200GB capacity, you still wouldn't have been using it
effectively
with these parameters.
ufsdump under Solaris (as against dump SunOS) is smart enough to know when it
has
reached the end of the tape and to ask you for a new one.
For fuller details, see the Sun Managers' FAQ (which you get regularly) which
has a
section I wrote on these dump parameters and what they amount to.
Also note that to use the maximum capacity of your tape drive you should make
sure
that you have an appropriate entry in the system file /kernel/drv/st.conf
I don't have that information - check with your vendor, Exabyte's WWW site or
the
Sun Managers' archive.
2.Jim McVey
Did you update your st.conf file when you setup the new drive? I had to
modify mine. Here's what I currently have:
"EXABYTE EXB-8900", "Exabyte 8mm EXB-8900", "EXBT-8MA";
EXBT-8MA = 1,0x35,0,0x1ce39,1,0x27,0;
It was also suggested to try:
EXBT-8MA = 1,0x29,0,0xde39,1,0x7f,0; instead of the line above.
I haven't tried it yet.
Don't forget to reboot after you make the change.
Using this and /dev/rmt/0cn I'm getting compression on my tapes. However,
I'm only getting about 25-30G. Sun told me that was probably as good as
it was going to get. :-(
Hope this helps.
3.Joel Lee
That's very strange. Do you have st.conf modified with the following ?
tape-config-list=
"EXABYTE EXB-8900","Exabyte Mammoth","mam-data";
mam-data = 1,0x29,0,0x1de39,1,0x7f,0;
4.Brion Leary
Try it without specifing the tape length.
eg. use
ufsdump 0unbf 126 $NR_TAPE_DRIVE $SLICE >> $LOGFILE 2>&1
Solaris 2.4+ defaults to denisty 5400 and can see end of tape.
5.Bismark Espinoza
You may need new entry in the scsi kernel files
or try /dev/hcn.
***********************************************************************************************
best
-- Chenthil Kumar LUCENT TECHNOLOGIES NJ-07748,USA chenthil@lucent.com
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:12:33 CDT