Using SharePoint 2010’s Catastrophic Backup Cmdlets

Backup-SPFarm has a broad-reaching scope and can be put to use in a number of versatile ways. As its name implies, the primary use of this cmdlet is to create a backup of an entire SharePoint farm. You can also use it to identify individual content components within a farm that can be backed up, back up those individual components, or create a backup of a farm’s configuration settings. Let’s look at an example of how Backup-SPFarm can make a full backup of a Share-Point 2010 farm:

Backup-SPFarm -Directory \\foo\backups -BackupMethod Full

Now, this example is pretty straightforward; in it we passed the Backup-SPFarm cmdlet two input parameters—one indicating the directory that the backup files should be stored in, and one indicating what type of backup should be created. The parameters you choose to provide with your call to Backup-SPFarm directly affect what kind of output it generates when run. There are two distinct sets of parameters you can use to call Backup-SPFarm: one to generate backups and one to identify components within a farm to back up. The following lists highlight the available parameters for each set, as well as what data you should be supplying for those parameters.

The first parameter set we’ll examine is the bread and butter of Backup-SPFarm. It is used to create a backup of your farm or an individual component within it. The items in the list that follow describe the various parameters to call Backup-SPFarm to create that desired backup:

• Directory. When you’re performing a backup with Backup-SPFarm, this parameter is required (unless the –ShowTree parameter is provided; see the next list for further information). The target directory can be on the file system if SharePoint is installed on the same server as its back-end database; otherwise, it must be a UNC shared directory. You can use this directory to store multiple backups for your farm. SharePoint automatically creates child folders within the directory to store each backup’s files.

• BackupMethod. When you’re performing a backup with Backup-SPFarm, this parameter is required (unless the –ShowTree parameter is provided). Acceptable input parameter values are “Full” or “Differential” and determine what type of backup is made for the target SharePoint component. Remember, to complete a differential backup with this cmdlet, you must have already run at least one full backup of the item you are targeting. Interestingly, some service applications always require a full backup; if you use the Differential option when backing up one of these service applications, SharePoint still performs a full backup.

• AssignmentCollection. This is an optional parameter, intended to allow for the proper disposal of objects. This parameter allows those objects to be assigned to a variable with an object of type SPAssignmentCollection, which the cmdlet disposes of when it is done with them. For more information on this important parameter, see the “SharePoint Object Disposal” sidebar following this list.

• BackupThreads. This parameter is not required. It determines the number of threads SharePoint uses to complete the backup operation and must be an integer from 1 to 10. If no BackupThreads value is provided, SharePoint defaults to three threads.

  Note

  The more threads that are used, the more components that can be backed up at the same time, which has the potential to reduce the time necessary to complete the backup operation. The trade-off with this is that the use of additional threads adds more data to your backup logs and makes them more difficult to read, because entries are entered in the order they occur with no correlation to which thread they are related to. If you are troubleshooting issues with your backups, reducing this value to one thread makes the log files much more readable.

  
  

• ConfigurationOnly. This is an optional parameter that does not actually require that an input value be provided for it. If this switch is used, the cmdlet only backs up the configuration data for the item targeted, whether that is the full farm or an individual component of that farm. It is also important to note that you can only use this parameter against the configuration data for the farm that the server hosting the session for the SharePoint Management Shell belongs to. There is another SharePoint 2010 backup cmdlet that provides similar functionality to Backup-SPFarm when this parameter is used but is not constrained by this restriction to the current farm, Backup-SPConfigurationDatabase.

• Confirm. This is an optional parameter. If this parameter is used with an input value of True, the cmdlet prompts the user to confirm that he wants to proceed with the action. If a value of False is provided, the cmdlet proceeds without prompting for permission once executed. The default value for this parameter is False.

• Force. This is an optional parameter that does not actually require an input value to be provided for it. If this switch is not used, the cmdlet does not proceed with the backup operation if it estimates that there is not enough disk space available to store the backup. If it is used, that check is overridden, and the backup is executed regardless of how much storage is available.

• Item. This parameter is not required. By default, if no item is specified, the entire farm is backed up. If an Item input parameter is provided to specify the SharePoint component to be backed up, it must be a valid item in the farm. If the item has spaces in its name, the entire item must be enclosed within quotation marks (“ ”). If the exact name or path for the desired component is not known, you can use the ShowTree switch to list the components available within the farm. (See the following list for more information on the ShowTree switch.) This parameter allows the cmdlet to be used to protect Web applications, service applications, content databases, and much more within your SharePoint farm.

