SharePoint Backup and Restore MOSS

If  you are moving your site from Testing(Staging) to Production, site backup and restore (using STSADM command line tool)  is the way to go. Other ways include SQL Server, Sharepoint Designer, DPM etc. However, site backup and restore using STSADM is probably the easiest and fastest one.


Backup the site using the following STSADM Command:Stsadm –o backup –url http://<server name>:<port> -filename <path\name to be used for the backup file>
Example:
Stsadm –o backup –url http://pravahaminfo:4545–filename "e:\backup4545.bak"
After the backup has been completed, “Operation Completed Successfully” message should be displayed.

Create a new Web Application for restoring the site:Go to Central Administration -> Application Management -> under SharePoint Web Application Management -> click Create or Extend Web Application. Fill in the required information, click Ok and wait until the progress continues.

Once the new web application is created, run the following STSADM command and restore the site using the backup file created above.

Stsadm –o restore –url http://<server>:<port> -filename <path\name of the backup file>
Stsadm –o restore –url  http://pravahaminfo:5454  –filename "e:\backup4545.bak"
Restored site should be up and running.

If it is not (and you are receiving weird errors in your browser), keep reading:

Now it could be the case that you have customized your site. So, we must deploy those customizations properly for the site to work as expected. This is typically a scenario while moving your site from Testing to Production environment. First you have to add the solutions (if any created) to the farm.

Add a Solution to the SharePoint Farm:Add the solution package to the farm by running the following commands. Make sure full path of WSP file is supplied.
 
stsadm –o addsolution –filename <path to mysolution.internet.test.wsp>
Deploy the Solution to the restored site:
Now we need to deploy the newly added solution to our restored site. Click the solution name and select ‘Deploy’ button from top. Select the appropriate web application in the deployment settings and click OK. This will take several minutes to deploy mysolution.internet.test.wspresources (list templates, features, assemblies, master pages, styles). Once the solution has been deployed, reset IIS to ensure all deployed changes are picked up by the web application.

You can also deploy the solution from the command line with the following SharePoint admin command.

stsadm -o deploysolution -name mysolution.internet.test.wsp -url <site> -immediate -allowgacdeployment –allowcaspolicies
Make sure all your assemblies (DLLs) are available in Global Assembly Cache (GAC) usually placed at c:\windows\assembly.  

 Activate features installed by mysolution.internet.test.wsp solution package:Go to the newly restored site, click Site Actions, click Site Settings, click Site Collection Features. Click Activate button to activate any Site Collection Feature.

Go to the newly restored site, click Site Actions, Site Settings, Site Features.
Click Activate button to activate any Site Features.

Update Web.Config file:It will be usually a case that your solution package will deploy a few DLLs with it. So we need to add all those Safe Control entries, Assembly Bindings, Keys and any other web.config changes to our newly restored sites’s web.config. Weird browser errors that I mentioned above usually appear due to these missing entries in web.config, specially when you are restoring on the same machine/server…….As assemblies will already be there in the GAC if the restore operation was performed on the same machine….you just need to make web.config entries to the restored site…..adding and deploying of the solution could be skipped. So lets do the copy paste operation from the old web.config to the new web.config. Just compare the two web configs and copy/paste the missing entries into the new. 

Web.config file could be found at the following path:
<drive letter>:\Inetpub\wwwroot\wss\VirtualDirectories\<port number>\web.config
 
Example:C:\Inetpub\wwwroot\wss\VirtualDirectories\5454\web.config 
 
Usually these changes will include Safe Controls, AssemblyBindings, PageParserPaths and Keys etc. After making these changes your site should be ready in Production.

If you are worried about the bad habit of Moss saving absolute URLs for the page layout in the properties of a publishing page, then relax, solution is already in the market:

http://blogs.technet.com/stefan_gossner/archive/2009/05/01/red-is-green-up-is-down-and-the-unsupported-suddenly-becomes-supported.aspx

References:

you are refering to the following Microsoft article that says that moving a farm using STSADM is obsolete:

http://technet.microsoft.com/en-us/library/cc263236.aspx

and from here they will point you to “Moving to Another Farm” using SQL Server Tools:

http://technet.microsoft.com/en-us/library/cc261918.aspx

Before I say why I was able to use STSADM, I will take this opportunity to share some important info:

You can use STSADM command to backup and restore on the same farm:

http://technet.microsoft.com/en-us/library/cc261704.aspx

and you should not use STSADM command to restore to another farm, that’s right.

To restore to another farm, you must use SQL Server tools:

http://technet.microsoft.com/en-us/library/cc261918.aspx

and here is the important information: the specs of the farm on which you are restoring should still be exactly the same as the one from which backup is taken from. Specs means server names, software updates, number of servers…

Now if you are restoring to another farm which has different specs, then it will not be called as MOVING to another farm, it will be either MIGRATING or UPGRADING to anohter farm…..good news is that its still doable:

http://technet.microsoft.com/en-us/library/cc262370.aspx

So, what have I done above in the post?
I haven’t actually moved the farm at all. I have simply moved a Site Collection from one farm to another.

So, the trick here is that moving farms is complicated……largely due to config and central admin databases because they contain computer specific information (in short)…….so why dont we simply move our site collection and probably relax  :

http://technet.microsoft.com/en-us/library/cc706871.aspx

You can also move individual content databases using STSADM:

http://technet.microsoft.com/en-us/library/cc262792.aspx

Site Collection backup/restore that we did above will actually backup and restore the content DB.

I’m getting confused by all the options and different opinions in blogs. I’m going to move one or more site collections from one farm to a completely different one (new server names but same domain).

If I understand the link below correctly, Stefan Gossner basically says that in that kind of scenario the “Best is to use SQL backup/restore.”

If it’s a publishing site, one only needs to be sure to have SP2 and the April CU installed (so that links to pagelayouts are fixed), and then there are no problems using SQL backup/restore.

http://blogs.technet.com/stefan_gossner/archive/2009/05/01/red-is-green-up-is-down-and-the-unsupported-suddenly-becomes-supported.aspx#3257724