Forum Discussion

Marcopolo's avatar
Marcopolo
Level 6
13 years ago

Constant DLT-S4 problems

We've been using DLT-S4 for approx 12 months (We're running 2010 R3 tape drivers are Symantec 5.1.25.0)

Last year, around Feb '11 we started getting backup errors and Quantum replaced our unit, this immediately sorted the problem.

2-3 months after the replacement, it started happening again (Nov '11). Again Quantum replaced the unit and this immeditely solved the problem.

Last week it started to happen again

These are the errors from the Server 2003 Application log in Nov '11

[0744] 11/22/11 04:48:04 Adamm Mover Error: DeviceIo: 03:00:06:00 - Device error 1117 on "\\.\Tape0", SCSI cmd 0a, 1 total errors

%2

%3

%4

%5

%6

%7

%8

[0744] 11/22/11 04:53:04 Adamm Mover Error: DeviceIo: 00:00:06:00 - Retry Logic: Retry logic was engaged on device: QUANTUM DLT-S4

%2

%3

%4

%5

%6

%7

%8

[0744] 11/22/11 04:53:04 Adamm Mover Error: DeviceIo: 03:00:06:00 - Refresh handle on "\\.\Tape0", SCSI cmd 00, new handle 5d8, error 1117

%2

%3

%4

%5

%6

%7

%8

[0744] 11/22/11 04:56:50 Adamm Mover Error: DeviceIo: 00:00:06:00 - Retry Logic: Failed to space to end of data on device: QUANTUM DLT-S4

%2

%3

%4

%5

%6

%7

%8

Storage device "QUANTUM DLT-S4" reported an error on a request to write data to media.

Error reported:

The request could not be performed because of an I/O device error.

.

For more information, click the following link:

http://eventlookup.veritas.com/eventlookup/EventLookup.jhtml

Adamm Mover Error: Read Failure!

Error = ERROR_CRC

Drive = "QUANTUM DLT-S4"

{1C2EC5DC-66D9-4335-8A0A-C3142A70EC07}

Media = "DLT000117"

{BFDE18A4-F4A6-4F17-852B-A9475AD7BC50}

Read Mode: SingleBlock(0), ScsiPass(0)

Write Mode: SingleBlock(1), ScsiPass(1)

Storage device "QUANTUM DLT-S4" reported an error on a request to read data from media.

Error reported:

0x17.

For more information, click the following link:

http://eventlookup.veritas.com/eventlookup/EventLookup.jhtml

Backup Exec Alert: Job Failed

(Server: "TIMOR") (Job: "Daily to SDLT v3 (Full)") Daily to SDLT v3 (Full) -- The job failed with the following error: A hardware error occurred.

 

For more information, click the following link:

http://eventlookup.veritas.com/eventlookup/EventLookup.jhtml

These are the errors from the Server 2003 Application log in from the past couple of days.

 

[0656] 01/14/12 01:09:09 Adamm Mover Error: DeviceIo: 03:00:06:00 - Device error 1117 on "\\.\Tape0", SCSI cmd 0a, 1 total errors

%2

%3

%4

%5

%6

%7

%8

 

[0656] 01/14/12 01:14:09 Adamm Mover Error: DeviceIo: 00:00:06:00 - Retry Logic: Retry logic was engaged on device: QUANTUM DLT-S4

%2

%3

%4

%5

%6

%7

%8

[0656] 01/14/12 01:14:09 Adamm Mover Error: DeviceIo: 03:00:06:00 - Refresh handle on "\\.\Tape0", SCSI cmd 00, new handle 6bc, error 1117

%2

%3

%4

%5

%6

%7

%8

[0656] 01/14/12 01:20:10 Adamm Mover Error: DeviceIo: 00:00:06:00 - Retry Logic: Failed to space to end of data on device: QUANTUM DLT-S4

%2

%3

%4

%5

%6

%7

%8

Storage device "QUANTUM DLTS4" reported an error on a request to write data to media.

Error reported:

The request could not be performed because of an I/O device error.

.

For more information, click the following link:

http://eventlookup.veritas.com/eventlookup/EventLookup.jhtml

Backup Exec Alert: Tape Alert Error

(Server: "TIMOR") (Job: "Daily to SDLT v3 (Full)") Job 'Daily to SDLT v3 (Full)' has reported Multiple Tape Alerts on Server 'TIMOR'. Please refer to job log BEX_TIMOR_08078.xml for more details.

For more information, click the following link:

http://eventlookup.veritas.com/eventlookup/EventLookup.jhtml

We've changed nothing, Servers do not auto update but this is starting to become annoying.

Although the errors seem very similar, here's what BE reported in the log failure for the past three days

Job ended: 16 January 2012 at 08:56:12
Completed status: Failed
Final error: 0xe00084ed - A hardware error occurred.
Final error category: Backup Device Errors

For additional information regarding this error refer to link V-79-57344-34029

Backup- E:
Storage device "QUANTUM DLTS4" reported an error on a request to write data to media.
Error reported:
The request could not be performed because of an I/O device error.
V-79-57344-34029 - A hardware error occurred.

 

 

Backup- KARA
Media mount failed.
User canceled a Physical Volume Library operation.

One thing I did try was to lower the priority of the Agent on the Exchange Server (KARA), but this has had no affect.

  • Don't you just love Spanners,

    On the 19th Jan, when I changed the ID for the DLT and disabled the HP Storage/Foundation services it must have applied the Quantum Driver (4.5.1.0) to the device rather than applying the existing BE 5.1.25.0 driver.

    Anyway, since the Verify hickup on the 25th, no failures as yet.

    Will continue to monitor and update

18 Replies

  • I was just having this dicussion with someone recently...  How SDLT S4 was killed off in 2006, and the planned S5 release never materialized and Quantum is pushing for LTO as the standard going forward...  Yet Quantum still sells this in the SMB.  

    That said, sometimes, removing the library and drives adn starting over is what is needed.  Even if it means more work for you to reconfigure your jobs.

    I've run into the HP conflicting software errors too.  I just plain removed it from my backup servers as a best practice now.  I prefer SNMP and perfmon polling tools instead, less impactful and problematic.

    Lastly, sometimes SCSI cables and terminations are a nasty thing.  What appears normal, is actually intermitent errors you never can track down.  Moving to anything other than Adaptec for SCSI cards, and having a new SCSI cable/terminator is always a good thing.  I used to keep spares on me to rule them out at customer sites, since it happened enough per year...

  • I know this shouldn't impact and is historical because it's a dual channel controller but both DLT-1 and DLT-S4 were ID 6

    So we had:-

    SCSI Port 1, Slot 3, ID=6

    SCSI Port 2, Slot 3, ID=6

    Shouldn't impact but we'll see.

  • Cheers guys,

    I think removing the device, along with disabling the Management agent will be on the task of things going forward.

    I was speaking with Quantum last night and they have suggested updating the LSI SSCI drivers, ensuring I use a non RAID version, because of an error in the system log (although all we've done is changed the tape drive hardware and nothing else).

    Event ID 11 The driver detected a controller error on \Device\RaidPort0.

    The above error occured on the 16th Jan, 2 days after the BE jobs started to fail so I don't see a 100% relation. The error has been reported before but not consistently.

    Going to do one thing at a time and maybe start with the disabling of Storage Agent (which in turn stops Foundation agent), then Library, then Device Driver, depending upon results.

    Cheers as always.

    PS - another successful backup last night, again same process as previous days.

  • Update,

    Backup was successful last night. This follows changing SCSI ID (which I doubt was ever an issue), re-connecting cable (which I doubt was an issue), stopping the HP storage service and didn't run the xtalk health check.

  • Great, give it a couple more days, and if successful, you can close this off.

    The funny thing is the HP Storage services run on all my servers with no hassles, and it seems to be a hit-and-miss affair with them causing issues or not.

  • Can't say I'm totally convinced since the server had a DLT-600 installed prior and nothing has changed, just the Streamer.

  • Failed, athough while verifying so at least we had a backup.

    I will update in a couple of days because I'm not convinced the removal of the library is the way forward.

  • Don't you just love Spanners,

    On the 19th Jan, when I changed the ID for the DLT and disabled the HP Storage/Foundation services it must have applied the Quantum Driver (4.5.1.0) to the device rather than applying the existing BE 5.1.25.0 driver.

    Anyway, since the Verify hickup on the 25th, no failures as yet.

    Will continue to monitor and update