If the job has failed, check above the tab with the completed status to see if there are any errors listed there. Also check the application and system event log for errors. Since when does this problem occur?
Yes you can paste the relevant part of the job log here for clarification. Try using another device for the job and see if it works.
In my experience, every job I would try would fail when the Utility partition was selected and encryption enabled. I don't know whether or not this is by design, or why this is happening is a mystery. No word from Symantec about this so I'm using what works for me.
We too have this problem, we did a complete re-install, changed no settings and ran a default backup job. The job completes and works fine afterwards but at the end we get an error message saying we responded Cancel to the job and then get a "Job Cancelled" and "Job Failed" in the job log.
Could this have anything to do wth the autoresponse feature, even though we havent turn it on or altered the default settings? Or any other suggestions?
If you are not seeing any output that makes sense in the job log or need more detail, try debugging the Backup Exec Job Engine service on the media service and the Backup Exec Remote Agent for the machine being backed up. If everything is local to the media server (including the data being backed up then it would probably be easiest to use SGMon and just check the engine checkbox (debugs both the job engine and the 'local' remote agent):
How to use the SGMON utility to perform a live debug of Backup Exec http://seer.support.veritas.com/docs/190979.htm
If the machine being backed up is remote (i.e. not the media server) then you will need to also debug that remote agent by following steps 1-4 in the following TechNote (for the relevant OS):
How to enable or disable "debug logging" in Backup Exec for Windows Servers http://seer.support.veritas.com/docs/254212.htm
Once you have the debugs you will want to look up the time of the supposed cancellation in the remote agent debug for the machine being backed up. Make sure first that the clocks are synced between both the media server & the remote machine otherwise you will be looking at the wrong section of the debug.
If you don't see anything obvious then you can post in this thread the relevant section of the job log & the RAWS debug
Thanks, the SGMON util showed that our device was timing out, it happened to be an exabyte vxa 2 that was being forced to be used as a DLT4000 for compatibility with a previous version i think. so after reseting it back to default and updating the firmware the problem stopped immediately.
i?ve run BE 11d on a W2K3 SP1 Server. I?ve the same problem. The server was setup with a other Computer Name. the name was changed and the beutility.exe was running to delete and renew the media server with a technical from Symantec.
In the log file from sgmon i see the following:
benetns: 02/15/07 14:53:38 End of NRDS Protocol Message. benetns: 02/15/07 14:53:38 Updating cache for destu02.atrema.deloitte.com. benetns: 02/15/07 14:53:38 Connecting to BE Database. beserver: 02/15/07 14:53:38 -1 Client requested key (1171547771). beserver: 02/15/07 14:53:38 01 UpdateDynamicInfo: cluster open unsuccessful. beserver: 02/15/07 14:53:38 01 Server Configuration: Client added: 9 beserver: 02/15/07 14:53:38 -1 Client 'DESTU02' connected('','ATREMA\DE Backup Service'): 0x87040a0 benetns: 02/15/07 14:53:38 Successfully connected to BE Database. benetns: 02/15/07 14:53:38 Reading agent database record for destu02.atrema.deloitte.com. benetns: 02/15/07 14:53:38 Found agent record 2 for destu02.atrema.deloitte.com. benetns: 02/15/07 14:53:38 Updating agent record for destu02.atrema.deloitte.com. benetns: 02/15/07 14:53:38 Write Successful, key=2. beserver: 02/15/07 14:53:38 01 Server Configuration: Client removed: 8 beserver: 02/15/07 14:53:38 -1 Client 'DESTU02' Disconnected:0x87040a0 benetns: 02/15/07 14:53:38 Disconnected from BE Database. benetns: 02/15/07 14:53:38 Update complete. beremote: 02/15/07 14:53:45 Could not create a BETCPConnection object from address: DESTU01 error=An error occurred during host address resolution: Error Code: 11001, System Error Message: No such host is known. beremote: 02/15/07 14:53:45 NrdsAdvertiserThread: connect to target=DESTU01 port=6101 failed beremote: 02/15/07 14:53:45 ConnectToServerEndPoint: dest=DESTU02, service=6101 beremote: 02/15/07 14:53:45 CreateConnection type=0 on socket 1536 via BESocket OK beremote: 02/15/07 14:53:45 NrdsAdvertiserThread: send of destu02.atrema.deloitte.com type 7 subtype 2 to target=DESTU02 port=6101 succeeded benetns: 02/15/07 14:53:45 Accepted new connection. beremote: 02/15/07 14:53:45 @@@@@@@MyCloseSocket called with sockfd = 1536(0x600)retval = 0 beremote: 02/15/07 14:53:45 NrdsAdvertiserThread: Retrying in 60 seconds benetns: 02/15/07 14:53:45 @@@@@@@MyCloseSocket called with sockfd = 516(0x204)retval = 0 benetns: 02/15/07 14:53:45 Received 131 bytes. benetns: 02/15/07 14:53:45 NRDS Protocol Message:
destu01 is the old name, destu02 the new.
Knows anyone how i can resolve this issue without reinstalling BE 11d ?
Best Regards MarkusMessage was edited by: Markus Walter
yes there is no other Message. Only "Job failed" ! I openend a call when the server name was changed from DESTU01 to DESTU02. The BE Services didn?t started after the renaming. The Symantec Technical told me i should try to update media server configuration by using beutility.exe. Aber updating the media server the service starts.
Many Greats Markus
for example i�m admin, the technical was only called for the update of the media server.Message was edited by: Markus Walter
It appears from the log that the beremote is still picking up the old server name from somewhere. Is this a local backup job (i.e. backing up local data on the media server)? If so, look in the job and change the selections view to 'text view' and see if the old server name is still in the job. There may also still be some reverse lookup w/ the old machine name in the local cache (hosts or lmhosts files, etc) or other low level services (DNS, WINS, etc.).
Let us know if you check all that and the beremote is still somehow picking up an old machine name.
Interesting... if you are saying the error actually occurs after the backup and during or after the verify then you might want to search the registry for the old machine name. There may be something we are queueing off of that is still contained somewhere.
1. Start > Run & type in 'regedit' 2. drill down to the 'local machine > software' area 2. Click edit > find 3. type in the old server name
If you find nothing there then you might want to try exporting our sql db to a txt file (you can find the procedure online) and search for the old machine name. If you find it in either place, give me the exact location and i'll advise on what to do next.
Sorry, i should have clarified if this is happening during the verify then all searching (registry & our BEDB sql db) should be done on the media server, not the remote machine in question. If its happening during the transition from backup to verify, then you might want to also search the registry on the remote machine in question.