• Percentage. This input parameter is not required. If a value is specified for the Percentage input parameter, it must be an integer between 1 and 100 and is used to determine the frequency with which Backup-SPFarm reports progress of the backup operation. For example, specifying a value of 20 displays the progress of the backup operation for every 20 percent of the operation that is completed. If no Percentage parameter is specified, STSADM.exe defaults to reporting progress every 5 percent of the operation. This input parameter has no impact on the outcome of the backup operation; it only affects the amount of information that the cmdlet reports about its activities during the operation. SharePoint is not able to calculate the percent completed of the backup operation with 100 percent accuracy. You may find that your actual progress updates do not appear with exactly the requested frequency.

  Tip

  For large SharePoint components, Microsoft recommends that a Percentage input of 1 be used to provide the best status data about your backup operation.

  
  

• WhatIf. This is an optional parameter. If this parameter is used, PowerShell displays a message stating what the outcome of running the cmdlet will be, but the cmdlet itself is not executed. This can be helpful when testing scripts, allowing you to verify that you can provide the correct set of inputs and parameters to the cmdlet.
  

The second parameter set for Backup-SPFarm is best used to obtain valuable information about your farm for backing it up, rather than backing it up itself. The key parameter in this set is the –ShowTree parameter. Its presence indicates that the second parameter set is being used instead of the first.

• ShowTree. This is an optional parameter. If the ShowTree parameter is included with the call of Backup-SPFarm for a backup, the cmdlet does not complete a backup of any SharePoint components. Instead, it displays the components in the farm so that you can use their names to request a backup. If a value is specified via the Item parameter, any components that are not children of that input are excluded and marked with an asterisk (*). Any components that cannot be backed up are enclosed within square brackets ([ ]). See Figure 1 for an example of the output produced when you use this parameter with Backup-SPFarm.

  Figure 1. A call of the Backup-SPFarm cmdlet with the ShowTree switch in the SharePoint 2010 Management Shell window, and the output of the operation.

  

• AssignmentCollection. This is an optional parameter. It is used with this parameter set in the same way that it is in the first parameter set.

• ConfigurationOnly. This is an optional parameter. It is used with this parameter set in the same way that it is the first parameter set.

• Item. This is an optional parameter. It is used with this parameter set in the same way that it is the first parameter set.

• WhatIf. This is an optional parameter. It is used with this parameter set in the same way that it is the first parameter set.

The beautiful thing about PowerShell is that most cmdlets (when they’re well designed and written), do exactly what their names say they do, and that’s certainly the case with Backup-SPFarm. It definitely backs up a SharePoint farm. Using the first parameter set and the minimal set of inputs for it, you can easily back up your entire farm: its configuration, its contents, and its service applications. When we start to talk about the new PowerShell cmdlets for restoring content into SharePoint 2010, this becomes even more important, because we can restore each of these components in a SharePoint 2010 farm, something that was not necessarily possible in previous versions of SharePoint.

Another important aspect of the Backup-SPFarm cmdlet is its ability to back up individual components with the Item parameter. By specifying a section of your farm with the Item parameter, you can back up and protect it separately from the rest of your farm. If you want to make a copy of a Web application’s content database to transfer down to a farm in your testing environment or take an exact copy of the configuration of your farm’s Search service application for use in another production farm, you can do it with the Backup-SPFarm cmdlet and its Item parameter. The Item parameter also becomes much more potent when you combine it with PowerShell’s pipelining and looping capabilities; with some clever use of the PowerShell language and the Backup-SPFarm cmdlet and its ShowTree and Item parameters, you can individually protect multiple components within your farm without a great deal of effort. The possibilities for how you can use this cmdlet and its valuable options within your environment to meet its specific needs are quite impressive and give you diverse and creative options for protecting your SharePoint farm.

Don’t overlook the ability to back up the data about the configuration of your farm with Backup-SPFarm’s ConfigurationOnly parameter. This parameter highlights a new aspect of SharePoint 2010 that wasn’t possible in previous versions of SharePoint: backing up the configuration data and settings for your SharePoint 2010 farm, not just its contents. This means you can capture the overall setup of your farm and use it to re-create a farm with most of the same settings in another environment, such as a development farm or a disaster recovery environment for failover, both which are cases where having an environment identical to the production one can be valuable. Interestingly, this feature is so important in SharePoint 2010 that it’s also available via a separate cmdlet, which we’ll look at in a bit.

