I was successfully running backups of my SharePoint 2010 server for a few weeks, then all of a sudden I noticed they weren't finishing properly. They'd run through most of the backup process, then stall trying to backup the Search Service Application. When I looked at the backup log file it showed the following:
I also noticed the following event log error (Event ID: 67, Source: SharePoint Server Search) :
After some investigation, I realized I had deleted my original Search Application and created a new one, but for some reason the old object still existed in SQL.
I tried a few methods to delete the old object, but nothing was working. When I manually tried to delete it through Central Admin it would pop up a screen saying it was processing, but it never did anything. A Google search turned up the following article: http://prequest01.wordpress.com/2008/08/16/unable-to-delete-shared-services/
I used the following stsadm command:
Stsadm -o deleteconfigurationobject -id "object GUID"
To find the object GUID, simply go into Central Admin - Manage Service Applications and highlight the offending legacy service application (Search Service Application in my case). You should now be able to see the GUID in the IE address bar. Run the command above, and try your backups again and all should be well.
You can also run the following command from the SharePoint PowerShell: Get-SPServiceApplication
If your backups are still failing, you can always increase the logging level to get more details about the Backup and Restore Process in the Diagnostics Logging Settings, from Errors only to Verbose. This will help troubleshooting. Once you find out the exact issue, you can bring logging back to default levels to reduce I/O and storage required for this extra activity.
You can also run the following command from the SharePoint PowerShell: Get-SPServiceApplication
If your backups are still failing, you can always increase the logging level to get more details about the Backup and Restore Process in the Diagnostics Logging Settings, from Errors only to Verbose. This will help troubleshooting. Once you find out the exact issue, you can bring logging back to default levels to reduce I/O and storage required for this extra activity.
