SUMMARY: DLT capacity

From: Rich Quinn (rquinn@sss.sight-n-sound.com)
Date: Thu May 18 2000 - 00:54:23 CDT


Sorry about that, forgot to post this as a summary:

Hi,

It appears that the right answer is to simply do without the density
and size options in my ufs command. As Solaris is smart enough now
to figure that all out. Including the density and size worked before,
but not now. That is fine.

Thanks to David, Cesare, Ray, Steve, Rahul, Chris, and Peter for their help.

So my new backup command is:
ufsdump 0bfun 126 bigbird:/dev/rmt/0cn /usr2

As opposed to:
ufsdump 0dsbfun 54000 20000 126 bigbird:/dev/rmt/0cn /usr2

Thanks again to the list for the quick replies,

Rich

My original post:
============================================================================
==========================
Hi,

I have a network of sun sparc machines running 2.5.1, 2.6, and 2.7.
I back them up via a ufsdump script that gets kicked off by cron.

The tape drive is a DLT 7000, and the tape is a DLT4.
The tape can hold up to 35 gig native and 70 gig compressed.
I'm doing a level 0 backup once per week for each machine.
This comes out to about 40 gig.

We just added a machine with 16 gig of filesystem space.
It is an E420 (named oscar) running Sol 7. The command to backup its
14 gig filesystem(/usr2) to our backup server (bigbird) is:

/usr/sbin/ufsdump 0dsbfun 54000 20000 126 bigbird:/dev/rmt/0cn /usr2

However, I keep getting an error about 1/4 way through the backup about the
end of media being reached. This shouldn't happen as the /usr2 filesys is
only
14 gig long and the tape can hold 70 gig.

I did an mt rew, an mt erase, and another mt rew to put the tape back to
the start and I still get an error about reaching the end of the media.
Here is what the transaction looks like:

____________________________________________________________________________
_________
# /usr/sbin/ufsdump 0dsbfun 54000 20000 126 bigbird:/dev/rmt/0cn /usr2
  DUMP: Writing 63 Kilobyte records
  DUMP: Date of this level 0 dump: Wed May 17 18:25:19 2000
  DUMP: Date of last level 0 dump: the epoch
  DUMP: Dumping /dev/md/rdsk/d12 (oscar:/usr2) to bigbird:/dev/rmt/0cn.
  DUMP: Mapping (Pass I) [regular files]
  DUMP: Mapping (Pass II) [directories]
  DUMP: Estimated 30251052 blocks (14771.02MB) on 2.40 tapes.
  DUMP: Dumping (Pass III) [directories]
  DUMP: Dumping (Pass IV) [regular files]
  DUMP: 21.89% done, finished in 0:35
  DUMP: End-of-tape detected
  DUMP: 43.46% done, finished in 0:25
  DUMP: Change Volumes: Mount volume `#2' on `bigbird:/dev/rmt/0cn'

Message from the dump program to all operators at 18:45 ...

CHANGE VOLUMES!
  DUMP: NEEDS ATTENTION: Is the new volume (#2) mounted on `bigbird:/dev/rmt/
0cn' and ready to go?: ("yes" or "no") yes
  DUMP: Warning - tape positioning error!
        /dev/rmt/0cn current file 2, should be 1

Message from the dump program to all operators at 18:45 ...

DUMP IS AILING!
  DUMP: NEEDS ATTENTION: Do you want to attempt to continue? ("yes" or
"no") yes
  DUMP: Volume 2 begins with blocks from inode 1949432
____________________________________________________________________________
_____________

Bear in mind that though the backup is asking me for a new tape, I don't
switch tapes.
I simply leave the original one in the drive and answer "yes" to the
prompts anyways.

The backup will continue until it asks me for another tape once again.
I give the same answers and then the backup completes.

The whole backup is only 14 gig, I should not need to put the backup over
the course of 3
70 gig tapes. Should I be changing the density, the block size, or
something else? 126 is the
max block size as far as I know. The size itself(20000) is more than
enough for a DLT 4
tape(which is about 1800 feet long).

Any ideas?

thanks,

Rich
===========================================================================



This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:14:08 CDT