When applying a new service pack or cumulative update to your SharePoint farm, you’re often instructed to do a backup both before and after the installation. Doing the backup beforehand is obvious.  If the patch somehow damages your farm, your backup ensures you can recover into a state just prior to the update.  This is doubly important for SharePoint since the updates cannot be uninstalled.

However, it might seem odd that you are also instructed to backup immediately after your update as well.  Let me explain why.  When you apply a service pack or cumulative update, the installation (and the SharePoint Products and Technologies Configuration Wizard that is run immediately after) makes several changes.  The most relevant ones related to this topic are the upgrading of code files located on your SharePoint WFE(s) and making changes to the configuration and content databases. In short, SharePoint’s code and databases must always remain in sync.

Let’s look at scenario that explains how these could get out of sync:  You have a farm that is currently patched to the SP1 level and you apply SP2. Shortly after the SP2 update, something happens to one of your site collections, requiring you to do a content database restore.  Your most recent backup is the one you made just prior to the SP2 update.  You go into SQL Management Studio and restore the SP1-version database on top of the damaged one.  After the restore, you try to access the web sites, and you find that all the web sites in each site collection for that content database are broken. You now have a much bigger problem, all because of mismatching versions.

This is the main reason why you are instructed to run a backup after the upgrade.

A good question you might be asking is “How come SharePoint isn’t smart enough to recognize the problem and just upgrade the database?”  Actually it is, but you can’t perform the steps as described in the scenario above.  Here is a better way to perform the database recovery which will usually result in a successful upgrade:

Before you issue the restore, go into Central Administration and remove the content database that is damaged.  You can do this from the Application Management Tab –> Content databases.  After this is done, drop the old database in your SQL Server and restore it backup.  Finally, use the STSADM –o addcontentdb command to add the content database back.  When you do it this way, SharePoint checks the versions and if it detects an older version will usually make the necessary changes to upgrade it to the correct version level.  Incidentally, if you try to add the content database from the Central Administration GUI, you will be greeted with this error directing you back to STSADM:

I should add that I have heard cases where this upgrade doesn’t always work.  Erring on the side of caution, I still recommend doing the post-upgrade backup.

Understanding SharePoint Build Numbers

Let’s now look at how SharePoint uses build numbers and where these are stored.  I’m sure you’ve seen these before.  For example, here are some of the common build numbers for SharePoint v3/2007:

When performing a recovery, you can always find out what your database build numbers by looking at the versions table inside the database.  This applies to all SharePoint databases except Single Sign-On. If you query the versions table on your configuration database, for example, you’ll see values such as:

In the results above, you can see the latest version is 12.0.0.6421 or SP2.  What you’ll also notice is the lineage of the upgrades.  That is, this farm was originally built with RTM (Release to Manufacturing—i.e. the original release) and then upgraded to SP1 (6219) and then SP2.  Again, you can run the same query on the other SharePoint databases as well.

Lastly, as you know, you can find the farm version in Central Administration if you go to Servers in Farm in the Operations tab.  Did you know that you can also find this in the registry?  This might be helpful if your SQL Server is down and you can’t run Central Administration.  You’ll find it in the Version value located in the the HKLM\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\12.0 key.

Armed with this architectural knowledge on versions and build numbers, you should have more confidence in your recoveries and also better understand why you should backup both before and after an upgrade.