The steps at the beginning of the previous section
show you one method by which you can create a backup of a database in
SQL Server 2008; you can use them to back up pretty much any database
hosted in a SQL Server 2008 database instance. There are other more
complex ways to create database backups in SQL Server 2008, such as
T-SQL scripting and maintenance plans, but as mentioned earlier, it is
best to leave those more involved approaches to the experts. Because you
now have a starting point for backing up your SharePoint environment
via SQL Server, it is important to start thinking about the issues and
restrictions specific to SharePoint that you need to address when moving
forward with the process.
Tip
For the best results when
backing up your SharePoint databases, plan on executing the backup
operations during periods of reduced user activity in your SharePoint
environment, such as after normal business hours or during planned
maintenance periods. Also, avoid scheduling them against other scheduled
activities within the farm itself, such as search crawls or usage log
processing. This ensures that a minimal number of changes are being made
to your databases while the backups are being created; in addition, it
prevents your end users from experiencing performance issues when
attempting to access SharePoint. SQL Server backup operations can be
resource intensive for their host instances, and you should try to avoid
impacting SQL Server’s ability to serve its data to Share-Point as much
as possible.
If you need to back up a
SharePoint database with SQL Server during normal business hours or when
there is regular or elevated user activity in the sites within that
database, consider applying a read-only site lock for affected site
collections in the SharePoint Central Administration site or with
PowerShell prior to executing the backup. This action can ensure that
your users do not encounter degraded performance when accessing the site
during a backup operation, as well as prevent them from tying up the
database when the operation is also trying to use it. This is not
required for a backup operation but can reduce the time a backup takes
to complete and the number of support calls that may be made regarding
poor performance. If you are making a backup through the Central
Administration site or via a PowerShell cmdlet, SharePoint automatically
sets the targeted site collection to read-only, but with SQL Server,
you must manually configure the site collection before backing it up.
What Can Be Backed Up
Above all else, the
most important aspect of your SharePoint environment, the reason it is
so important to your business, is what your end users put into it. The
contents of your SharePoint sites, whether they are documents, lists,
forms, or some other form of knowledge capital, are most likely to be
the first and foremost item that your organization needs replaced should
disaster
strike your SharePoint environment. Happily, you can easily back up
SharePoint’s content databases and restore them at a later date using
SQL Server’s tools, using either the steps described earlier or the
other options that SQL Server offers.
Note
The location you select for
your backup media set must be associated with or available from the
server hosting the SQL Server instance that you are connected to. So if
you are running SQL Server Management Studio on your workstation and
connecting to a remote database instance, you are only able to save the
backup to a file system directory or attached tape drive on the database
host server, not on your local workstation. Once you create the backup,
you can copy it to your local workstation if you desire, but you cannot
create backup files on your local workstation through the backup
operation.
In addition to your
SharePoint content databases, don’t overlook other databases in your SQL
Server environment that may contain critical information for your
SharePoint environment, even if they are not explicitly SharePoint
databases: SQL Server’s system databases. Every SQL Server instance is
created with several default databases that are required to store
critical data about the state of the instance, such as its MASTER, MSDB,
MODEL, and TEMPDB databases. You can also back up these system
databases if you want to preserve the most recent state of your SQL
Server instance. It may not be necessary to do so, depending on your
requirements for data preservation and your ability to rebuild the
instance, so you should validate your plans with your SQL DBA, if
possible. Of those databases, the MASTER, MSDB, and MODEL databases are
potential candidates that you should consider backing up; the TEMPDB is
re-created every time a SQL Server instance is restarted.
What Cannot (or Should Not) Be Backed Up
Much like the
out-of-the-box backup tools provided with SharePoint, SQL Server cannot
back up your SharePoint environment’s IIS Web server settings, custom
code or site templates, the SharePoint Root directory (also known as the
14 Hive), or any other items located in the file system of your
SharePoint servers. Because these items are not stored in a SharePoint
database in SQL Server, it stands to reason that they cannot be backed
up. Nonetheless, it is important to keep this fact in mind when
developing your comprehensive disaster recovery plan so that you are
aware of what holes you need to fill with alternative tools or
approaches.
If your SharePoint content is
being stored in an RBS-enabled content database, you are not directly
backing up BLOB data when you back up your database; you are simply
backing up pointers that are understood by the RBS provider that is
associated with the database. To protect the BLOB data that is tied to
the content database, your backup strategy must incorporate your RBS
provider; more specifically, you must ensure that the storage location
or locations that the RBS provider uses are protected by some data
protection strategy. This makes the total protection of
SharePoint data stored in RBS-enabled content databases more difficult,
and any plan depends on the nature of the RBS provider.
It is important to understand the
details of this constraint. It only pertains to backups performed using
SQL Server’s tools, any other backup tools that operate directly
against the databases, or any non-Microsoft RBS solutions. If you are
backing up an RBS-enabled content database with SharePoint backup tools
in the Central Administration site or PowerShell via the FILESTREAM
provider, the database and its associated BLOBs are backed up together
in a single operation because SharePoint’s application programming
interfaces (APIs) hide RBS implementation details from the applications
that use them. If you are using a third-party RBS provider, Share-Point
2010’s backup tools do not include those BLOBs; you must manually back
them up.
The two major aspects of a
SharePoint environment that we haven’t covered yet are its configuration
(specifically its configuration database) and its Service Applications.
Although you can back up your SharePoint 2010 farm’s configuration
database and the databases associated with its Service Applications
using SQL Server’s tools, you also need to understand how to use the
backups of those items. With Service Applications, you can restore a
backup of their associated database, but you must have taken a backup of
the Service Application through the Central Administration site or
PowerShell and restored that into a farm before you can restore its
database. In most cases, SharePoint’s built-in tools or a third party
backup tool is going to be a better option for protecting those items in
case of a disaster. There can be utility in creating SQL Server backups
of the Service Application databases, but it is more as a point of
reference or referral than for disaster recovery protection.
With the
SharePoint farm’s configuration database, you can’t restore directly
back into a live farm; there’s just no supported way to do it with SQL
Server’s tools. The good news with Share-Point 2010 is that this is not
the end of the discussion. SharePoint 2010 introduces several new tools
in the area of backup and restore. Interestingly, one of those tools
changes what you can now do with SQL Server backups of a farm’s
configuration database. One of SharePoint 2010’s new PowerShell cmdlets,
Backup-SPConfigurationDatabase,
allows you to generate a configuration database backup of a
configuration database attached to your current farm, a separate farm
(assuming the account running the script has the proper rights in that
farm), and most importantly, a configuration database that is not
attached to a farm.
This means you could take a SQL
Server backup of your configuration database and restore that database
to a SQL instance in the event of a disaster. You could then extract the
details of the database’s configuration using Backup-SPConfigurationDatabase.
You can then use this backup like you would any other configuration
database backup created via the PowerShell cmdlet, except that you
preserved the data in it via SQL Server’s tools instead of SharePoint’s.
Note
This
aspect of SharePoint 2010’s new configuration backup functionality is
only possible via the PowerShell cmdlet; the Central Administration site
can only take configuration database backups of the farm it governs.
Database Sizing
As with any SQL Server
backup operation, the size of the SharePoint database you are backing up
directly influences the amount of time that the operation takes to
complete: the larger the database, the longer it takes to finish. As
your databases grow larger, you need to continually evaluate the timing
and approach you take when backing them up so you can minimize the
impact of your backup operations on your SharePoint environment’s
ability to serve its users. You may find that after a certain point you
are no longer able to complete full backup operations quickly enough to
meet your desired schedule. When this happens, consider using
differential backups or moving some site collections to new content
databases to shorten your backup periods. Monitoring and managing the
size and usage of your SharePoint databases should already be a part of
your operational SharePoint maintenance plan, but these activities
become even more important when you start considering disaster recovery.
Tip
There is no hard, fast limit
on how large a SharePoint site collection should be. In some cases,
SharePoint site collections and their associated SQL Server content
databases have grown to be hundreds of terabytes (TB) large and still
been viable for end users. But just because this is possible does not
make it feasible, especially from a disaster recovery perspective.
Microsoft recommends limiting your content databases to 200GB and an
individual site collection in a database to 100GB unless it is the only
site collection in a database, but these are not absolute. Discuss this
topic with your organization’s SQL Server DBA, because this person often
has preferences for general database size limits that need to be
observed.
The good news is that
SharePoint can be quite flexible when it comes to its content databases,
allowing you to associate one to many of them with a single Web
application. The main limitation is that you cannot divide a site
collection across content databases, which means that if a single site
collection grows beyond your size restrictions, you must split it into
two collections or have content removed to comply. SharePoint
administrators also have several commands available, such as the Move-SPSite PowerShell cmdlet, to help them move site collections from one content database to another.
Another less obvious item to
consider is how the site collections within your SharePoint databases
are utilized. If numerous users access the site, collaborate on
documents, or update content at the same time, it can directly impact
your backup and restore planning. These activities lead to
SharePoint reading and writing to its databases with increased
frequency, which in turn means SQL Server is writing a large amount of
data to the transaction logs associated with these databases. Because a
full backup of a SQL Server database includes the database’s active
transaction logs, heavy usage of your sites adds to the time it takes to
back up (and restore) the databases associated with them. If you find
that this is negatively affecting your ability to preserve your
SharePoint farm’s databases, you may need to reevaluate your farm and
site hierarchies to better distribute use traffic across databases.
Note
The previous database
sizing issues have a similar impact on SQL Server restore operations.
One reason it is important to test both your backup and restore
strategies is so that you have an accurate estimate of how long each
activity should take in expected conditions. If your restore operations
are taking hours to execute due to the size of your databases and your
system needs to be available as soon as possible, you are better served
by finding that out through testing rather than the first time you
execute your disaster recovery plan during an outage that is costing you
real money every second.
