Hiyas. Last night I was testing one of our shell script (not made by me) that is having some problems. What it does is that it backups some oracle data to tape and it is failing. I put the commands manually that it uses inside it to make the backup, in order to debug where it was failing. I ran the commands and it returned back, after like 12 hours, with the below error:
and thus I wonder what could cause cpio to do this? Also, it is _normal_ for cpio to take so much time for just 10GB ? The command I used was
Right now I am doing the same thing but with tar.. it seems to go a lot faster than cpio.

Thanks!

Ok. Apparently, the tar finished. But listing the tape contents only gives me three files, whereas they are more than 30.

The error message is pretty self descriptive. The kernel tried to write data to tape and the tape driver returned an error. If this used to work ok, it is probably a hardware problem most likely with whatever tape drive you are using. Your tape driver may have logged a message using whatever facility is available on whatever OS you are using. Depending on which model of what family tape drive you have, there may be some operator maintenance that could be tried such as cleaning the transport and/or read/write heads. Also the medium on which you were writing may be bad and you may be able to try another instance of that medium. That's about all I can do with this error report. Oh well, at least you let "tape" slip out. That's more detail than we usually get.

Thanks Perderabo. I forgot to include my unix version, sorry for that. It is HP Tru-64 v.5.1b. The media we are using is HP's DDS4, I believe it is 40GB compressed and 20gb uncompressed.

What can you say about the last part with tar ? what I did was this
there are like 30 files in total with over 9GB of data. Only three of these are shown when I list the tape contents. I will try with another tape now, as you suggested.

Thanks!

At first you had a slash in front of the dev. Now you don't. Which is it really? It makes a big difference. You are doing a v in cvf so it should display the filenames. Are there 30 there...and then only 3 with tvf? Or 3 both times? If 30 during the cvf and 3 during the tvf, which 3??? The first 3? The last 3? 3 random selections? Did you rewind the tape bewteen the cvf and the tvf? If so how? Did you try a cleaning tape?

That was a typo, it is /dev/tape/tape0. When I list the tape contents, it always returns the first 3 files that it tar'ed when using cvf. Please, see the attached file, so you can actually see the oputput. It doesn't seem normal to me.

Attached Files

backup_output.txt (27.3 KB, 3 views)

The main problem you have is that your tar program seems to have malfunctioned. 01032006aamcg.dat.Z has 9393 bytes but was recorded in 19 tape blocks. That means it had to use a blocksize of 512 writing 18 full blocks followed by one partial block. When tar reads a tape, it is supposed to figure out the blocksize. Your tar figured wrong. It picked 256 as it reported. I suspect that to be the problem. I don't understand how that choice is even possible. Blocksize is a multiple of 512. It has picked a blocking factor of one half or something like that.

Try specifying a blocking factor. 20 is considered a very safe choice.

tar cvbf 20 /dev/tape/tape0 *032006*
tar tvbf 20 /dev/tape/tape0

Since you are backing up .Z files, hardware compression won't buy you much. But you seem to think you're using hardware compression. A quick reading of the tru64 man pages suggests that you are not. /dev/tape/tape0c would be specifying compression. I got lost on the tru64 device naming docs and I can't test anything. You may or may not have other device naming troubles... I'm not sure.