SharePoint 2010 Backup and Restore of site Collection using Power Shell

Lets see how to perform backup/restore operation using Power Shell in SharePoint 2010

1. On the Start menu, click All Programs.
2. Click Microsoft SharePoint 2010 Products.
3. Click SharePoint 2010 Management Shell.
4. At the Windows Power Shell command prompt type the following command:


5. You will get a Power shell command prompt like below


6. In SharePoint 2010, Power Shell command Backup-SPSite is used for taking backup

7. Please see the screen shot for the backup Power Shell command

8. Backup-SPSite -Identity http://ServerName:port -Path "c:\backup\file.bak"

 

9. If you want to overwrite a previously used backup file, use the Force parameter. You can use the NoSiteLock parameter to keep the read-only lock from being set on the site collection while it is being backed up. However, using this parameter can allow users to change the site collection while it is being backed up and might lead to possible data corruption during backup.

10. Once this done you will get the backup.

11. Next you have to create site collection then use the below command to restore the backup that we currently taken.

12. Restore-SPSite -Identity http://Servername:port -Path "c:\backup\file.bak" -force



13. We are using force command because I want to overwrite the existing site collection that I created now.

Latest code not working

Latest Code Not Working Quite Right?

I’m going to start this post with an example. See if you have ever found yourself in this situation when working on developing updates for previously deployed code; most often in a test and/or development environment:
1. I start out with an existing feature receiver that uses a web-scoped feature. The feature is already deployed to my development environment. To make this example very simple to illustrate the issue – this feature receiver will set the web’s title to an arbitrary value. The title will be reset back to its original state when the feature is deactivated.

1	<span>using System;

2	using System.Runtime.InteropServices;

3	using <a href="http://securelink.sendori.com/br?key=Microsoft&spid=1853&output=redirect&ix=1" target="_blank"><span id="inlineTextHighlight">Microsoft</span></a>.SharePoint;

4

5	namespace SMayes.SharePoint

6

{

7	/// <remarks>

8	/// This class is meant to be the least amount of code to demonstrate the key points of

9	/// this post. It is lacking proper error handling, pre-requsitite checks, and null

10	/// reference checks for the sole purpose of making the code shorter and easier to read.

11	/// </remarks>

12	[Guid("af59900c-611c-4b77-82e6-8ed989768b76")]

13	public class ExampleFeatureEventReceiver : SPFeatureReceiver

14

{

15	private const string OLD_TITLE_KEY = "SMayes.SharePoint.ExampleFeature.OldWebTitle";

16	private const string NEW_TITLE_STRING = "EXISTING WEB TITLE";

17

18	public override void FeatureActivated(SPFeatureReceiverProperties properties)

19

{

20	// Retrieve the web object for processing

21	SPWeb web = properties.Feature.Parent as SPWeb;

22

23	// Before updating the web's title, store the old title in the web's property bag

24	web.AllProperties[OLD_TITLE_KEY] = web.Title;

25

26	// Update the web's title

27	web.Title = NEW_TITLE_STRING;

28

29	// Save all changes to the content database

30	web.Update();

31

}

32

33	public override void FeatureDeactivating(SPFeatureReceiverProperties properties)

34

{

35	// Retrieve the web object for processing

36	SPWeb web = properties.Feature.Parent as SPWeb;

37

38	// Reset the web's title back to the old title saved during activation

39	web.Title = web.AllProperties[OLD_TITLE_KEY] as string;

40

41	// Remove the old title from the property bag as it is no longer needed

42	web.AllProperties.Remove(OLD_TITLE_KEY);

43

44	// Save all changes to the content database

45	web.Update();

46

}

47

}

48

}</span>

2. Activating the feature on my test site reveals the following site title change.
Pre-activation:
Post-activation:
3. Now I’m going to illustrate a change to my previously deployed code. Let’s say for example that I wanted the title to be changed to “*** NEW WEB TITLE ***” instead of “EXISTING WEB TITLE”. I’ll make the change on Line 16 of the code above and create a new WSP for deployment.
4. I then open a new PowerShell window and execute the following six PowerShell commands using the same window. These commands will deploy the latest code and reactivate the feature on my test site so I can see the latest change.

1	Disable-SPFeature SMayes.SharePoint_ExampleFeature -Url http://default.smayes.com/sites/examplefeature

2	Uninstall-SPSolution SMayes.SharePoint.wsp

3	Remove-SPSolution SMayes.SharePoint.wsp

4	Add-SPSolution \SMayes.SharePoint\SMayes.SharePoint\bin\Debug\SMayes.SharePoint.wsp

5	Install-SPSolution SMayes.SharePoint.wsp -GACDeployment

6	Enable-SPFeature SMayes.SharePoint_ExampleFeature -Url http://default.smayes.com/sites/examplefeature

5. I will then visit the site to see the change…

What happened? The title didn’t change?! What is wrong?
The problem occurred during Step 4. When the first command deactivated the feature, that cmdlet called the SharePoint DLLs which in turn called the SMayes.SharePoint assembly. This loaded the assembly in the PowerShell.exe process. Once the assembly is loaded, it will not be unloaded.
That’s the issue here: Once a DLL is loaded in a .NET process, it will not and cannot be unloaded!
So what? This means that when I executed the Enable-SPFeature cmdlet, PowerShell was still referring to my old code that was loaded earlier and therefore was not using my updated code! Opening a new PowerShell instance and executing the activation in that instance will cause the latest code to be used since the new process will be getting the updated DLL from the GAC.
In summary: Whenever you are deploying code updates, the proper way to execute the redeployment would include closing the current PowerShell process and opening a new PowerShell process as soon as new assemblies are deployed. This will ensure that further commands, such as feature activations, will not use outdated code.
Note that while the issue I described above pertains specifically to a feature receiver, it would also equally pertain to an event receiver, timer job, or other piece of code within a deployed assembly called by the SharePoint API. This issue is also a general issue across the board whenever a process (PowerShell, W3WP, OWSTimer, etc.) is using a custom-built assembly. This is why, when deploying new assemblies, W3WP is typically recycled. Also ensure that OWSTimer is recycled if there are any timer jobs being deployed.

Other solution for this is Increase the AssemblyVersion  in AssemblyInfo.cs and everywhere where it is referenced.