Before we can get into the nuts and bolts of using
SharePoint 2010’s new PowerShell backup and restore cmdlets, it’s
important to look at the things you need to have in place and understand
to properly use PowerShell, SharePoint 2010, and its cmdlets in your
environment. Accessing the SharePoint 2010 cmdlets is not something you
can do by simply opening a PowerShell command prompt, and there are
certain prerequisites that must be met to have the rights and resources
necessary to use them properly. You also need to be mindful of several
important points about how to properly use and integrate these cmdlets
in your own custom scripts.
Accessing the SharePoint 2010 Management Shell
On a Windows Server 2008 server
with SharePoint 2010 installed, SharePoint 2010’s PowerShell cmdlets
can be accessed two ways: via the SharePoint 2010 Management Shell
shortcut in the Start Menu’s Microsoft SharePoint 2010 Products
directory, or by loading the SharePoint 2010 snap-in (Microsoft.SharePoint.PowerShell) for PowerShell via the Add-PSSnapin
cmdlet. Both approaches load the same set of SharePoint 2010 cmdlets
into the current PowerShell session, so you can use them to configure
and administer your SharePoint environment.
In previous releases of the
SharePoint platform, it was at best a challenge to determine what rights
a user needed to have to run administrative commands from the command
line. It was often more of a blindfolded fishing expedition through a
minefield of incomplete information and half-truths. (Unless you read
the SharePoint 2007 Disaster Recovery Guide—we
never steered you wrong!) Well, as if the addition of PowerShell itself
wasn’t good enough, SharePoint 2010’s command line administration story
is so much better this time around thanks to one specific cmdlet
designed to make the process of permission and rights assignment much
simpler: Add-SPShellAdmin.
Every cmdlet we’ll be
discussing in this chapter requires that the account used to run it be
granted rights within the targeted SharePoint farm via Add-SPShellAdmin, so you need to be ready to use it for any account you may use to run these cmdlets. But what does Add-SPShellAdmin
do? As you can probably infer from the name (naming conventions for
PowerShell cmdlets are discussed later in this chapter), it grants a
named user’s account administrative rights in SharePoint via PowerShell.
Now, there are some specific things that the Add-SPShellAdmin
cmdlet does to grant those SharePoint administrative rights, and it is
important to understand what it does behind the scenes within your
SharePoint environment before you just go blindly running it for all
your administrative users. Add-SPShellAdmin grants targeted accounts the following rights:
SharePoint_Shell_Access database role membership. The user’s login is added to the SharePoint_Shell_Access
role. (If this role does not exist in the target database, the cmdlet
creates it.) This is important to note, because the user’s login gains
SQL Server’s db_owner and securityadmin
rights in the database targeted by the cmdlet by associating it with
that SQL Server role, something you should not take lightly.
Database-specific rights. Add-SPShellAdmin can target specific databases within your farm via the –Database
input parameter. If you specify a database, the user is added to a role
that has those rights in the farm’s configuration database, the Central
Admin site’s content database, and the targeted database. If you do not
specify a database, the cmdlet grants the user rights for the farm’s
configuration database by default.
WSS_ADMIN_WPG security group membership. The user is also added to the WSS_ADMIN_WPG
local security group on all servers in the farm with the SharePoint
Foundation 2010 Web Application role, which grants certain
administrative rights in IIS and the file system of those affected
servers.
As you can see, these are
certainly nontrivial rights within your farm, and only administrators
who you trust to use those powers properly should be added to the SharePoint_Shell_Access
role. A single misstep with these rights can drastically impact your
environment, and that’s something we would encourage you to impress upon
any administrator you place within the role.
Before covering the
various cmdlets that can protect your SharePoint 2010 farm, it’s
important to briefly examine the structure of PowerShell cmdlets and how
they are used. First and foremost, cmdlets follow a strict naming
convention, starting with a verb describing the action the cmdlet
performs followed by a noun that describes the target of the action.
Directly following the name of the cmdlet is its input parameter(s),
which defines the specific conditions that the cmdlet should use when
run. For a complete listing of the PowerShell cmdlets available with
SharePoint Foundation 2010, see http://technet.microsoft.com/en-us/library/ff686791.aspx, and for a similar listing for SharePoint Server 2010, see http://technet.microsoft.com/en-us/library/ff678226.aspx.
Note
PowerShell is not case
sensitive; you can execute its cmdlets using all caps, all lowercase, or
a combination of the two. It does not behave differently depending on
the casing used.
Tip
One incredibly useful feature of PowerShell is its built-in Get-Help cmdlet. A call to Get-Help
followed by the name of the target cmdlet displays a great deal of
information on the cmdlet, as well as a display of all the input
parameters you can use when running the target operation. It’s also
invaluable to add -Examples to the end of the call, because it provides actual examples of how to use the cmdlet.
PowerShell Backup and Restore Prerequisites
In addition to the rights granted via Add-SPShellAdmin,
the account you are using to execute SharePoint 2010’s backup and
restore cmdlets, as well as the account serving as the identity of the
SQL Server service on the SQL Instance (or instances) hosting your
farm’s SharePoint database, must have the right to read from the
directory used as the target storage location for the backup files that
will be created. It must also be able to write and update files in the
directory. The configuration of that target storage location is somewhat
flexible, depending on your Share-Point farm’s configuration. If the
SharePoint server you’re using to run the cmdlets is also the server
hosting the farm’s SQL Server database instance, you can map the
directory you use as the target storage location via a file system path
such as C:\backups. In all other cases, a file share mapped via a UNC path, such as \\server\backups,
is the only way you can reference the location when using the cmdlets.
Shared UNC paths are the type of location most commonly used; separating
the farm’s database instance to its own server is a highly recommended
configuration, especially for larger environments.
Caution
As with the
Central Administration site’s backup and restore tool, the amount of
storage space available in your target storage location is important to
consider before backing up your SharePoint farm with SharePoint 2010’s
PowerShell cmdlets. The cmdlets do not automatically compress files or
archive older files to free up additional space as needed, so the onus
is on your organization to ensure that the selected storage location is
large enough to hold your backup files.
Scripting SharePoint 2010’s Backup and Restore Cmdlets
The majority of this chapter
is geared toward explaining what you can and can’t do with Share-Point
2010’s backup and restore cmdlets, but before we get to that, we want to
get you thinking about something else: how you can and should use them.
The most important use of these cmdlets you need to be thinking about
is how you can create PowerShell scripts that include and extend them,
so you can protect your farm completely, manage your farm’s resources
effectively, and be confident that your farm is being protected the same
way each time a script is run. As we cover each of the cmdlets to
follow, we’ll provide you with basic examples for how to use them, as
well as (when it makes sense) more advanced descriptions of how to
integrate each into an effective script for protecting your SharePoint
2010 farm.
Note
Keep in mind as you’re
reading this chapter that many of the tangible scripting examples focus
on the cmdlets that back up SharePoint 2010, not those that restore it.
The fact of the matter is this: backing up is a repeatable exercise that
you have control over when and how it executes. On the other hand,
restoring a backup is usually something you don’t know you have to do
until a need is at hand and the circumstances and conditions surrounding
that restore operation are impossible to predict. Now, don’t let that
dissuade you from scripting a restore operation; there are times it may
make sense to do so, such as an automated process to replicate a
production farm’s configuration into a testing or development
environment. But in our context of SharePoint 2010 disaster recovery,
there just isn’t a lot of need for scripting restore operations, so we
haven’t spent much time covering that topic in depth.
You need to
understand some things about creating successful scripts that use and
take advantage of these new SharePoint 2010 backup and restore cmdlets.
Keep in mind that, although these cmdlets offer a range of
functionality, there are still things they cannot do. Don’t forget:
these cmdlets are written to work in both manual and scripted
situations, so they have to be able to handle one-off uses just as much
as they do repeated uses. This means that your script may have to
include some logic or processing that varies the way a given cmdlet is
called based on variable circumstances, because these cmdlets are not
capable of such behavior.
The best example of this
shortcoming is in the area of storage management. With a one-off use of a
backup cmdlet, all you need is a storage location with enough space to
hold your backups. But if you’re scripting a backup process, it’s a
different story. Continually using the same backup location to store a
backup, especially a full backup of a complete SharePoint 2010 farm,
requires an astronomical amount of storage. It is far more likely that
your script is going to have to help you manage your storage, say by
taking actions like deleting backup files older than a certain date,
running differential backups on a much more regular basis than full
backups, or a combination of the two.
Note
SharePoint backup cmdlets do
help in this area somewhat by automatically saving backups into unique
directories, which can make it easier to identify and classify backup
files over time but still does not directly address the issue of storage
consumption.
The type of backups you take
is important from another perspective: the amount of time it takes to
restore your backups. Although differential backups are great for their
lower use of storage, it can take longer to restore large groups of
differential backups because you must apply each in succession to fully
include updates to the targeted item since its last full backup. Having a
high number of differential backups can affect your ability to meet
recovery time objectives (RTOs). Your script should allow for some
flexibility in the scheduling and type selection of your backups so that
you can achieve the best possible balance between reducing the storage
impact of your backups and reducing the time it takes to restore those
backups.
Take some time to consider
whether there are items within your farm that need to be protected
uniquely, say by backing them up on a different schedule than the rest
of the farm, having them stored in a different location, or using a
different set of parameter inputs. If you have a series of high-profile
site collections within your farm, they may have a more stringent set of
recovery point objectives (RPOs) and RTOs than the rest of the farm.
You may find that your users’ My Sites do not need to be backed up as
frequently. Perhaps you need more granular status reporting for a
complex Web application that often has failing backups. Regardless of
the reason, make sure to take requirements like these into account when
creating your scripts.
Just because you may be an
IT professional writing an administrative script, don’t overlook the
opportunity to incorporate key software development best practices into
your script, such as error
reporting, logging, and testing. Your SharePoint backup and restore
scripts need to be rock solid. You need to have complete faith in a
resource you’re creating to protect your SharePoint environment day in
and day out, so make sure to write a script that inspires that kind of
faith. First and foremost, always test your scripts to make sure they do
exactly what they’re supposed to do; it is far better to take some
extra time to identify a potential issue up front than to have it
identified for you in a production environment during a catastrophic
failure. Integrate logging and reporting into your script, so that if
there is an error, you can be notified as soon as possible and work to
correct it. PowerShell offers the ability to communicate in a lot of
different ways (the Windows Event Log, e-mail, text messages via Short
Message Services [SMS], and so on), so take advantage of that.
Finally, PowerShell’s
scripting language offers you unbelievable access to a huge range of
functionality, code, and tools to really enhance your scripts. Its
intrinsic pipeline capability allows you to send the output of one
cmdlet directly to another for further processing, a robust feature that
simplifies a script’s logic and helps you to better manage data within
the script. It has direct access to Microsoft’s .NET Framework, as well
as the SharePoint Object Model, allowing you to access code and
functionality that may not be exposed by SharePoint 2010’s other
PowerShell cmdlets. You can also access more traditional Windows
resources such as Windows Management Instrumentation (WMI) objects, the
Windows Registry itself, and the file systems of your servers. Don’t
overlook any potential available resources that these items, and many
others, may offer you when writing your backup scripts; they can make
your scripts more useful and perform better when put to good use.
