Windows Vista
Windows 7
Windows Azure
Windows Server
Windows Phone
Windows Server

SharePoint 2010 : An Overview of Backup and Restore Capabilities (part 2) - Granular Backup & Configuration-Only Backup

- Free product key for windows 10
- Free Product Key for Microsoft office 365
- Malwarebytes Premium 3.7.1 Serial Keys (LifeTime) 2019
5/20/2011 5:54:05 PM

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.


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.

Figure 10. Configuration-only backup settings.

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.


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.

Other -----------------
- Exchange Server 2010 : Generating Reports (part 5) - Using the Microsoft Exchange Best Practices Analyzer (ExBPA) to Create Reports
- Exchange Server 2010 : Generating Reports (part 4)
- Exchange Server 2010 : Generating Reports (part 3) - Testing Mail Flow
- Exchange Server 2010 : Generating Reports (part 2) - Reporting Mailbox Folder Statistics
- Exchange Server 2010 : Generating Reports (part 1) - Generating Mailbox Statistics Reports
- SharePoint 2010 PerformancePoint Services : Using Windows PowerShell and Cmdlets (part 2) - Cmdlet Samples
- SharePoint 2010 PerformancePoint Services : Using Windows PowerShell and Cmdlets (part 1) - Cmdlets Available Out of the Box
- BizTalk 2010 Recipes : Administration and Operations - Restarting the BizTalk Host Instance(s)
- BizTalk 2010 Recipes : Administration and Operations - Tracking Messages
- BizTalk 2010 Recipes : Administration and Operations - Debugging Orchestrations
Top 10
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 2) - Wireframes,Legends
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 1) - Swimlanes
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Formatting and sizing lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Adding shapes to lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Sizing containers
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 3) - The Other Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 2) - The Data Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 1) - The Format Properties of a Control
- Microsoft Access 2010 : Form Properties and Why Should You Use Them - Working with the Properties Window
- Microsoft Visio 2013 : Using the Organization Chart Wizard with new data
Windows Vista
Windows 7
Windows Azure
Windows Server