I mentioned the other day that an update broke my SharePoint installation. The timing was bad as I was just about to leave the office for a few days, so as it turned out I did not get to focus on this properly until last weekend. This virtual server is backed up nightly. I restored from before the failure but it still did not work. Perhaps there was an update pending that was not fully applied until the server restarted, so that even my “good” backup was bad.

The error was frustrating. Accessing a SharePoint site got me a 503, service unavailable. I could run either psconfig or the SharePoint Configuration Wizard without error, but it still did not work. The event log showed a bunch of errors that made little sense to me, including those annoying DCOM activation errors, and database login errors when the accounts concerned had valid logins.

It was wasting too much time so I went for plan B. Reinstall SharePoint from scratch and restore the content database.

This was actually easier than I expected. I backed up WSS_Content using SQL Server Management Studio. I then removed everything SharePoint, and deleted a couple of remnants in IIS. Reinstalled and everything worked.

After that it was simply a matter of attaching the old content database. Well, nearly that simple. My first attempt failed because SharePoint was not fully patched and had an earlier schema than the content database. I manually downloaded and applied the latest SharePoint hotfix rollup. Then I attached the old content database to a new SharePoint site, and everything came up just as before.

I find this reassuring, as keeping documents as blobs in SQL Server is just a little scary from a recovery perspective.

Even if attaching the database were to fail, it is not too bad. You can write code to write out the documents to files and recover them that way. There are some clues here.