SharePoint Backup Error Object Index Partition 0 failed in event OnPrepareBackup

My SharePoint site was installed without the SP 2010 SP1 service pack, so before installing the SP, I wanted to perform a backup, lest I allow Mr. Murphy to grab the empty seat next to me in my cubicle and hang out for a few days laughing at me and drinking my coffee.  (Anyone can laugh at me, but you DO NOT drink my coffee!).

So I went into the SharePoint Central Admin, chose the backup option, ticked off the Full option (as opposed to differential) and chose the root Farm node for the backup choices.  Once I chose to start the backup, almost immediately I found that the error "Object Index Partition 0 failed in event OnPrepareBackup" was reported.  I googled\researched\rebooted\re-tried my backup, but all to the same conclusion.

Down The Rabbit Hole

It wasn't until after I looked more closely at all the gobbledygood in the error logs that I found the following:
[10/8/2012 9:34:39 AM] Verbose: Starting object: Search Service Application.
[10/8/2012 9:34:39 AM] Verbose: Saving SPPersistedObject State
[10/8/2012 9:34:39 AM] Verbose: [Search Service Application] Stored this object's parent type: Microsoft.Office.Server.Search.Administration.SearchQueryAndSiteSettingsService
[10/8/2012 9:34:39 AM] Verbose: [Search Service Application] Stored application pool name: SharePoint Search Crawl App Pool
[10/8/2012 9:34:39 AM] Verbose: [Search Service Application] Storing the process account username 'DOMAIN\serviceaccount'.
[10/8/2012 9:34:39 AM] Verbose: [Search Service Application] Stored default endpoint name: http
[10/8/2012 9:34:39 AM] Verbose: Starting object: http.
[10/8/2012 9:34:39 AM] Verbose: Saving SPPersistedObject State
[10/8/2012 9:34:39 AM] Verbose: Starting object: https.
[10/8/2012 9:34:39 AM] Verbose: Saving SPPersistedObject State
[10/8/2012 9:34:39 AM] Verbose: Starting object: Search_Service_Application_DB_ad1fa25e6f84a6e952.
[10/8/2012 9:34:39 AM] Verbose: Saving SPPersistedObject State
[10/8/2012 9:34:39 AM] Verbose: Starting object: Admin (C: on SERVERNAME).
[10/8/2012 9:34:39 AM] Verbose: Saving SPPersistedObject State
[10/8/2012 9:34:39 AM] Verbose: Starting object: Search_Service_Application_CrawlStoreDB_579164d3.
[10/8/2012 9:34:39 AM] Verbose: Saving SPPersistedObject State
[10/8/2012 9:34:39 AM] Verbose: Starting object: Crawl-0 (C: on SERVERNAME).
[10/8/2012 9:34:39 AM] Verbose: Saving SPPersistedObject State
[10/8/2012 9:34:39 AM] Verbose: Starting object: Search_Service_Application_PropertyStoreDB_33d0b9.
[10/8/2012 9:34:39 AM] Verbose: Saving SPPersistedObject State
[10/8/2012 9:34:39 AM] Verbose: Starting object: Index Partition 0.
[10/8/2012 9:34:39 AM] Verbose: Saving SPPersistedObject State
[10/8/2012 9:34:39 AM] FatalError: Object Index Partition 0 failed in event OnPrepareBackup. For more information, see the spbackup.log or sprestore.log file located in the backup directory.
 NullReferenceException: Object reference not set to an instance of an object.

Interestingly enough (to me, anyway) is that all these error's seem to surround the Search Service.  When I viewed the results of the backup process in the Central Admin, I found that all other backup tasks completed properly, it was just the Search Service that was causing my headache. 
(At this juncture, I thought hmm.. I don't really need to backup the search service, do I?  Just then, I pictured Mr. Murphy tossing my ibuprophin, acetometaphin and liquor out the window and drinking my coffee.)

Within Central Admin, I clicked around looking for more more tips on this search stuff.  I'll spare you the boring details and cut to the chase.  After some blind luck, I went to Manage Service Applications where I found my Search service.  I chose to highlight the row and click Manage.  There, I found the error message "The search service is not able to connect to the machine that hosts the administration component. Verify that the administration component c8519b74 status -<GUID> in search application Search Service Application is in a good state and try again".  Hooray!, I thought, thinking that all I have to do is configure my search service properly, and away I go with performing my backup again.

Further Down The Rabbit Hole

I followed the steps posted here - http://blogs.technet.com/b/poojk/archive/2011/11/28/sharepoint-2010-search-service-is-not-able-to-connect-to-administration-component-server.aspx - thinking that I just had to enable my search service.  However, after performing these steps, and other troubleshooting, my search service would always indicate that it wasn't active.  Finally, I decided that I should follow some other suggestions and remove the Search Service application entirely, see if that resolves my backup issue, and if so just re-install my search service at a later time.  I gave the service a final blessing, clicked it, and chose Delete.  Central Admin just hung there.. I made a coffee, clicked around the Interwebz, and after 30 minutes or so found it was STILL hanging.

Deeper Further Down The Rabbit Hole

I tried deleting the Search Service, disabling some potentially related services, rebooting the server several times, but in the end, the bloody thing wouldn't delete!  Finally, I came across another handy dandy blog post - http://donalconlon.wordpress.com/2010/08/27/deleting-the-search-service-application/.  Here, it's recommended to use stsadm.  The problem here is that stsadm isn't the recommended method to perform admin tasks, but I was helpless at this point.  Help me stsadm, youre my only hope!

I used the steps provided in the blog post (stsadm.exe -o deleteconfigurationobject -id <GUID>) and the service finally deleted, HOORAY!

Out Of The Rabbit Hole

At this point, I rebooted once more, just to be safe, checked my Central Admin, and saw that the Search Service removed.. which it did.  I tried another backup, and no error's this time.  I went on to install Service Pack 1, and we all lived happily ever after.