Because SharePoint Server 2007 is a multi-tiered solution and cannot be backed up via a single interface, you shouldn’t base your recovery plan on backups; you should base it on restores. You should first decide what you need to restore and in what time frame. As you progress through your plan, don’t forget to leave time for dependencies, such as SQL Server. Let’s use a four-hour SLA as an example. If it takes you the entire four hours to restore your SharePoint Server 2007 content, that doesn’t leave you time to restore SQL Server if needed. To totally restore a server farm, the following SharePoint Server 2007 components must be backed up, scripted, or thoroughly documented:

Using the native farm backup tools in Central Administration, you will back up the majority of the preceding content with the exception of manually edited 12 hive customizations, Alternate Access Mappings, and unique IIS settings such as host headers, assigned IP addresses, and SSL certificates.

You cannot simply restore the native backups, however. You must first build a new farm. The new farm will create a new configuration database and Central Administration content database. The settings used for those two items will persist after a full restore. What actually happens is that the old configuration database is merged with the new one you created. Why not do a complete restore? You cannot restore the farm to full fidelity because you don’t have the SharePoint Server 2007 tools to perform the restore. Essentially, you must build a new farm to use the native restore tools. For small installations, the native tools work well. For larger installations, you may consider SQL Server backups of all content databases and use the native tools only for SSPs backups. Most large organizations are already performing SQL Server backups and would like to continue doing so for SharePoint Server 2007.

Notes from the Field: Recovering Content Databases Using SQL Server Tools

In a worst-case scenario, we have used SQL Server Management Studio to restore content database backups created with the native SharePoint Server 2007 tools. In your SharePoint Server 2007 backup directory, look for large files, such as 00000015.bak, as shown in the following graphic.

If you have a great deal of content databases, you can either use guesswork and old-fashioned trial and error or refer to your backup logs. In the relevant spbr00nn directory, open the spbackup.txt file. In this file, search and find the content database you want to restore. The content database and backup file association is defined like the following example:

@db_name=Contoso_WSS_Portal_01, @db_loc=\app1ackspbr00010000015.bak

Using SQL Server Management Studio, you should restore using the device location and selecting the .bak file previously documented. After selecting the backup file, you will be presented with the backup set selection, as shown in the following graphic.

After restoring the content database, you can attach it either to a temporary Web application built for restores or associate it once again with your production Web application.

Ben Curry, Microsoft MVP, Mindsharp

You may also decide to script all or part of your farm restoration. This is quickly becoming commonplace and will allow an exact reproduction of your farm while using SQL Server to back up and restore your content databases. You will still need to back up the file systems on all servers in the farm and back up your SSPs using the native tools. To restore a server farm using scripted backups, the best practice is to first build a farm using scripted backups. In a perfect scenario, your production farm is completely built using your farm recovery scripts. This ensures that the scripts can be used to restore the farm in the event of a disaster.

Second, you need to use the native tools to back up your SSPs. Third, you will use SQL Server tools to back up your content databases. We have included a sample farm build script on the companion CD with instructions.