Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

Register Log in
  • Congratulations gkittelson on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

SCO Backup on Compaq 12/24 DAT drive

Status
Not open for further replies.
wwalls

wwalls

MIS
Jan 7, 2002
11
US
I have a Compaq Proliant 1600 with a Compaq 12/24GB DAT drive. The system seems to be able to address this device, but I get errors while backing up and trying to read tapes. I have tried to set it up as a generic SCSI tape drive and also as a DAT drive (compressed and uncompressed). Neither is allowing a good backup. What are valid media values for block size and volume size for a DDS3 DAT Tape?

Thanks!
 
Sort by date Sort by votes
The defaults for a DAT should work fine with this- what sort of errors are you getting?
Tony Lawrence
SCO Unix/Linux Resources tony@pcunix.com
 
Upvote 0 Downvote
from cron I get
cpio: can't open device /dev/tty for writing
cbackup : Backup NOT recorded

Backup arg from Crontab:
30 19 * * * /usr/lib/sysadmin/cbackup 0 12000000 /dev/rStp1 /dev/root

block size I set from backup manager 1024
volume size 12582912 (12 GB in K)

When I issue a tape command or try to run a backup from backup manager the tape drive goes active and it appears to work, but asks me for more tapes. It should not need 4 12 GB tapes to backup about 6 GB of data.

Any Ideas?
 
Upvote 0 Downvote
Another question would be how are you trying to use the device? tar, cpio, other software?
On sco openserver 5.0.4 and 5.0.5, we have no problems with the compaq 12/24 dat's on proliant 800 / ml350 ...etc, when the devices work. (lots of infant mortality)

stan
 
Upvote 0 Downvote
Sorry posting at the same time.

that looks like it is having problems finding the right device.

cbackup does have a limitation of all items must fit on one volume.

try a "find..... | cpio .... > /dev/rStp1"
command on a test directory and see if it works.


stan
 
Upvote 0 Downvote
find..... | cpio .... > /dev/rStp1
find.....: not found


/dev/rStp1: cannot create

This is the result...
 
Upvote 0 Downvote
this is what I get with the tape status command.

# tape status
status : beginning-of-tape
soft errors : 0
hard errors : 2
underruns : 1
 
Upvote 0 Downvote
Your problem with /dev/tty is that you are running out of tape (I think you already know that), but if not, and for the benefit of someone who may come across this thread some other time, see
Otherwise

It looks to me like cbackup isn't configured correctly.

I would STRONGLY suggest using one of the Supertars anyway, and certainly for a quick test, downloading a demo is a good way to eliminate everything but cbackup.


Supertars:
I like the Microlite product myself, but all of them are good. Download a time limited demo- if that works, cbackup is definitely misconfigured.

And who knows- you might realize that these products are what you should be using anyway.. Tony Lawrence
SCO Unix/Linux Resources tony@pcunix.com
 
Upvote 0 Downvote
to stanhubble:

# cat /etc/default/tape | tail -2
device = /dev/xct0
curdriver=Stp1
#
 
Upvote 0 Downvote
I shouldn't be running out of tape. These are 12GB tapes and I have less than that used on my whole system. Have I set the media values wrong?
 
Upvote 0 Downvote
I don't know.

*Nobody* uses cbackup. That's an exaggeration, of course, but really: you won't find any professional person recommending that. Because it is so infrequently used, there could be all kinds of problems with it that most of us would never know or care about.

To eliminate hardware/tape/who knows prpblems download one of the supertar demos. If it works, you then *know* that cbackup is misconfigured somewhere. If not, those products can also give you a better idea of where the real problem is too.

Serously: do a Google search of comp.unix.sco.misc. You'll se what a mean: people who are serious about backup don't use the SCO supplied tools.
Tony Lawrence
SCO Unix/Linux Resources tony@pcunix.com
 
Upvote 0 Downvote
how about changing the settings in /etc/default/tar , the last line, and set device and media size. Then try a tar of the whole system to see if it will put the 6 gb on one tape. Tar cranks in extra stuff but not enough that the media should fill up. This will at least tell you that your settings are within reason. Ed Fair
efair@atlnet.com

Any advice I give is my best judgement based on my interpretation of the facts you supply.

Help increase my knowledge by providing some feedback, good or bad, on any advice I have given.

 
Upvote 0 Downvote
ok, let me see if i have this right...

