PowerShell cmdlets ease SharePoint 2013 backup

PowerShell cmdlets ease some of the pain points of SharePoint 2013 backup. Here are some tips on using PowerShell for SharePoint disaster recovery.

SharePoint administrators have long used the STSADM utility as a tool for performing command-line backups of SharePoint site collections. However, Microsoft is phasing out legacy command-line tools in favor of PowerShell cmdlets.

The primary benefit of the change is that PowerShell cmdlets are easy to use in scripted operations -- which can be useful when performing backups. With SharePoint 2013 disaster recovery, it's possible to perform command-line backups of site collections with PowerShell. In this article, I'll show you how it's done.

SharePoint 2013 backups: Required permissions

Before you can use PowerShell for SharePoint 2013 backups, you need certain permissions. The person who performs SharePoint disaster recovery must be assigned the db_owner role on any SQL Server database that will be updated as a part of the backup operation. Likewise, the administrator must also be added to the securityadmin role on the SQL server instance that SharePoint uses. In addition, you must be a member of the local administrators' group on the computer from which you will run the PowerShell cmdlets.

This article assumes you will run the various PowerShell cmdlets directly on the SharePoint server to back up. It's possible, however, to back up a remote SharePoint server. In an effort to make PowerShell a viable option for managing cloud applications -- such as SharePoint -- Microsoft has gone to great lengths to design the most recent version of PowerShell to work equally as well on local and remote servers.

SharePoint 2013 Management Shell
Figure 1. The Start screen contains a tile labeled SharePoint 2013 Management Shell.

Identifying the site collection

Before you can perform a backup at the command line, you need to gather some information: You need to know the globally unique identifier (GUID) or the URL of the site collection you plan to back up. The GUID is a unique identification number assigned to the site collection. You can acquire this information directly through the SharePoint Management Shell. If you use Windows Server 2012, the SharePoint Management Shell is accessible from the server's Start screen, as shown in Figure 1.

When the SharePoint Management Shell opens, enter the following command:

Get-SPSite | FL –Property URL, ID

PowerShell command GUI URL
Figure 2. This PowerShell command returns each site collection's URL and GUID.

When you execute the command, SharePoint returns the URL and the GUID of each SharePoint site. You can see what the command looks like in action in Figure 2.

Performing a SharePoint 2013 backup

Now that you know the URL and GUID for the various SharePoint site collections, you can move forward with the backup. The cmdlet that you will be using is Backup-SPSite. Because this is a SharePoint-specific cmdlet, you will need to execute it through the SharePoint Management Shell. The command syntax looks like this:

Backup-SPSite –Identity <the site collection's URL or GUID> -Path <path and filename of the backup file> [-force] [-nositelock] [-UseSQLSnapshot] [Verbose]

PowerShell Backup SPsite command
Figure 3. This is what the Backup-SPSite command looks like when it runs.

Normally, when you use this command, the only information you have to supply is the URL or GUID for the site collection you want to back up, as well as the path and filename of the backup file. For example, the backup command might look like this:

Backup-SPSite –Identity 0913b7a2-8556-4f2e-b0fa-43cd4bb80a6b –path C:\data\backup

SharePoint backup file
Figure 4. A backup file is created in the specified location.

As you can see in Figure 3, when run successfully, the command does not produce visible output. However, a backup file should be created in the location specified, as shown in Figure 4.

In the previous example, a backup was created using the bare minimum set of parameters. You can use several optional parameters when backing up SharePoint in this way. The optional parameters include:

  • Force: This parameter applies if you want to overwrite a previously created backup of the same name.
  • NoSiteLock: When you create a backup in this way, there is a temporary read-only lock on the site collection throughout the duration of the backup, which preserves backup integrity. You can use the NoSiteLock parameter to maintain read/write access to the site collection during the backup, but doing so can result in a corrupt backup if users modify site collection data while it's being backed up.
  • UseSQLSnapshot: The UseSQLSnapshot parameter creates a VSS snapshot of SQL server data as a part of the backup process. Microsoft strongly recommends using this parameter for the enterprise edition of SQL Server.
  • Verbose: The Verbose parameter provides Verbose output. With this option, the command output provides detailed information about the operation as it progresses.

Restoring a SharePoint backup

The restoration process is similar to the backup process. Restorations are performed with the Restore-SPSite cmdlet. At a minimum, this cmdlet requires you to provide the name of the backup file and the name and path of the SharePoint site you want to restore.

Suppose, for example, you wanted to restore a site named MySite on a server named Lab1 and using a backup file named C:\Data\Backup. You could accomplish the restoration using a command similar to this one:

Restore-SPSite http://Lab1/sites/MySite -Path C:\data\Backup

Microsoft makes it relatively easy to use PowerShell to perform a site collection backup for disaster recovery purposes. This type of backup is useful as an impromptu method for quickly backing up a site collection prior to making major changes to it.

Dig Deeper on Enterprise SharePoint strategy