Please take note, however, that we did not say that the ConfigurationOnly parameter makes a “complete” backup of your farm’s configuration data. That’s because it doesn’t. SharePoint 2010’s configuration backups don’t make an exact copy of a farm’s settings; they only capture some of its portable settings and configurations.

Now that you’re familiar with Backup-SPFarm, let’s look at an example of a comprehensive approach to using that cmdlet to effectively and flexibly back up your SharePoint 2010 farm. The PowerShell function listed next, Backup-Farm, is designed to not only back up a SharePoint farm, but check its output log files for errors and then use another function (Record-Event) to report its findings. The function can be used to execute both full and differential backups via the $backupMethod input parameter and is set to target the entire farm regardless of the method provided. You can also specify the storage location of the backups via an input to allow for customization; the final two inputs are solely for error reporting.

Function Backup-Farm ($backupMethod, $backupDir, $errorFlag, $entryType)
{
  # Run a farm backup with the SP2010 CMDLET using the parameters passed in
  Backup-SPFarm -directory $backupDir -backupmethod $backupMethod

  # Get the most recently modified backup folder
  $newestFolder = (Get-ChildItem -path $backupDir | Sort -property LastWriteTime '
                 | Select-Object -last 1 -property FullName | format-table '
                 -hidetableheaders | out-string| foreach { $_.trim() } )

  # Build the file path for the most recently created backup log file
  $newestLog = Join-Path -path $newestFolder -childpath "spbackup.log"

  # Getting the number of errors in the backups log file
  #  (subtracting 1 for the reporting line at the end of the document)
  $errorLog = Get-Content $newestLog | Out-String
  $errorCount = [regex]::matches($errorLog,"error").count - 1

  # If there is an error, report it
  If ($errorCount -gt 0)
  {
   # Create Error Message
   $eventMsg = $eventMsg + "At least one error was found while making a " '
       + $backupMethod + "backup, stored in the " + $newestFolder + "directory. " '
       + "Please review the spbackup.log file in that directory carefully to " '
       + "diagnose and resolve the issue before running another backup."

   # Report an error
   Record-Event -eventMsg $eventMsg -entryType "Error"

   # Set the Error flag to "On"
   $errorFlag = 1
  }
  Else #Report the successful Farm backup
  {
   # Report the Deletion Event
   $eventMsg = "A " + $backupMethod + " backup of the farm was successfully " '
               + "backed up to " + $newestFolder + ". See " + $newestLog '
               + " for more information."
   Record-Event -eventMsg $eventMsg -entryType "Information"
  }
}


					  

As we’ve already mentioned, the Backup-SPConfigurationDatabase cmdlet is another option you have available to back up a SharePoint 2010 farm’s configuration, without including any of its contents. It works much like the Backup-SPFarm cmdlet when used with the ConfigurationOnly parameter, but there are some differences between that and the Backup-SPConfigurationDatabase cmdlet. The intent of each of these two options is similar, and the functionality that they use behind the scenes is pretty much the same, but those differences are crucial to understand.

When we were talking about the Backup-SPFarm cmdlet, you may not have noticed it, but we were careful to say that Backup-SPFarm is for use with your farm—the current farm that the server you’re running the cmdlet on is part of. That’s the way it works; Backup-SPFarm is for use with the current farm only; you cannot run it against other SharePoint 2010 farms if the server executing the cmdlet is not attached to them. But the constraint does not bind Backup-SPConfigurationDatabase; you can run the cmdlet against any farm’s configuration database, as long as the server hosting the cmdlet can connect to the database over the network and you as the cmdlet’s operator can provide the proper credentials to access the database. But the most important thing to take in about this cmdlet is that configuration databases targeted by Backup-SPConfigurationDatabase don’t even have to be used by an active farm. You can use the cmdlet to create a backup of any SharePoint 2010 configuration database as long as that database is attached to a SQL Server instance and running. Here’s an example of how to call Backup-SPConfigurationDatabase to back up a configuration database in a remote Share-Point server farm:

Backup-SPConfigurationDatabase -Directory \\foo\backups -DatabaseServer
RemoteSQLInstance -DatabaseName RemoteSPConfigDB

This capability may seem a little strange at first, but in reality, this is a powerful feature. It allows you to back up any configuration database, whether it’s from a running farm, a farm you shut down a few weeks ago, or even a SQL Server backup of a configuration database that you’ve brought back online for the express purpose of capturing its farm’s configuration and settings. Once you have that backup, there’s quite a bit you can do with it. This is another of those situations in which SharePoint 2010 gives you a great deal more flexibility and functionality than its previous versions. Now you can back up a farm’s configuration and have a template you can use to deploy as many times as you want, the same way every time. Now you can capture the exact settings of your farm, even if it’s encountered an error and offline, so you can recover not just your content, but the specific setup of the farm that was hosting it. Now you have a lot more ways to protect yourself from errors, corruption, and disaster and recover from them more effectively.

