Storage device "HP 2" reported an error on a request to space forward by file marks

[Lansend]

I am getting the following error on one Server that is running Backup exec 9.1 ( yes, I know it is old , but it is & has been working OK , till recently)

The backup device is an HP DAT72 C7438A Tape Drive 36/72GB SCSI DDS5

I know all about I/O device error & the many reasons for that error.

However I am seeing the other error for the first time and could not find anything about it.

" reported an error on a request to space forward by file marks."

I was wondering if somebdoy has a clue what it means.

OFO: Started for device: "Shadow?Copy?Components".
Advanced Open File Option used: Microsoft Volume Shadow Copy Service (VSS).

Storage device "HP 2" reported an error on a request to space forward by file marks.

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

Please no advice about the "I/O device error." Thank you

[AmolB]

Have you checked the below article.

http://www.symantec.com/docs/TECH47605

[Ken_Putnam]

Please no advice about the "I/O device error."

Why not?

That is the root cause of your problem

[Lansend]

Thanks Amol, I now at least have some direction to follow.

Solution 1:
The Removable Storage Manager (RSM) was already disabled

Solution 2: Install the latest Device Drivers, does not really apply. Nothing & I mean nothing has changed since the last good back up about a month ago. As a matter of fact nothing has changed on the server for about a couple of years, not even updates & service packs. The Backupexec is actually VERITAS Backup exec.

Solution 3: Perform an erase. I am going to try that tonight. Operator usually replaces tapes last thing in the evening so I have to try & remember to do it.

If I do it, will respond with results tomorrow.

[Lansend · Accepted solution]

We performed solution 3 namely did a full erase before the backup. No difference.

The job backs up two drives on the server, an SQL Server instance on the same server and shadow copy components.

While investigating we had noticed that the job always failed on the second resource. So we changed the resource order to see if the error moved with the resource or remained on the second resource. We observed that it remained on the second resource.  

We then split the job into individual jobs with the first job overwriting the tape & the remaining jobs appending to the tape. Lo & behold all jobs completed successfully.

Can anybody explain?

[Ken_Putnam]

Good troubleshooting

but no, I have no idea why creating separate jobs rather than one multi-resource job would resolve this error