corrupt file and tape backup

[simanek]

has anyone heard of a corrupt file making a 'backup' fail? for some reason, i can perform a backup on 3 of my 4 logical volumes but the 4th one is failing with a 'media error' 0511-079. i'm using smit to perform the backup and i know it's not a bad tape or drive (since i can backup the other 3 just fine). any ideas as to why this might be happening? thanks. Mike
~~~~
simanek@illinoisalumni.org
"It's a Swingline!"
~~~~

 

[Chapter11]

What device is errpt reporting the media error on?

It could still be the tape - the spot on the tape where it might be bad is probably not far enough for the first 3 to get to it.

 

[simanek]

the exact message is:
the backup media may be damaged. Use a different disk to run the backup.

it can't be the tape as I have tried with several different, brand new ones and if fails in the same spot every time. Mike
~~~~
simanek@illinoisalumni.org
"It's a Swingline!"
~~~~

 

just wondering what logical volumes are that. which is failing ?

 

just wondering what logical volumes are that. which is failing ?

 

[bonsky]

try this one bro, this might help you in a way.

0511-079 The backup media may be damaged
Possible Causes
>>From the command line, you issued the backup command naming a tape device with the block size set to 0, but specified a value with the -b flag that is larger than the maximum allowable write size for the tape device.

>>From the command line, you issued the backup command naming a tape device, but specified a value with the -b flag that does not yield a whole number multiple of the tape device's physical block size.

>>From the command line, you issued the following command:
find File -print| backup -ivf FileSystem/FileName
but the specified FileSystem was full.

>>The backup media is damaged.

Procedures for Recovery
>>Specify a value with the -b flag that does not exceed the maximum allowable write size for the tape device, or do not use this flag.

>>Specify a value with the -b flag that yields a whole number multiple of the tape device's physical block size (-b Number, where Number is the number of 512-byte blocks).

Note: You can use the lsattr command to check the physical block size of the device:
lsattr -l rmt# -E

Remove unnecessary files from the file system, or use the chfs command to increase the file system and rerun the backup command.

Check the error log for media errors:
errpt -a

>>Use a different tape or disk to run the backup

 

[TSch]

Maybe you are using the wrong tapes for your drive...

E.g. Look at your tape. If it's gotten DDS 3 printed on it you can only use it with the proper tape drive and if the tape drive says DDS 1 or something else, then it won't work...

 

[simanek]

nope, tapes are the right kind. and i'm using smit to perform the backup, so the command line stuff wouldn't apply. good thoughts though. Mike
~~~~
simanek@illinoisalumni.org
"It's a Swingline!"
~~~~

 

[Chapter11]

I had a client who had a similar problem, even with new tapes, it would fail at the same time. We ended up getting them to have IBM replace the tape drive.

 

[aixqueen]

Well you could do the mksysb to /dev/null to rule out no logical volume corruption...
with the results being sent to a file..... that way you would see if it is the tape drive or tape vs a logical volume that needs an fsck...........

I think it would be something like

mkszfile && mksysb /dev/null 2>&1 /tmp/logfile
(this should come back quickly with an either ok or fail. It will put errors in the logfile)

 

[DSMARWAY]

ALso as bonsky states about block size setting it to 0 ,

what is the block size of your tape device set to .
( lsattr -El rmt? ) if not 0 , set it to 0 and when you backup your filesystems /LVs , specify the block size here.