It may seem nice from a backup coverage perspective, but Backup-SPConfigurationDatabase’s ability to directly address configuration databases for other farms really starts to make the most difference when you think about it from the restore side of the equation. It’s not so much about targeting other active farms, because you can always just run the cmdlet directly in that farm. Creating a backup straight from a configuration database in SQL Server that isn’t associated with a live farm really allows you to protect your farm in a way that few, if any, of the other tools discussed in this book can. This becomes even more impressive when you consider the limitations of those other tools.

Microsoft does not support directly restoring a SQL backup of a configuration database to an existing or new SharePoint 2010 farm. The Central Administration site can back up a farm’s configuration, but you can’t schedule those backups.

But with Backup-SPConfigurationDatabase, you can restore a farm’s configuration data with little more than SQL Server backups of the database. This means that it makes a lot more sense to do regular backups of your farm’s configuration database with SQL Server; the backups can now play into a restore scenario, in much the same way that you can use the configuration database to protect your farm’s content databases. In the event of a disaster where you’ve lost your entire farm, you can restore a SQL Server backup of your configuration database into a SQL Server instance and with Backup-SPConfigurationDatabase create a SharePoint configuration-only backup of it. Then you can restore that configuration data into a new farm with the Restore-SPFarm cmdlet. It isn’t going to bring back everything, but it does restore important data about a farm and enables you to get that data restored much more quickly than other alternatives.

There are many similarities between the Backup-SPConfigurationDatabase and Backup-SPFarm, such as the Item and ShowTree parameters. They both create backup files in the same manner; they both write to the spbackup.log file; they’re both Pisces (just kidding). Really, most of the other difference between Backup-SPFarm and Backup-SPConfigurationDatabase are mechanical: they do have slightly different input parameters you can use to call them. Out of those differences, the only one worth noting is that there are no differential backups with Backup-SPConfiguration-Database; it only takes a full backup of a configuration database. Because the best use case for Backup-SPConfigurationDatabase is in a restore scenario in which you’re only running it once anyway, this isn’t a big deal (not to mention that the files generated by the cmdlet stay pretty small).

Before we dive into the specifics of the Backup-SPConfigurationDatabase, we want to mention one other difference about the two cmdlets. When run with its default settings, Backup-SPFarm uses three threads to back up a SharePoint 2010 farm; with the default settings, Backup-SPConfigurationDatabase only uses two. This is a pretty minor point (especially because you can’t control the number of threads that Backup-SPConfigurationDatabase uses), but if you ever get into fine-tuning the performance of your backups, you may want to take that difference into consideration so you know that they’re going to behave differently unless you specify the number of threads. If you’re concerned about performance, Backup-SPFarm is the only one of the two cmdlets that allows you to set the number of threads used; Backup-SPConfigurationDatabase doesn’t offer a BackupThread parameter.

To paraphrase B. A. Baracus, enough with all the jibber jabber; let’s talk about the details of Backup-SPConfigurationDatabase. The items in the list that follow describe the various parameters used to call Backup-SPConfigurationDatabase to create a backup of a SharePoint 2010 configuration database:

• Directory. When you’re performing a backup with Backup-SPConfigurationDatabase, this parameter is required (unless the –ShowTree parameter is provided; see the next list for further information). The target directory can be on the file system if SharePoint is installed on the same server as its back-end database; otherwise, it must be a UNC shared directory. This directory can store multiple backups for your farm. SharePoint automatically creates child folders within the directory to store individual backup files.

• AssignmentCollection. This is an optional parameter, intended to allow for the proper disposal of objects. Carefully consider using this parameter if your call of Backup-SPConfigurationDatabase also involves using SharePoint’s SPWeb, SPSite, or SPSiteAdministration objects; otherwise, it is not likely to be necessary.

• DatabaseCredentials. This parameter is not required; you should use it only if the account that executes the Backup-SPConfigurationDatabase cmdlet is not a member of the db_backupoperator role in the SQL Server instance hosting the targeted configuration database or SQL Authentication is used to connect to a database. The credentials provided should have administrator rights in SQL Server. If this parameter is not provided and required, the cmdlet prompts the user for the username and password values.