-your second configured scsi tape drive is the default (xct0 = Stp1)
-but the device does not seem to be totaly present
(/dev/rStp1)
-so cbackup thinks it writes something hits an error and then needs another volume (if run from cron it won't ask)

what bothers me is the tape status result, the 2 hard errors. start with the obvious
-clean the tape drive
-use a different tape
-is the booted kernel the one with the device defined in it
-how do the device numbers look ( l /dev/| grep Stp )

Sorry about the find command in my earlier post, I didn't mean it as an example. It should have read:
find /tmp -print | cpio -ocvdumB > /dev/rStp1

tar and cpio will work just fine for testing purposes
( but i do agree with tony that the supertars are better for overall system backup and integrity)

- has this drive ever worked ?
- do you have other devices on the same scsi chain ?
- is the termination correct ?

I know, lots of questions but they should lead to an answer.....eventually

stan
 
Upvote 0 Downvote
I'm going to disagree a little bit about "tar and cpio will work fine for testing purposes". In fact, the Supertars (and I'll use Micolite as an example because I use that the most) can give you much more information about the tape than any of the built-in stuff can. For example, this model of tape is probably new enough to support TapeAlert, and Microlite can read that info from the drive- so it can tell you that the tape needs cleaning BEFORE the cleaning light comes on.

Also, the Supertars bit level verify is far more reliable than anything you can do with tar or cpio- with those, all a "verify" is checking is that the next header is where it should be- the rest of the data could be utter junk. he suprtars will catch that, tar and cpio will not.


There's also the matter of support for problems like this (and support for backup is pretty darn important). All of the companies have different models for support, but for example with Microlite email support is free- and they DO know their stuff because tape is what they do, day after day, year after year.

I'm going to stop beating that poor dead horse now (at least in this thread), but anyone who doesn't use one if these is being very very foolish. That's my opinion and I have been doing this stuff professionally for more than 20 years. If you check with other professionals, you'll find the same thing: some of us like Microlite, some like Lonetar, etc. but we all recognize the value and NECESSITY of this sort of backup.

(BTW, if you don't know about DVD-RAM backup, you should read )


Tony Lawrence
SCO Unix/Linux Resources tony@pcunix.com
 
Upvote 0 Downvote
I have become baffled. How can I completely remove all vestiges of this tape drive and re-install it?
 
Upvote 0 Downvote
I have removed the old tape config files and I had to use the information from caldera to completely clean up. I now have just one tape drive configured and it is responding to commands. Now i am getting buffer underruns and I/O errors writing the tape.

Can this be caused by bad tapes? Is it possible that the tape drive is toast?

Thanks for any input!
Walter
 
Upvote 0 Downvote
I'm sorry, that was SCSI data underruns, not buffer underruns.
 
Upvote 0 Downvote
says it's annoying but harmless.

I believe that it may be related to this and mayy possibly be fixed the same way:


Compaq controllers with HP tape drives may see

NOTICE: cha: SCSI bus has been reset ha=0
Attached SCSI peripherals will return to power up state
NOTICE: cha: Unexpected SCSI phase ha=0 id=6 lun=0


This is harmless but annoying. To fix:

1. cd /etc/conf/pack.d/cha

2. vi space.c

3. Search for "int cha_print_warnings= -1;"

4. Change it to "int cha_print_warnings=0;"

5. Relink the kernel and reboot for the change to take effect



Tony Lawrence
SCO Unix/Linux Resources tony@pcunix.com
 
Upvote 0 Downvote
Status
Not open for further replies.

Similar threads

ziggy6
  • Locked
  • Question
Trying to Install Openssl 1.1.1. on SCO 5.0.7
Replies
0
Views
618
ziggy6
ziggy6
singaaravelup
  • Locked
  • Question
Need help on UNIX
Replies
0
Views
590
singaaravelup
singaaravelup
mduddytel
  • Locked
  • Question
SCO Unix Smart-host problem (?)
Replies
0
Views
550
mduddytel
mduddytel
Bluejay07
  • Locked
  • Question
SCO password change text location
Replies
0
Views
512
Bluejay07
Bluejay07
Steve Bowman
  • Locked
  • Question
SCO Unix Bulk Process Killer 1
Replies
1
Views
539
Salem
Salem

Part and Inventory Search

Sponsor

Back
Top