This article speaks about the issues we go through more often than not in doing a restoration of a Site Collection from one version of SharePoint 2010 farm
to an upgraded version of SharePoint 2010 farm. This mostly happens in enterprise SharePoint establishments where developers are supposed to develop on one environment,
say a development environment, and then move their application to an entirely new SharePoint farm, say a staging or production.
The stsadm as we know gives many SharePoint methods, one of them being the ability to backup your SharePoint site collection
(stsadm –o backup –filename <filename> -url <sitecollurl>) and then restore it (stsadm –o restore –filename <filename>
-url <pre created empty sitecollurl> -overwrite) to any other SharePoint 2010 farm. So in cases where we try to restore a SharePoint 2010 Site
Collection to a SharePoint Farm which is a slightly upgraded one*, the stsadm throws a restore error which reads:
“The backup is from a different version of Microsoft SharePoint foundation and cannot be restored to a server running the current version.”
And all that we end up saying is "Now what!!!”
Using the code/solution
Well, there are many articles that explain a fix for this, but none of them explain it either in detail or in full. This is what I intent to write on. The solution
as it is evident is a SQL Server Backup Restore or better known as Detach Attach SQL Database, instead of a stsadm backup restore. (For the purposes
of this article, I will call the latter method “SQL Server Backup Restore”.) But that does not end here, to make sure your Site Collection is properly restored and upgraded,
you have to go a step further to do a PowerShell upgrade command.
The steps for executing a SQL Backup Restore of a Site Collection are explained below:
- Go to the Central Admin; find out the Content Database where the Site Collection is stored. It should typically be at Application
Management --> (under) Site Collections --> View All Site Collections.
On this page, select the Web Application where your Site Collection resides and then click on the Site Collection URL in the left.
The table in the right should have the Content Database Name where the Site Collection data is stored.
- Login to your SQL Server Management Studio; figure the Content Database Name from the list of databases there. Get the backup of your Content Database
from the SQL Server Management Studio Backup Wizard.
- Restore your Content Database to the SQL Server that acts as the database server for the upgraded SharePoint Farm. Make sure your SQL databases
are of the same version for both the older and upgraded version of SharePoint; for instance, you cannot restore a SQL Server 2008 database backup file to a SQL Server 2008 R2 box.
- Now login to the Central Admin of your upgraded SharePoint farm, create a new Content Database (Application Management--> under Databases --> Manage Content
Databases--> Click on Add a Content Database) for the web application where you want your site collection. Make sure the Web Application you choose does not have a Site Collection
at the same URL as the one you are trying to restore**. Title the content database the same name as done while restoring your SQL Server backup.
And voila!!! Your new Site Collection should be browse-able in the Web Application.
- However, this does not end here, you probably are able to browse your site collection fine but if you take a closer look, your site collection
is just restored as of now but not upgraded. To verify this, go to the Central Admin--> Upgrade and Migration--> under Upgrade and
Patch Management --> Click on Review Database Status and you would have your revelation there. If you point to the newly restored
content database here, you will find a message that says:
“Database is in compatibility range and upgrade is recommended”.
So effectively if you again try to backup restore this site collection using stsadm, in the same upgraded SharePoint farm, you will have a similar error as you got earlier.
This is where you need to do an upgrade, using a PowerShell command:
Upgrade-SPContentDatabase –Identity <name_of_contentDB>
Once this command finishes its execution, your site collection is now a fully restored and upgraded one.
Points of interest
In a nutshell, this article can be summarized by making a brief comparison of the stsadm way of backup-restore and the SQL Server way of backup-restore.
|STSADM||SQL Server (as described in the article above)|
|This allows the Site Collection to be restored at any URL location in the web application (at explicit paths like the root of the Web Application
or wildcard paths like “/sites/SiteCollection”).||This restores the Site Collection at the exact same URL in the Web Application at which it was backed up from.|
|This method has a Granularity level of Top Level Sites or Site Collection level.||This method has a Granularity level of Content Database, and hence all the Site Collections in the Content Database get shipped with this methodology.|
|For being able to restore a Site Collection by this method, it does not require creating a New Content Database in the target SharePoint Farm.||This mandatorily calls for the creation of a New Content Database in the target farm. |
|The backup files are usually very small when compared to the one generated by the SQL Server backup. As a simple comparison, where for an stsadm backup of a site collection
file weighs 294 KB, the backup file of the Content Database (which contains only one Site Collection) would typically be 23 MB.||The backup file size generated is huge.|
|Does not require access to the database server or SQL Server Management Studio to connect to it.||Requires permission on database server as well as SQL Server Management Studio to connect to it.|
* In order to see your SharePoint Farm's current version, in Central Admin, go to System Settings --> under Servers --> Manage servers
in the farm. Find the version of your farm under Farm Information as title Farm database version.
** One trouble of executing a SQL Server backup restore instead of a stsadm backup restore is that you are not at liberty to restore your site collection
at any URL. The former method does a restoration along with the URL of the Site Collection; however, that is not the case of an stsadm backup restore where you are free to choose your URL.