• DatabaseName. This is an optional parameter that does not actually require that an input value be provided for it. If this parameter is used, the cmdlet backs up the configuration database specified. If no value is supplied for this parameter, the cmdlet defaults to selecting the configuration database for the farm that the SharePoint 2010 server hosting the cmdlet is a member of.

• DatabaseServer. This is an optional parameter that does not actually require that an input value be provided for it. If this parameter is used, the cmdlet uses the SQL Server instance name to target the configuration database specified via the DatabaseName parameter, which should be hosted in that database instance. If no value is supplied for this parameter, the cmdlet defaults to selecting the database instance hosting the configuration database for the farm that the SharePoint 2010 server hosting the cmdlet is a member of.

• Item. This parameter is not required. By default, if no item is specified, the entire farm is backed up. If an Item input parameter is provided to specify the SharePoint component to be backed up, it must be a valid item in the farm. If the item has spaces in its name, you must enclose the entire item within quotation marks (“ ”). If the exact name or path for the desired component is not known, you can use the ShowTree switch to list the components available within the farm. (See the following list for more information on the ShowTree switch.) This parameter allows the cmdlet to be used to protect Web applications, service applications, content databases, and much more within your SharePoint farm.

• ShowTree. This is an optional parameter. If the ShowTree parameter is included with the call of Backup-SPFarm for a backup, the cmdlet does not complete a backup of SharePoint components. Instead, it displays the components in the farm so that their names can be used to request a backup. If a value is specified via the Item parameter, any components that are not children of that input are excluded and marked with an asterisk (*). Any components that you cannot back up are enclosed within square brackets ([ ]).

The syntax to use Backup-SPConfigurationDatabase in a script is really not that different from what you use with Backup-SPFarm. In fact, you may find that in most scripted situations,Backup-SPFarm with the ConfigurationOnly parameter works well enough to keep you from introducing another cmdlet into the script. Backup-SPConfigurationDatabase works just fine in scripted scenarios to protect your farm’s configuration data, but its primary use case is really more of a one-off, ad hoc type of situation in which you execute it when a specific need and situation arises.

Backup-SPSite

With the larger, farm-wide aspects of backing up SharePoint via PowerShell out of the way, let’s look at the more granular backup operations you can perform with SharePoint 2010’s Power-Shell cmdlets. Well, “operations” is a bit of a misnomer—there’s really only one additional cmdlet that we haven’t talked about for nongranular backup activities with PowerShell in Share-Point 2010: the Backup-SPSite cmdlet.

Before we dive into the nitty-gritty of that cmdlet, remember that the Backup-SPFarm cmdlet can granularly protect a SharePoint environment. You can use Backup-SPFarm’s Item input parameter to back up service applications, Web applications, content databases, search databases, and other content components down to the database level. If you need to protect an item higher up in SharePoint 2010’s logical hierarchy, you’re going to need to use Backup-SPFarm. But if you want to completely back up individual site collections in a farm, your only option is Backup-SPSite, because the smallest item that Backup-SPFarm can back up is a SharePoint content database.

Keep the specifics of that distinct level of granularity in mind when preparing to use Backup-SPSite; you can use it only to create backups of SharePoint 2010 site collections. You cannot individually target subsites (also known as webs within SharePoint 2010’s Object Model) beneath a site collection with the cmdlet, nor can you target individual items, lists, or libraries within a site collection or subsite. Administrators can back up site collections with the cmdlet by calling the Backup-SPSite-Identity parameter with a uniform resource locator (URL) or globally unique identifier (GUID) of the target site collection as an input parameter, and the -Path parameter with the details of where to create and store the backup file (either in the local file system of the server or a remote server via UNC path). cmdlet. In that call, they must specify at least two parameters: the

Backup-SPSite -Identity http://foo/bar -Path \\backups\foo.bak

The Backup-SPSite cmdlet is also a great example of why the use of PowerShell to administer SharePoint 2010 is such an important development. PowerShell’s core features, such as pipelining, object orientation, and looping, make it much, much easier to individually back up multiple site collections in a single process; something that would take quite a bit of VBScript and calls with STSADM.exe in previous versions of SharePoint can now be accomplished in a single line of PowerShell scripting. For example, let’s say that you need to back up all the site collections within a Web application owned by your company’s chief operating officer (COO), a Mr. John Doe, on a much more frequent schedule than the rest of your SharePoint farm, because Mr. Doe is kind of a big deal. An excerpt of the PowerShell script necessary to do that should look something like this:

