DDS3 Tape drive problem

[James R Wilson]

Hi - I'm running SCO Openserver v5.0.5 and I have a DDS3 tape drive in the
machine, been running a regular backup each night for a couple of months
with no problems at all. Just recently, the backup routine has been
stopping at around 2040MB with a "cpio - cannot open /dev/rct0" error
message. The DDS3 tape drive should hold at least 12GB with no compression -
so what's the problem?

Anyone any ideas?

James R Wilson

[Jeff Hyman]

Put a tape in the drive and run:
# tape getcomp /dev/rct0
# tape getcomp /dev/rStp0 <- just curious
to confirm compression is actually ON.

Are you using DDS3 tapes?

- Jeff Hyman

[John DuBois]

In article <TUrf8.25269$jM1.203511@NewsReader>,

James R Wilson <ja...@betta.co.uk> wrote:
>Just recently, the backup routine has been stopping at around 2040MB

How do you determine that it's stopping at 2040MB? If you're using 'tape
amount', note that in the release you're using, as well as the current release,
it wraps at 4GB.

John
--
John DuBois spc...@armory.com KC6QKZ/AE http://www.armory.com/~spcecdt/

[James R Wilson]

"Jeff Hyman" <sco...@cactus.com> wrote in message
news:m16gYPb...@cactus.com...

Thanks for the reply - just tried that and it confirmed that compression was
off, decompression on.
I've set it to compression on now, but I still think that it should be
backing up more than 2.04 GB even with compression off?

> Are you using DDS3 tapes?

Yes using HP and Sony DDS3 tapes, all new and a different one each night so
it's not a tape problem.

>
> - Jeff Hyman
>
>

[Mike Copp]

"James R Wilson" <ja...@betta.co.uk> wrote in message news:<CrKf8.27625$jM1.229042@NewsReader>...

James,

We recently had this problem. Not only did we have the same error
message as you, but occasionally backup would start and not complete.
On the latter occasions, the tape wouldn't eject, and the cpio process
was sleeping too deep to 'kill -9'. We had to shutdown and reboot
before the tape would eject. If then left for cronsched to run the
nightly backup, it would fail again, so we always run this script
after rebooting:

find / -depth -print |cpio -ovcB -O /dev/rct0
2>/usr1/backup/last_backup

(where usr1/backup/last_backup is simply a log file)

then find the pid using something like:

ps -elf | grep cpio

give it 3 or 4 mins and then:

kill -9 *pid*

The backup then tended to run OK the next time or two, but would
always fail again at some point.

It was not a hardware problem (as we assumed), as we had the dds3
machine replaced 3 times and the motherboard(!) of the server
replaced.

Here's an example from the log:

Backup start: Sat Oct 27 01:30:00 BST 2001, 23492540 blocks, Finished:
03:26:20
Verify start: Sat Oct 27 03:26:20 BST 2001, 23492531 blocks, Finished:
04:59:45
Backup start: Mon Oct 29 18:10:52 GMT 2001, cpio: cannot open
</dev/rct0> for ou
tput., Finished: 18:10:53
Backup start: Tue Oct 30 01:30:00 GMT 2001, 23591690 blocks, Finished:
03:26:58
Verify start: Tue Oct 30 03:26:58 GMT 2001, 23591685 blocks, Finished:
05:00:50

So one day fine, the next fail, the next 2 fine, the next fail and so
on in a seemingly random pattern. We therefore thought it must be a
hardware problem. However, I removed a large number of redundant files
and managed to get the backup down to c17,000,000 blocks and we
haven't had the problem for over 6 months. It turns out that it really
was a problem with trying to cram too much data on to the one tape.

So please forgive me if I'm way out of line, but could you be mixing
up your blocks with your KBs or possibly miscounting in some way?

NB We've decided never to compress, as we believe that the chances of
a corrupt backup are increased, and in the event of a total system
failure, the backup could be useless.