Tar: tape error (5) on tar rv but not tar cv

[Ian Lochray]

Our back up script can either back up everything at once with a tar cv command or else back things up in stages with an initial tar cv to a non rewindable tape device followed by an series of mt rew and tar rv commands. The script does lots of other stuff and is cross platform so it is not practical to change the way it works in the short term.
My problem is that the single tar cv command works all the time on one server but if I use the second method it always fails on the first tar rv command. The error is:
Tar: tape error (5) and $? is set to 1.
Any ideas? If it is a dodgy tape/drive then why does the first method work?

[Michael Tully]

You haven't really mentioned too much about changing the media, so I'm going to assume you have. Try cleaning the drive and trying again. Tapes drives do not last forever, in fact getting 12 months out of one is not too bad either.
The first method probably works because the tape is continuously streaming and not looking do to do file markers.

[Stefan Farrelly]

Its in the manpage for tar, you cant use the r option to append if the tar image is on a tape. You can only use the r option to append if the tar image is on disk or a network drive.

[Tim Adamson_1]

Are there any messages in syslog?

It could be a bad drive a bad tape or a bad controller. Need to eliminate the controller by checking syslog for errors.

Change the tape and try again to test the tape problem.


Tim.

[Michael Tully]

Stefan is quite correct, the -r option is not available for tapes. The man pages states "This option cannot be used if the archive is a tape."

If you wish to do this type of backup then 'cpio' would be an alternative.

[Ian Lochray]

The thread http://forums.itrc.hp.com/cm/QuestionAnswer/1,,0x042306350fe2d61190050090279cd0f9,00.html indicates that the tar rv restriction on tapes is only relevant for a few types of tape drive which does not include the one I am using.
The syslog shows that there is a SCSI lbolt error at the same time as the tar failure.

[Stefan Farrelly]

I dont think its completely supported. Ive tried it on a couple of my servers with DDS drives and it doesnt work - keep getting tape read error.

Your scsi error doesnt mean you have a hardware problem, it depends on your level of scsi patches. Are your scsi/stape/tape2 drivers and the tar binary uptodate ?

[Bill Hassell]

The errno 5 error indicates that the tape drive is unable to complete the I/O due to errors. If it was during a write operation, something failed during the tape's built-in checks, or during read, it is likely due to parity errors or reading unwritten areas of the tape. It is possible that the script is asking the drive to read an area of the tape that was not recorded. For DDS drives, this isn't really possible (without a power fail) but for other drives, the tape may have been positioned past the end of valid data and has been asked to read 'noise' on the tape.

The difference in the methods probably has to do with the actual tape position. NOTE: The default tape device file (/dev/rmt/0m) is an AT&T device with what can be best be described as bizarre behavior. Refer to the mt man page for warnings where you'll see that the Berkeley device file is required to get the expected behavior. AT&T closes the drive and automatically positions to the beginning of the current file regardless of the no-rewind option.

[Michael Tully]

Bill, your incredible! Thanks for the fantastic information, many people including me can learn from this.
Cheers
Michael

[Volker Borowski]

Hi,

negative experience with tar-append, but feel free to correct with your experience....

I tried around with the append to archive option and one thing I never managed was to restore a file, that had been appended multiple times with easy selection criteria.
Throughout the append, the content of the previous stored data is not checked (as far as I tested). So you could append as often as you like a file to an archive, and when listing the inventory you found it is all in the archive.
So if you create on Monday and append on Tuesday through Friday, you will have 5 files in the archive (tar is behaving diffrent from ar, which will handle this by replacing the file if it exists), from which you only would be able to restore Monday (when specifying the name for restore -> first hit and stop) or Friday (restore the entire archive and get the file five times overwritten) or, if you have flink eyes, quick finges and a working crtl-c trap, catch Tuesday or Wendsday in between on a full restore. Nothing to be handled real good.

Why not opening a new fileset ? Use cv multiple times and the no-rewind device and no mt upon save.

Getting Inventory ?
tar tv
tar tv
tar tv

restoring ? I.e.

mt fsf 4
tar xv

Did anyone came across this and found a solution to restore the 4th stored ./usr/myfile of 6 in a tar-archive ?
I tried this with 9.04 and early 10.10 but I think tar is not evolving very rapidly any more :-)

So from my experience, I would suggest not to use append to tar-archives. Go for seperate archives on a norewind device.

Hope this helps
Volker

[Ian Lochray]

The answer was a dodgy tape drive. The drive has been replaced and it all works fine now.