Error during tape backup..

[James Hamilton_2]

Hi,

we have a problem with our nightly backup to tape.

We are running an Oracle 7.3.4 DB on HP-UX 10.20. Each night a cron job fires under Oracle user which backs up all the database files and archive logs to tape. Essentially it copies all the files to a repository then archives this area off using TAR, having first checked we can access the mag tape. This is a condensed part of the script which does the TAR:

tar -cv $ARCHON /temp1/overflow/*.arc $CURRENT_ARCS /archive/a* >> $LOG 2> $TMPX

if [ $? != 0 ] ; then
echo "\nError during TAR" >> $LOG
else
echo "\nTAR succeeded\n" >> $LOG
fi

We are getting the following error reported prior to our 'Error during TAR' message:

'Can't open /dev/tty to prompt for more media.'

This seems to happen at a randomn point in the archiving process. Sometimes it happens after the first file, sometimes it gets about 75% of the way through. We have tried cleaning the drive, and using a new tape but this seemed to have no effect.

Things seem to point to the drive itself being dodgy, but before I make this conclusion I thought I'd check whether anyone else has a possible explanation for what we're seeing.

All input very gratefully received,

Cheers
James.

[Stefan Farrelly]

If youre absolutely sure that it sometimes happens very early in the backup when it simply CANT be possible the tape is full, then yes, your drive is returning an error to your tar command indicating a tape full when in fact its not full, so yes, I think your drive is faulty. Have you tried a new tape ?

Try proving it first using something different like gnu tar or fbackup to confirm even they sometimes ask for a new tape well before the tape is full.

[John Palmer]

You are hitting end of tape. Could be:

1. More data than normal.
2. Lower capacity tape than normal.
3. Bad tape causing lots of retries.
4. Bad tape drive ditto.

If the backup time is much longer than normal then suspect 3 or 4. As you've used a new tape then 4 is likely.

You're defaulting to /dev/rmt/0m which is likely to be a DAT drive. In my experience, DAT's do tend to wear out. If you've got a support contract, get the drive replaced.

As an aside, you'll get much better performance with tar to tape by specifying a larger blocksize, use -b 64 but note that you'll also have to specify this if you do a restore.

Regards,
John

[Stanimir]

Hi!
One possible reason for this could be,
that "tar" /even gnu-tar/ is not supported files > 2GB and crash,when find overhead.
And becouse you run script over cron, you
receive such message.
Anyway good alternative for your tape-backup
could be "fbackup".
Regards,Stan

[Eugeny Brychkov]

James,
great utility to check you drive and tape(s) at low level: HP LTT http://www.hp.com/cposupport/information_storage/support_doc/lpg50128.html
There's media test, compression test, perfomance test etc. Try it
Eugeny

[James Hamilton_2]

Wow, first of all thanks to everyone for the speedy responses.

When it only gets as far as the first file it ends by 01:30, when it gets 75% through it ends at 04:50. I guess this means that it is not repeatedly re-trying the write and eventually filling the disc, because then you'd expect it to fail at about the same time (not sure when the TAR starts since I don't know how long the file copy takes, but the cron job fires at ~00:05).

If the conclusion is that it is a faulty drive i need a quick fix for the short term (down-time on prod needs to be scheduled since system is 24/7).

We have a the disc cluster on the 'primary' machine mirrored on a 'secondary' machine. This machine also has a tape drive. The cluster is not mounted on the secondary (unless primary collapses!). Is there a way I can either run TAR on secondary to archive files on primary to it's local tape drive, or run TAR on primary to archive it's local files to the remote tape drive (a DDS drive BTW) on secondary??

Please go easy on me BTW, I'm just a developer who has been thrust into a sysadmin role since no-one else on site has any more clue than I do!

Thanks in advance,
James.

[Frank Slootweg]

I think you have a faulty tape drive, because as far as I can determine, a DDS tape can not be full in 1H25M (shortest is 1H54M for DDS-4).

You can backup the primary to a tape on the secondary. This can be done with tar(1), but it is easy to get that *silently* wrong. Since this is a one-time or few-times issue, I think it is best to make backup from SAM on the primary to the tape drive on the secondary. SAM internally uses fbackup(1M) to do the actual back.

Note: tar(1) is inappropriate for backup of important/costly data. At least use fbackup, and preferably an advanced backup product like HP's OmniBack.