External Event Caused Rewind During Write. Status 84 Media Write Error

[dslam24]

I am running Netbackup version 6MP2. I get the error
Freezing Media ID XXXXXX External Event caused rewind during write, all data on media is lost.

I am using Windows Server 2003 as the Master Server. With a 30 tape robot, with two Sony SDX 500C drives.

I have pinpointed the time when this happens. It occurs at the end of the tape. It will not pick up the next tape to continue writing, it gives me the error above. It almost sounds as if it rewinds the tape at the end, i'm not sure if this is normal or not though. After it fails it unloads the tape and picks up the backup catalog tape and backs up the catalog with a status of 0. Any backup under 50gb finish succesfully, this is because the capasity of the tapes is 50gb.

I do have "allow backups to span media" checkmarked so thats not the problem.


I can get succesfull backups if i back up the data to a single virtual tape(1.7 Terabytes)

Any ideas on this?

Things I've already done--
-updated the drivers for the drives using veritas drivers
-disabled the 'removable storage' service in netbackup
-removed and readded the drives several times

[Stumpr2]

Is this still a problem?
Have you contacted VERITAS support?

Have you set up the debug log for bptm?
...and if so are there any hints in the logfile?

[dslam24]

As of last thursday it was still a problem. I do have an open ticket with veritas. They suggested I update the firmware on my drives. Unfortunately we have drives from CYBERNETICS (They SUCK) so instead of downloading and updating it in 20 minutes, I had to send them in.

All i'm seeing in the logs is that after the tape reaches the end it rewinds and then fails...

I will post back when the drives return and I get them connected again.

[dslam24]

I got the library back a full week after it left, and...the problem continues. They upgraded the firmware on the library and the tapes but it is doing the same thing. The finger pointing between hardware vendor and software vendor has resumed.

The only other thing I can think of at this time is that the library has outdated drivers. It is a Spectra 2000, from Spectralogic but I cant find any new drivers for it. I went to their website and all I see is firmware upgrades.

[zippy]

What tape device are you using?

/dev/rmt/c22t3d1BESTnb

Only raw, no-rewind Berkeley-type devices should be specified. This
type of device will not reposition the tape upon close. An example of
such a device is /dev/rmt/0mnb.

Do you have span tape set, maybe Bob knows where to set that.

Has this ever happend before 6.x?

Does it happen on all backups?

Would you like to unfrezz em?
/usr/openv/netbackup/bin/admincmd/bpmedia -ev $LOGLINE -unfreeze

Would you like to see if you have a valid image?

type ./tar +help in the /usropenv/netbackup/bin dir..

JD

[dslam24]

Tape drives are Sony SDX-500c.

Allow backups to span media is set. This started happening after we installed NBU 6.x. Everything was working fine on 4.5(Different Server)

[Stumpr2]

Check the attributes for the media server
do you have checked "Enable SCSI reserve / release

[dslam24]

That option is enabled.

Here is what I am testing now...

http://support.veritas.com/docs/281312

This is not the same error I'm getting nor is it the same hardware, BUT it is a media error which veritas says, are 99.9% usually caused by hardware(who knows) and it is the same type of drive (Sony SDX) and the same brand of changer, Spectra Logic.

I'm testing now to see if this helps.

[dslam24]

No GO! on my attempt with the NO_SIXTEEN_BYTE_NDB file.

[dslam24]

Sorry on my last post. I misstyped the file name...it is actually
\Volmgr\database\NO_SIXTEEN_BYTE_CDB
Obviously from the link I posted....

The latest news on this is that, the case has been escalated to the engineering dept. at veritas!

[dslam24]

I have resolved my problem.

Along with our library we have this controller that has an LCD display and it shows what the library is doing, Loading, Unloading, Rewinding, BOT, how much is left on your tape, etc. That unit has always been there for years, in fact I thought it was necessary for the library, but the library also had two SCSI ports.

As a last ditch effort, I bypassed that controller connected the SCSI cable directly from the server to the library and "TA-DA" it worked. I dont think our extra controller is bad because it used to work fine when we had v4.5FP6, I just think it's some sort of incompatability with version 6.

This would explain why when I sent the library in to have the firmware updated they didnt find any problems. They probably didnt use a controller board like ours.

So now things are working fine and we have another useless piece of equipment.