It is all Windows 2000 SP4 SAN environment.

Library is SCSI & uses an MDR to get connected to FC Switch.

I am not able to isolate whether this is form library or MDR.

We have not tried NT backup and this does not happen for all tapes ex. our backup should end in two tapes + 10-15 GB of third tape but it marks third, fourth & fifth tape full and ends up in the sixth tape. First day when we had labelled only three tapes, it marked third tape & kept waiting for a writable volume.

Would CDI enable/disable help?

This is Windows 2000 server operating system.

The way devices are handled in 6.x and 7.x is completely different... first you had CDI introduced, then reservation and daemon looking over state of library, etc. So difference is there. However if you already had resets then those things had to be addressed. What happens if you try NT backup? Btw, do you get resets for each tape each time?

Hi Anuj,

What is your OS, HBA, Driver Ver?

I'm asking this because this kind of problem doesn't look as a NetWorker error, it's look like a environment problem (SAN or physical problem). NetWorker doesn't have a internal driver, so he depends from the OS to have access to the Driver that controls the Tape Drive. Please verify your library to see if it has some logs with errors, firmware, tape drive; Verify the OS, HBA firmware, HBA driver, switch logs ( SAN ?), driver version and verify if exists another program that can access the tape ( OS backup program as a example).

You can try to disable CDI - some older technologies don't cope with that well. But it sounds as there is something else there... I guess RSM is off... if you still get the same, try NT backup and see if you can reproduce the issue.

RSM is ON but on both setups.

Should that cause I/O bus resets.

No idea, but it causes headache that's for sure. Based on past experience I would suspect MDR as those devices almost always caused some kind of issue - I have rarely seen environment without troubles being related somehow to MDR. However, I would make sure RSM is off here as first step. Second I would test it without CDI and then if error persists I would test it with NT backup too.

RSM was ON with NW 6.x also so we thought we will go ahead with it.

I doubt. I think whatever caused I/O is causing now more I/O bus resets because NW tends to check and listen for status and health of library and devices. That is not NW problem.