$webApp = Get-SPWebApplication -identity http://foo
$sites = Get-SPSite $webApp -filter {$_.Owner = "BAR\JDOE"}
Backup-SPSite -identity $sites -path \\foo\backups

Now, you may notice that there’s no looping logic in the preceding script, and there’s a reason for that. Every PowerShell cmdlet returns its results as an object, and cmdlets that return multiple objects actually return those results as an array of objects. So the $sites variable is populated with all the site collections that Mr. Doe owns, not just one. That array is then passed to Backup-SPSite, which iterates through each site collection within the array and backs up each one individually.

Another great thing about PowerShell is that you can continue to improve these three lines of script in a couple of ways. First, there’s no need to hardcode the URL of the targeted Web application, the account ID for Mr. Doe’s account, or the location of the backup files created by the process. Instead, you can configure those items as parameters, which can be passed into a function containing the script, or as parameters for an entire script that the code would reside in. This allows you to reuse the script as needed to cover multiple Web applications, users, and storage locations.

The other thing you can do is rewrite the script as shown next to reduce the number of lines needed to execute the desired backups:

Get-SPWebApplication -identity $URL | Get-SPSite -filter {$_.Owner = $siteOwner} | Backup-
SPSite -path $backupStorage


					  

This is just one example of some of the exciting and useful things that administrators can do with PowerShell thanks to its advanced features and functionality. Because of that, it is important to not just zero in on what a single cmdlet like Backup-SPSite can do, but to consider how to combine with other SharePoint 2010 cmdlets like Get-SPWebApplication as well as other cmdlets, objects, application programming interfaces (APIs), and Web services that PowerShell makes available to you and your scripts. But before you can really get into the creation of those scripts, you need to have a good understanding of what is needed to effectively use this key cmdlet to properly back up a SharePoint 2010 site collection. The list that follows details each switch that you can use with Backup-SPSite and its purpose:

• Identity. When you back up a site collection, this parameter is required and must be a valid URL or GUID for the target site collection.

• Path. When you back up a site collection, this parameter is required and must be a valid UNC or Windows directory path to a file that the backup is saved in. The account logged into the SharePoint 2010 Management Shell must have permission to write to the directory specified for this input.

  Tip

  Although you must specify a file name for the backup with this input parameter, there is no required extension to use when specifying the file name for your backup. Use something easily identifiable as a backup file, such as .bak. Regardless of the extension you specify, SharePoint creates your backup at the selected path.

  
  

• AssignmentCollection. This is an optional parameter, intended to allow for the proper disposal of objects. Carefully consider using this parameter if your call of Backup-SPSite also involves using SharePoint’s SPWeb, SPSite, or SPSiteAdministration objects; otherwise, it is not likely to be necessary.

• Confirm. This parameter is optional. When used in a call of Backup-SPSite, it forces the cmdlet to prompt the user for confirmation prior to executing the backup.

• Force. This parameter is optional; using it forces Backup-SPSite to overwrite any existing backup file matching the value of the –Identity parameter should one already exist.

• NoSiteLock. This parameter is optional; its use keeps Backup-SPSite from locking a site during the execution of the site collection backup. If this parameter is not used, the target site collection is only available for users to read content from. They are not able to add, modify, or delete content in it until the backup is done and the site is unlocked. If you expect your users to write to a target site collection while it is being backed up, do not use this parameter unless you absolutely have to. Allowing write access to a SharePoint site while it is being backed up can lead to inconsistencies or corruption in your site’s content. Keeping the target site collection locked during the backup process ensures the highest-quality backup and provides the best possible long-term experience for your users.

• UseSqlSnapshot. This parameter is optional. When you use it, Backup-SPSite creates a SQL Server database snapshot of the content database containing the site collection, and the backup of the site collection is created by referencing the snapshot rather than the database. Once the backup is completed, the cmdlet deletes the database snapshot. This parameter can be used only if your SQL Server instance supports the creation of database snapshots, so it is important to review your SQL Server edition prior to using it. If your instance does support snapshots, this parameter is recommended because it makes your site collection fully available to users during the backup. Because the cmdlet is reading from the snapshot and not the database, there is a drastically reduced chance of resource contention between it and the activities of your users.

• WhatIf. This is an optional parameter. If this parameter is used, PowerShell displays a message stating what the outcome of running the cmdlet will be, but the cmdlet itself is not executed. This can be helpful when testing scripts, allowing you to verify that you can provide the correct set of inputs and parameters to the cmdlet.