Granular Backup
The bulk of the Granular
Backup functionality that is included with SharePoint 2010 was included
in some form in SharePoint 2007, but it was not available from within
the Central Administration site. You could perform a site collection
backup easily with SharePoint 2007, for example, but you had to go to a
command line and type STSADM –o backup –url <YourSite’sUrl> -filename <SiteCollectionBackupFilename>. With SharePoint 2010, this functionality is exposed within Central Administration along with some brand new capabilities.
How Granular Backup Is Different from Farm Backup and Restore
Although
the Granular Backup functions are exposed in the same area of Central
Administration as the Farm Backup and Restore functions, they are not
the same. Under the hood, the catastrophic Farm Backup and Restore
functionality that has been discussed thus far leverages a number of
types that are contained within the Microsoft.SharePoint.Administration. Backup
namespace of the SharePoint object model. The functions that are
exposed by Granular Backup, on the other hand, are tied to a collection
of other types that reside in a variety of namespaces. For example, the
Export a Site or List option exposes functionality that resides in the Microsoft.SharePoint.Deployment
namespace—an area of the application programming interface (API) that
is associated with content deployment, not backup and restore.
This distinction is
important because you shouldn’t mistakenly think that the Granular
Backup functions operate and behave the same way that the catastrophic
backup and restore operations do. This is especially true for export
operations that use the content deployment types. Content deployment
operations are not intended to be full fidelity, meaning that only a
subset of content and property values can be exported or imported.
Backup and restore operations, on the other hand, are
full fidelity. This may seem like a minor point, but it carries
implications for the scenarios in which you can utilize backups and
exports.
Site Collection Backup
As its name implies, the Site
Collection Backup allows you to back up a single site collection within a
Web application residing within your SharePoint environment. To perform
this type of backup, SharePoint executes a combination of database
queries and export calls to yield a single backup file. The backup file
is commonly assigned a .bak
extension, but you can actually assign any extension you would like.
This file can then be used to restore the targeted site collection
in-place or in one or more other Web applications.
This is the same site
collection backup that could be performed with SharePoint 2007 through
STSADM.exe using the command line syntax STSADM –o backup –url <YourSite’sUrl> -filename <SiteCollectionBackupFilename>.
Central Administration in SharePoint 2010 simply wraps the site
collection selection and file name specification within a graphical user
interface (GUI) for more visually oriented administrators.
Prior
to starting, the backup operation temporarily sets the lock state for
the site collection to read-only if the site collection’s lock state is
either Not Locked or Adding Content Prevented. In such a situation, the
site collection’s original lock state is restored upon completion of the
backup. This lock state change is made to reduce the likelihood of
content changes during the backup process because such changes could
result in an inconsistent backup.
Microsoft doesn’t
recommend the use of site collection backups with site collections that
are larger than 85GB, but this is not a hard limit. As your site
collections approach and exceed 85GB, though, you would be wise to
investigate the use of SQL Server content database backups or
SharePoint’s native catastrophic backup functionality as a more
appropriate alternative to site collection backups.
Note
At the time when this book
was written, Microsoft’s TechNet site included a specific note stating
that site collection backups did not include workflow information. This
note is incorrect. Backups that are performed with the site collection
backup approach are full-fidelity and contain all workflow information,
including workflow history and workflow state. The note was originally
intended as a warning for exports that are performed with granular
export operations through types within the Content Deployment API, not
site collection backups.
Content Export
“Microsoft giveth, and Microsoft
taketh away” is a good way to summarize the arrival of the Export a
Site or List function in Central Administration. Although the GUI-based
manifestation of this functionality is new to Central Administration
with SharePoint 2010, the capabilities existed in the previous version
of SharePoint Designer for SharePoint 2007. With the redesign of
SharePoint Designer 2010 to make the application more task oriented,
however, GUI-based content backup and export functionality was removed.
Much like the Site
Collection Backup function just discussed, the Export a Site or List
function does exactly what its name suggests. Through a series of
drop-down selection controls, you can select an entire site collection, a
specific site, or a specific list within a site for export to a content
migration package file set. The file set is commonly given a .cmp extension, but that isn’t required. If no extension is specified for the file, .cmp
is assigned. You have the option of exporting security information with
the package, and you are given the option to decide whether all or some
versions of files and lists are exported.
As with the site
collection backup capability, administrators still maintain the ability
to execute export operations from the command line using both PowerShell
and STSADM.exe.
When You Should Use It
The Granular Backup
options overlap with the catastrophic backup and restore operations in
some places, but they are generally intended to complement them.
Catastrophic backup and restore
operations focus on the objects that exist at the macro scale above the
content database level—objects such as the farm, services, and Web
applications. It is best to think of the Granular Backup functions as
addressing those objects that exist within or below the content database
level, such as site collections, Webs, and lists.
Granular Backup operations
are well suited to migrating and moving content around, and they are
generally preferable to catastrophic backup and restore operations for
this purpose. Granular Backup operations generate a limited file set
(oftentimes only one file of interest), and their output is intended for
use in content duplication efforts. Copying content from one site to
another is a much easier affair with Granular Backup than it is with
Farm Backup and Restore options.
This flexibility comes
with some constraints, though. The practical size limitation for site
collection backups was already discussed. Granular operations, on the
other hand, target only one object at a time, be it a site collection,
site, list, or document library. Granular Backup operations are also
harder on SharePoint’s infrastructure resources due to their
read-intensive and processing-intensive nature.
One of the biggest
limitations for visually oriented administrators, though, is the
complete lack of restore options for Granular Backups and exports within
Central Administration. Central Administration provides a wonderful
interface for site collection backups and content exports, but it
provides no complementary functionality for restores and imports of the
items that result from these actions. Administrators must instead turn
to command line operations and Power-Shell for such activities.
Configuration-Only Backup
The concept of a
configuration-only backup is new to SharePoint 2010, and it is a direct
response to one of the heaviest criticisms levied against full farm
backup and restore in previous SharePoint versions; namely, it isn’t
possible to perform an out-of-place restore on a backed-up farm to
create a clone of it. Farm configuration databases are tightly coupled
to a SharePoint farm at both the logical and physical levels due to the
way server names and database connection strings are used, and practical
use cases involving the restoration of a farm configuration database
through any means are so narrow and uncommon that they are nearly
nonexistent.
Despite this fact, the desire to
find some way to make farm configuration settings portable under
SharePoint is common. Many administrators, for example, require a way to
create copies of their production environments for use in disaster
recovery, testing, development, content authoring, and other scenarios.
Unfortunately, platform support for this type of operation didn’t exist
in SharePoint 2007. In most cases, administrators had no practical
choice but to build a new farm each time and reapply configuration
settings through a carefully assembled script (at best) or in an ad-hoc
fashion (at worst).
To ease the administrative
burden associated with these types of scenarios, Microsoft introduced
configuration-only backup and restore with SharePoint 2010. Although it
isn’t a complete solution itself, it does improve the situation in this
area relative to SharePoint 2007.
When
a catastrophic backup is being set up, you have the option of backing
up content and configuration settings or configuration settings only, as
shown in Figure 10.
For the purposes of a
configuration-only restore, both of these backup types include the
configuration information that is needed if a configuration-only restore
is to be performed later. Put another way: you can perform a
configuration-only restore using either a configuration-only backup or a
catastrophic backup. The information that is restored includes the
following type of portable configuration data:
Antivirus settings
Information rights management (IRM) settings
Outbound e-mail settings
Customizations and solution packages
Diagnostic logging settings
When you perform a
configuration-only restore, these portable configuration items are
written to the configuration database of the target farm. The target
farm can be the farm where the configuration settings were backed up
using a catastrophic backup or configuration-only backup, thus providing
a mechanism for configuration rollback. The target farm can also be
another farm altogether, allowing the cloning of settings from one farm
to another.
Unfortunately, configuration-only
backup and restore is not a complete solution for configuration
documentation and replication. It fails to capture configuration data
associated with a number of critical components, including Web
application and Service Application settings. For this reason,
configuration-only backup and restore won’t remove the need for complete
farm documentation anytime soon. It does, however, bring administrators
one step closer to a future that is free of manual configuration
tracking.
Tip
Microsoft recognizes
that completely documenting a SharePoint farm’s configuration is
challenging. In an attempt to provide administrators with some
assistance in this area, Microsoft has created a PowerShell script that
does a solid job of documenting the overwhelming majority of
configuration items and settings in the typical SharePoint farm.
