11-01-2011 06:32 AM
I have a backup to disk job that is backing up the C:\ and F:\ of a windows 2008 r2 VM, every 5-6 days the job fails with 'the connection to target system has been lost', we have backup exec 2010 R3 (with SP1). We have rebooted both the server and the backup server (its hard to reboot the VM during the day since it is our fileshare). Any advice on what to check next?
11-01-2011 06:44 AM
Hi
Can you please post the job log when it has failed also can you post the events in event viewer in application tab at the time of failure on which server job is failing for example if you are backing up media server itself then application events of that time from media server or if you are backing particular remote server then application events if with any errors from that server
Thanks
11-01-2011 07:08 AM
Here is the job log (names and ips changed) and an entry in the event viewer from the backup server:
11-01-2011 07:52 AM
double post
11-01-2011 07:52 AM
I've just gone through this again today..if you run: vssadmin list writers - from a command prompt you should find some of the VSS writers are in error.
Reregister the VSS *.dlls using the Symantec TN below and it should fix it. This can be done while the server is online with no effect on anybody.
http://www.symantec.com/docs/TECH70486
If this still doesn't fix it, uninstall the RAWS agent and run a push-install from your media server again. Once done, make sure that your AV (if you run 1) isn't blocking access between the RAWS agent and the media server, and if so, put in an exclusion.
Thanks!
11-01-2011 10:41 AM
i ran the vssadmin list writers on both the backup server and the VM having issues, but none of the writers said there was an error. i havent reregistered the dlls yet and being that teh VM is our fileshare, reinstalling the agent will need to be scheduled (since the possible reboot), thanks
11-01-2011 01:27 PM
...nope, there is a way around that which buys you time if you cannot reboot the server immediately:
1. Backup your registry first!!!
2. Open regedit.exe --> HKEY_Local Machine
3. SOFTWARE --> Symantec...
4. Look for a registry key called PatchReboot and delete this.
That fools BE into thinking it was rebooted. Reboot the server as soon as you are able too...
11-02-2011 12:31 AM
Enable AOFO in your job and try again.
11-02-2011 06:02 AM
AOFO is already set to 'Automatically select open file technology'
11-02-2011 06:06 AM
...OK, then on the affected server, run: vssadmin list providers and take note of what is shown. Change to that provider in AOFO in the job settings!
11-05-2011 04:06 PM
Check this link about de AOFO Troubleshooting http://www.symantec.com/business/support/index?page=content&id=TECH45996
11-05-2011 06:08 PM
What has quiet time got to do with the problem?
11-07-2011 10:29 AM
the aofo option is already set to Microsoft provider (same as the results of vssadmin list providers on the affected VM), is there anything else i should check?
i see this in the event viewer of the backup server around the time of the failed job
11-11-2011 05:03 AM
...the TN below may or may not be for your issue, but check it out nonetheless:
http://www.symantec.com/business/support/index?page=content&id=TECH87166