Fbackup Failure - Return Code 2

[paula hawk_2]

We have automated backups via sam running nightly. I have been receiving a return code of 2 which means fail. A script that runs and checks the SAM_br_msgs log for bad tapes is also returning that the tape is bad. I manually kicked off a backup via sam for the /tmp file system and was successful. I tested backing up /stand file system and received the following error. Once aborted I retried /tmp and was successful again. Tested backing up / and received the same error as /stand. Can anyone help?

fbackup(3045): WRITE ERROR while writing data record, at media record 45
fbackup(3102): attempting to make this volume salvagable
fbackup(3123): could not read the previous checkpoint record
fbackup(3105): writing 2 EOFs and rewinding the tape
fbackup(3106): please mount a good tape
fbackup(3316): enter 'yes' when volume 1 is ready on /dev/rmt/c1t0doBEST


thanks....paula

[Cheryl Griffin]

The difference between backing /stand vs /tmp is that /stand is very large. fbackup has some overhead when attempting to write. Check bdf to see if you have a filesystem full condition.

The 3045 is also a on a Write which indicates a HW problem. There may be a bad spot on the tape? Could be that the /stand write hits the bad spot.

Try another tape.
Also check /var/adm/syslog/syslog.log for other SCSI or tape related errors.
Run dmesg to see if there are errors there as well.

Cheryl

[steven Burgess_2]

Hi Paula

Whats the media usage ? You can check this by looking at the tape header

frecover -V `tty`

Have you checked the cleaning light is not on , on the drive itself ?

I have had many occasion where a test backup is ok but when attempting multiple filesystems it fails

If the drive is clean and the tapes are new you may need a new drive

HTH

Steve

[Hai Nguyen_1]

Paula,

Was there any change in blocksperrecord recently? I got an excerpt from the fbackup manual which describes the same symptome you encountered:
....
When configuring the parameter blocksperrecord (see -c option), the
record size is limited by the maximum allowed for the tape drive.
Common record sizes include 128 blocks for DLT and DDS tape drives,
and 60 blocks for the HP7980. Note also that the blocksize used in
earlier releases (7.0 and before) was 512 bytes, whereas it is now
1024 bytes. This means that the same value specified in
blocksperrecord in an earlier release creates blocks twice their
earlier size in the current release; for example, a blocksperrecord
parameter of 32 would create 16-Kbyte blocks at Release 7.0, but now
creates 32-Kbyte blocks. If blocksperrecord exceeds the byte count
allowed by the tape drive, the tape drive rejects the write, causing
an error to be communicated to fbackup which fbackup interprets as a
bad tape. The resulting write error message resembles the following:

fbackup (3013): Write error while writing backup at tape block 0.
Diagnostic error from tape 11...... SW_PROBLEM (printed by driver on console)
fbackup (3102): Attempting to make this volume salvageable.
etc.
....
Hai

[Hai Nguyen_1]

Paula,

Based on your fbackup output, you may want to try to back up using a new tape as well.

Another way to test is to back up to /dev/null to see if you run into any error. If not, then definitely your problem is related to either backup equipment or media.

Hai

[paula hawk_2]

THis is a remote location so I can not see if the tape light is on or not. I am going to have the user clean the drive and then try manually running a back up. If I still receive the error I am going to have the tape drive replaced. THanks to everyone for the quick responses.

[Stefan Farrelly]

Normally this error is a tape media error. Try a new tape first, only if it recurrs then have the drive replaced.

[Paul Thomson_2]

Have also found, one instance of this over a week is a poor tape. Consistent failures would indicate the drive is at fault.

You could perhaps further test the drive using
/etc/frecover -xv -N -i /tmp -f /dev/rmt/0m >> outputfile 2>&1 &


This will make sure the drive can also read the contents. If this fails to, I would seriously think your drive could be at fault.