Video Screencast Help

BEX 12.5 I/O Error

Created: 08 Oct 2010 | 9 comments

I guess you get to your desperation point when you're posting on a product forum.  Actually, I've seen how useful some of the posts were to others on here and I am hoping for the same results. 

So, here's our problem.  Last Sunday night (10/3/2010) our backup job failed with the following error from BEX logs:
Storage device "IBM 1" 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. 
The correlating Windows event is worded exactly the same, with event ID = 57665.
Initially, I believed this was a hardware error, and conducted troubleshooting accordingly.  After cleaning and running diagnostics, we determined the drive required replacement (and this was confirmed by Dell support).  After the new drive has been replaced and configured, we are still seeing the same error above.  What I find baffling is that this failure occurs on our shared "E:/" partition, which is local to the machine running BEX.  It has no problem backing up files and folders on the root (C:/) and additionally no problem reaching out to remote agents and running those backups when I manually point BEX to them.  It only fails on this local partition.  Unfortunately, when this happens it puts the tape drive in a "panic" state, and the only way to regain communications with it is to reboot the machine.  I struggle to believe this is strictly a hardware issue, as I am able to backup data from C:\ and restore it without any problem.  Something else is going on here.
If anyone has any thoughts or ideas, they are more than welcomed at this point.  The following links were unhelpful, unfortunately.
Here's our specs:
Windows Server 2008 Standard
Backup Exec 12.5 R2213 SP4, Hotfixes 355944 and 357378
IBM Ultrium HH3 LTO-3 Tape Drive, current firmware, using Veritas / Symantec Drivers
I have attached a screenshot and the BEX log (xml only)
Thanks in advance.

Comments 9 CommentsJump to latest comment

MyNameIsNeo's picture

Thanks for the reply.  It's actually a SCSI tape drive, but I will definitely check that it's not daisy-chained with another SCSI device on the same controller. 

CraigV's picture

Hi Neo,

Can you verify whether or not you that E:\ partition is successfully backed up in a stand-alone job? if it is, deselect it from your selection list, go to Text view and make sure that it is deselected, and then reselect it...


Alternative ways to access Backup Exec Technical Support:

Larry Fine's picture

Does the problem always occur on the same file/folder on E:?

Can you backup E:\ (either the whole thing or a specific problem folder) to a B2D folder?

If it is reproducible, this may help:

Troubleshooting hardware with Backup Exec for Windows Servers using the SCSI Trace Utility (tracer.exe).

If you find this is a solution for the thread, please mark it as such.

Mahesh Roja's picture


The error message "Error on a request to space to end of data. The request could not be performed because of an I/O error" is reported in Symantec Backup Exec for Windows Servers (BEWS) when attempting any tape media operation.

Also refer to this article..

How to troubleshoot issues with a Robotic Library (autoloader/changer) and/or Tape Drive(s)

If this Info helps to resolve the issue please Mark as Solution


pkh's picture

Try re-installing the drivers for the tape device.  Go to Tools ---> Wizards ---> Tape Device Configuration Wizard to do so.

After re-installing the driver, restart both your tape device and your media server.

MyNameIsNeo's picture

@ Craig:  Thanks for the advice.  I tried this, but the backup still failed with identical errors. 

@ Larry:  Good call.  I am backing the E:\ partition up to disk now.  If the B2D job succeeds, then we know may have a SCSI communications issue.  I will then proceed to run the same job backing up to tape, and run the tracer.exe.  Both great ideas.

@ Maheshroja:  We are using the Symantec drivers, so it would make sense that the manufacturer's drivers may have a longer timeout.  That's the direction I will go if the tracer.exe output indicates communication issues. 

@ pkh:  As per Maheshroja's post, I will definitely consider looking at the drivers if the tracer.exe indicates communication issues.

Thanks for all the helpful suggestions all.  I inherited this system, and tape backup has never been my bag, so this help is definitely appreciated.  Once I find a solution, I'll be sure to come back here and mark the correct post accordingly.

MyNameIsNeo's picture

@ Larry:  It backed up to disk, no problems.  I plan to use the tracer.exe app to capture the SCSI commands, but that's a rather large partition and I'm a little concerned about the size of the log file.  Still willing to give it a shot.

Larry Fine's picture

Does the problem always occur on the same file/folder on E:?

Running tracer on a large backup is tough.  If you could nrrow it down, it is easier to trace/troubleshoot.

If you find this is a solution for the thread, please mark it as such.