Backup Agent - E8602 - Error at Virtual Device Set

[neilmorris123]

Hi all,

I am currently really stumped with an error message that I have been getting on one of my Arcserve NT boxes running SQL Backup Agent. The machine is running NT4 Server with Service Pack 6a, Arcserve v6.61 Running SP2a and is also running SQL7 with Service pack 4.
The backup job is failing with the following error -

E8602 - Failed to read from Database - (DBNAME=Database1, EC=Backup Agent Error - (127) "Error at Virtual Device Set. Please Check the SQL Server 7.0 VDI.log"

I have looked up this message on the Computer Associates web site and its only suggestion is to upgrade SQL to Service Pack 2! This is running a later version.

Any ideas or thoughts would really really be appreciated!

 

[ACiDelic]

What started this problem? Did you install a service pack? Change the backup to use a different user?

Do you have sp2a applied on the agent? Reapplied?

What errors do you see in the vdi.log file?

What errors do you see in the SQL errorlog file?

 

[neilmorris123]

Hi,

Thanks for your response. I don't know when this problem actually started, it was something I noticed when working on one of our servers but the issue has been going for at least five weeks. I have reinstalled the agent and have reupdated Arcserve.

VDI log shows multiple instances of the following lines -

2003/03/14 22:39:21 pid(192)
Error on DBASQL70TID180VD0
Error at TriggerAbort: invoked

 

[ACiDelic]

That's a tough one. It's good that you tried reinstalling the agent. I think that error in your VDI.LOG indicates that the agent aborted the backup. I'm not sure why.

Here are a couple other things you can try out:

1. Try backing up the SQL agent using ARCserve on a different machine (remote backup). I believe this will use named pipes instead of VDI (like local backups).

2. Turn on the agent debug tracing (Under "HKLM \ ComputerAssociates \ ARCserveIT \ DSAgent \ agent \ CurrentVersion \ dbasql70 \" set Debug = 3). Run a backup and review the dbasql.trc file. You may be able to identify the error there, or you may have to have CA support look at it. You can also try posting the file (or a portion of the file). Maybe somebody else will have seen the problem before.

Sorry I cannot be of more help.

 

[mousie18]

Neil,

Is the SQL database on a remote server? If it is, are you using the client agent or backing up across the network?

Cheers
A.

 

[neilmorris123]

A,

It's running a local back up with the SQL Open File Agent residing on the server

Neil

 

[ACiDelic]

Something that you can do as a workaround to this problem is to perform a remote backup. Instead of using VDI it will attempt a backup using named pipes.

If possible, turn on tracing and review the output. You may be able to see an error or SQL Server error in the trace that will indicate the problem source.