If you haven’t heard already, I am going to be at Jeff Middleton’s SMB Disaster Recovery Conference in New Orleans at the end of this month, and at some point during the weekend I will be discussing Windows SharePoint Services in the context of Disaster Recovery – not only how to recover from a SharePoint disaster, but how SharePoint can be a valuable technology in the face of a true catastrophic disaster.

Well, it just so happens that I have had my own little SharePoint disaster on my hands.  A little over a week a go, I was testing a SharePoint upgrade scenario on my web server and proceded to blow up WSS 3.0 on that box.  The good news was that I had a disaster to fine-tune my recovery skills.  The bad news?  Being a bit lazy I actually had a production SharePoint site on that server (oops smile_embaressed  )   Luckily, the production site was non-critical (just the site for my family – and while they’re used to me blowing things up, I really didn’t want to have to mess with recreating that site and it’s 20GB of data).  And I’ll also admit that I was slightly behind on my SharePoint-based backups for that site as well – far enough behind that I really didn’t want to have to go that far back if I didn’t have to.

I’ll admit that I’m not making much progress with repairing the WSS installation on the web server – I’ve tried just about everything, and it looks like I’m going to break down and call PSS to get it working again, assuming I don’t just re-install.  Naturally, the only thing holding me back was this one site that I really wanted to salvage.  Well I’m happy to say that after some trial & error (and the help of Google), I have the site up and running on a separate SharePoint farm – and it was actually quite painless.

First – for the sake of clarity, I’m going to talk about this process in terms of moving a site to a different SharePoint farm, for the simple fact that we can have multiple front-end servers running SharePoint in a single farm, and moving a site to different servers in a single farm is a separate process.  Most SBSers are going to be running a single server farm, and as such will often talk about moving a site between servers, when they’re really talking about moving between farms. 

So to accomplish this task, here’s what I did:

1)  On the database server for the current farm, I performed an offline backup of the content database for the site I wanted to move.  (Easiest way to accomplish this is to stop your SharePoint database service and copy your .mdf & .ldf files).

2)  I restored the .mdf & .ldf files for the content database to the SQL data directory on the database server for the new farm.

3)  I attached the restored database to the SQL instance for the new farm.

4)  On the new farm, I opened SharePoint Central Administration.

5)  On the Application Management tab, I created a new SharePoint Application.  In doing so, I created a new web site that used the same port and host header the site on the original farm used.

6)  When the application creation process completed, I did not run the Site Collection Creation Wizard.

7)  Within SharePoint Central Administration Application Management tab, I clicked on Content Databases.

8)  I verified the Web Application, then clicked on the content database (which should be an empty content database created during the Web Application creation process)

9)  On the Content Database Settings page, I changed the database status from Ready to Offline, clicked to select the option to Remove Content Database and clicked OK.

10) Back on the Manage Content Databases page, I verified the web application then clicked Add a content database.

11) On the Add Content Database page, I entered the name of my SQL server where I attached my restored database, as well as the database name.  I verified Windows Authentication was selected, selected the appropriate Search Server, and clicked OK.

12)  Once that process finished, I was returned to the Manage Content Databases tab and could see that the restored content database was now associated with the web application I had created minutes earlier.

13)  I edited my local hosts file so the URL of my site would resolve to the local server

14)  I opened a command prompt and ran an iisreset, then ran an  ipconfig /flushdns, then pinged my site URL to verify it resolved to the local server.

15)  I opened Internet Explorer and browsed to my site – and voila! there it was smile_regular

So in the big picture, what is the big deal here?  The significance is that with WSS 3.0, you can actually restore one or more SharePoint web applications to a new farm with nothing besides a file-level backup of your content database.  And if you ever tried accomplishing the same feat with WSS 2.0, you can appreciate just how significant this functionality is.  Don’t get me wrong – this isn’t going to be the preferred method (I still recommend you take a look at native backup/restore functionality either from within SharePoint Central Administration or via the command line using stsadm.