DDS2 works, DDS4 & DAT72 fail, replaced everything, why?

[libove]

Networker 7.3.2 build 364 on a P4 Windows Server 2003 SP1 system, all Windows patches applied (except .Net Framework v3.0).

Java Runtime Environments loaded are:
1.4.2_13 (not enabled)
1.5.0_11 (enabled)
1.6.0_01 (not enabled)

Two SCSI tape drives installed:
Seagate/Archive Python 02779 DDS2 4mm 4G/8G DAT
Seagate/Certance DAT72 052 DDS5 4mm 36G/72G DAT
(tried both MS Win2003 default DAT tape driver, and Quantum 1.14.3.0 DAT tape driver)

Two SCSI controllers installed:
Atto Tech UL2D (MS Win2003 default LSI Logic 53C896 driver)
Adaptec 2940UW (MS Win2003 default driver)

This server formerly would reliably run backups to a pair of DDS3 and then later a pair of DDS4 tape drives, along with separate backups to the DDS2 drive. A few months ago, errors started increasingly creeping up on the DDS4 drives until they became so unreliable as to be useless. I tried a separate Atto Tech UL2D controller, then replaced the two DDS4 drives with the new DAT72 drive. I moved the DAT72 drive from the external storage box where it and previously the DDS4 and DDS3 drives had worked) to an internal bay, to eliminate the power and external cabling as a source of trouble. I switched the DAT72 drive from the UL2D controller to the 2940UW controller.

Nothing worked. I can't even label a tape in the DAT72 drive. (Tried several brand new tapes in this drive, as well as a range of DDS4 tapes in the older pair of DDS4 drives).

The DDS2 drive still works fine.

Since I've eliminated the controller, the tape device driver, the tape device, the power supply, and the cabling, it appears that the only remaining possibility is some kind of incompatibility between post-DDS2 devices in this O/S and Networker 7.3.2 configuration.

The Windows Event Log shows bad block errors on all attempts to write to these DDS4 or DAT72 drives. The same occurs with Windows NTBACKUP also.

With all of the changes I've made, it seems highly unlikely that I have *five* bad drives (two DDS3, two DDS4, and a DAT72) and dozens of bad tapes (DDS3, DDS4, DAT72) and three bad controllers (two UL2D and one 2940UW) and two bad tape drivers (Windows default DAT driver and Quantum DAT driver)... It isn't specific to Networker 7.3.2, though I suppose it could just possibly be something that 7.3.2 put on the system. I'm guessing it's more likely to be something updated in some Microsoft patch a few months ago.

Any advice on how to diagnose this?

Thanks!
-Jay

 

[605]

If it is a read problem, then your trouble already starts when a backup software tries to verify an existing label as first step during the labeling process.


The first step i would take is to run the NW tape test utility "tapeexer.exe".

As a second step, i would stop NetWorker and use Windows ntbackup. Because NW does not use anything else but the OS - if they come up as well, then it is likely not a NW problem.


And do not forget to disable RSM and to set it to disabled. Otherwise it may restart when you search for new hardware.

 

[libove]

NTBACKUP has the same problem, as noted above.
RSM is set to Manual, and does not auto-start even when new hardware is detected.

I realize this is not specifically, or at least not obviously, a Networker problem. I appreciate any attempts to help.

Any other ideas?
Thanks!
-Jay

 

[Rif123]

Hi,
If the problem also exists with other applications it won't be a NetWorker issue. As long nt backup or any other apps doesn't work, NetWorker will not work eiter. You can have a look at the tape.sys file that was updated by Microsoft and made sure some people got new problems since it restricts the block size to 64kb.

Here is an articel:

http://support.microsoft.com/kb/907418/en-us

You can always try the pre SP1 tape.sys and see if that solves your problem.

 

[libove]

I applied Windows Server 2003 Service Pack 2 (which includes the updated tape.sys intended to address the performance problem referenced by Rif123 - thanks), and it did not correct the problem. Sigh.

Any other ideas folks? I really do appreciate your help, even though this (probably) isn't a Networker specific issue.

Thanks
-Jay