Chapter 12: Configuring SharePoint 2010 for High Availability Backups

What’s In This Chapter?

• Methods for backing up content and configuration
• Restoring the information you’ve backed up
• Keeping SharePoint 2010 online in the face of adversity

It’s terrifying to think about, but someday, something terrible might happen to your SharePoint 2010 servers. Some mean users might delete content that they want back, right now, of course. A hard drive may decide to take an early retirement, or a stray volcano may take out your datacenter. While we all hate to think about it, these things do happen. To fend off that diabolical Murphy, you have to put some plans into place. If you plan accordingly, you can keep your SharePoint 2010 farm safe from any bad luck that might come your way.

Attacks come in different forms and not all organizations need protection from all kinds of failures or problems. Determining which of the world’s evils you want to protect your servers from is the first step. In this chapter we cover the different options you have with SharePoint 2010 out of the box and what kinds of situations they will protect you against.

Determining Your Business Requirements

Business continuity management can be summarized as an organization’s processes and procedures to create and validate a logistical plan outlining how to recover and restore interrupted critical functions within a predetermined time following a disaster or disruption. The predetermined time by which the organization will recover and/or restore is guided by several objectives, including the following:

• Service-level agreements (SLAs) — The SLA is the cornerstone of keeping the businesses or end users happy. It is a contract, an agreement between the end users and the service provider. In this case that is whoever is in charge of the keeping the SharePoint 2010 farm up. The SLA usually defines acceptable levels of downtime, both planned and unplanned, and other metrics that are defined in the following bullets.
• Operational-level agreements (OLAs) — The OLA is similar to an SLA, but it is between support groups, not between a support group and the customer. In the SharePoint environment, the SharePoint support team as well as the SQL and Active Directory support team may have responsibilities outlined in a company’s OLA.
• Recovery point objectives (RPOs) — The RPO helps define the acceptable level of data loss. When this is defined in the SLA it helps keep everyone’s expectations the same. Usually the shorter the RPO, the more expensive the solution. Examples of RPOs are “Anything that existed at midnight when the backups ran” or “Never lose more than two hours’ worth of data.”
• Recovery time objectives (RTOs) — Your RTO is how long it will take to recover from a disaster. If the RTO is three hours, then the SharePoint 2010 farm should be back on line within three hours of the failure. It’s important to note that your RTO can be longer than your RPO. For instance, an example SLA may state the RPO is one hour, and the RTO is three hours. If a failure happens at 9:59 in the morning, all data that existed at 8:59 or earlier can be restored. However, since the RTO is three hours, that data may not be available until 1:00, as that’s three hours after 9:59. Sounds like a great excuse for an early lunch.

These objectives apply both within and across the boundaries of the two primary scenarios in which business continuity management applies: high availability and disaster recovery.

This chapter describes these two objectives and explains how the new capabilities offered by SharePoint 2010 can help you achieve them. Keep in mind that, as with many of the new features in SharePoint, the backup and recovery features are merely facilitating the technical implementation of a business plan. You, as the administrator of the farm, will often be the driving force in the creation or updating of this business plan, but remember that your role is to provide technical guidance as to what is capable in SharePoint 2010 and to implement what the business decides.

When planning business continuity management, you should adhere to a process that begins with analysis to clarify the various scenarios and threats, and assess their potential impact, that will guide your solution design. You should also realize that there is rarely a “one size fits all” approach to this process. Different types of data require different recovery plans. Usually it is the most stringently controlled data in your organization that ends up making the hard decisions (and often the most costly decisions) for the rest of the organization, for instance, if a second failover data center is required because the data is just too valuable to the business.

The next stage is the one everyone hates, the documentation stage. Here is where you plan, document, and prepare your solution design, identifying the most cost-effective solution that meets the main requirements from the impact analysis stage. The solution design is based primarily on the objectives or requirements to which you are required to adhere as set forth by any SLAs, RPOs, or RTOs.

The next step in the process is the implementation stage, where you carry out the results of your business continuity management planning. At this point you should be prepared to test your solution and gain organizational acceptance as the next stage. Testing and acceptance is critical in order to validate that the solution satisfies the organization’s recovery requirements. Commonly, in this stage of planning you may discover that the solution fails to meet expectations, perhaps as a result of insufficient recovery requirements or inaccurate recovery requirements. Other common failures at this stage in planning result from design flaws and/or implementation errors. Testing and finally acceptance is an important stage. It’s what all this work has been moving us toward. All the planning and documentation is no good if the customer won’t sign off on it.

Upon successful completion of the testing and acceptance stage, you can finally begin the last stage of the business continuity management process, which is maintenance. The maintenance stage includes preparation, validation, and handoff of all corresponding documentation, testing, and verification of the solution, including testing and verification of the processes and procedures required to properly execute the solution.

Because each organization has unique requirements and objectives, there is no definitive manual or set of guidelines that can ensure you find the most effective solution. Therefore, you need a thorough understanding of not only what capabilities are provided by the service you are protecting, but also what aspects of that service are critical to your operations. Remember that this is not a one-time activity, as business rules and processes can change within an organization, and adding or removing sets of data can drastically change your company’s data availability requirements.

In this chapter, at a high level, we break down the three most common areas of planning associated with SharePoint 2010: content recovery, disaster recovery, and high availability. After ensuring that your business continuity management plan includes these areas, you can take advantage of the features and capabilities of SharePoint 2010 to meet your defined objectives.

Content Recovery

Content recovery is the most frequently leveraged aspect of data restoration with SharePoint 2010. Depending on both the scope and nature of recovery, several options are available for recovering data lost through deletion or corruption, including the following:

• Versioning
• Recycle Bin
• SharePoint Administration Tool
• Windows PowerShell
• Central Administration

These rich capabilities used both independently and in conjunction provide a framework for your disaster recovery processes and procedures. In addition to these new and improved capabilities, SharePoint 2010 also supports the use of SQL Server snapshots as part of its content recovery scenarios.

About SQL Server Snapshots

SQL Server snapshots are a SQL Server Enterprise and Developer Edition feature that enables you to specify a point in time from which you wish to preserve the contents of a database. Snapshots do not actually make a copy of the data, but instead create a new database that is prepared to receive content from the source database as the content is replaced, changed, or overwritten. When you restore the snapshot to the live site, those previous values are reapplied to the live database, which brings the database back to the state it was in at the point in time when the snapshot was taken.

It is important to understand that adding more SQL Server snapshots for a database slows the performance of that database. This is because each time a write operation takes place on the source database, the previous value has to be registered on each snapshot.

Content Storage Overview

Understanding how content is stored and organized in SharePoint 2010 is important for understanding the technologies used to protect it. In most scenarios, binary large objects, or BLOBs, comprise the deployment. These are the individual files commonly introduced by end users, such as PowerPoint presentations, Word documents, and so on. The binary large objects are stored in data tables within one or more content databases. In SharePoint 2010, content databases are the smallest unit of content representation on the file system and are hosted by individual web applications. It might not be obvious, but it is worth noting that if you have good backups of your content databases, you can always recover individual documents. You may have to jump through some hoops, but the content database contains all of the content for the site collections it contains. Take care of the databases; they may get you out of a jam some time.

The binary large objects are assigned to the specific document library or folder to which they were placed within a site hosted within a site collection, which is the principal point of initial interaction that end users have with SharePoint. A site collection is a set of sites that have the same owner and share administrative settings. It contains a top-level site and can contain one or more subsites. A site is the primary means of organizing related content in SharePoint 2010 and is host to document libraries and folders.

Document libraries are a location in a site containing files of one or more large binary objects or content types. Document libraries are designed to manage and store related documents, and to enable users to create new documents of the appropriate types. A folder is a named subdivision of the content in a document library, similar to the concept of folders in a file system. The primary purpose of folders is to organize content to match the expected functionality of the library. Figure 12-1 shows the farm hierarchy.

The Recycle Bin

The Recycle Bin, initially introduced in Windows SharePoint Services 3.0, provides self-service recovery of simple content — for example, lists and list items — to users of SharePoint 2010. The Recycle Bin is enabled by default and is configured on a per-web-application basis.

The Recycle Bin in SharePoint 2010 is unchanged from Windows SharePoint Services 3.0 and supports two Recycle Bin stages:

• Stage 1 — The first-stage Recycle Bin is located at the site level and is available to users with Contribute, Design, or Full Control permissions. When a user deletes an item from a site, it is sent to the first-stage Recycle Bin, where it can be recovered by that user. Items located in this stage affect the overall site quota and are retained until the specified time period has been reached as configured by the administrator in SharePoint 2010 Central Administration (the default setting is 30 days).
• Stage 2 — The second-stage Recycle Bin is located at the site collection level and is organized in two distinct views: the first-stage Recycle Bin just described and the second-stage Recycle Bin described here. Items deleted from the first-stage Recycle Bin are submitted to the second-stage Recycle Bin, where they can be recovered by the site collection administrator.

Items are retained in the second-stage Recycle Bin until the specified time period has been reached, similar to the first-stage Recycle Bin (the default setting is 30 days), or until the second-stage Recycle Bin has reached its allocated size limit, established by the administrator in SharePoint 2010 Central Administration, at which time the oldest items are permanently deleted. The time limit for the Recycle Bins reflects the total time after the item was initially deleted, not the time spent in either Recycle Bin stage.

When a second-stage Recycle Bin is enabled for a web application, the amount of disk space available to the second-stage Recycle Bin is defined as a percentage of the quota allotted to each individual site collection. Items stored in the second-stage Recycle Bin do not count toward the site quota; however, the size that is specified for the second-stage Recycle Bin increases the total size of the site and the content database that hosts it. If no site quota has been set, there is no limit on the size of the second-stage Recycle Bin.

Figure 12-2 provides an overview of two stages of the Recycle Bin and points of interaction.

Keep in mind that the total life of a document in your SharePoint farm equals the amount of time the document is live in a site AND the amount of time it spends in the Recycle Bin. This time can have a significant impact on your organization’s Business Records Retention Policy. Make sure that the team that manages Business Records policies for your organization is aware of and has a say in the Recycle Bin’s policies.

Configuring the Recycle Bin

The Recycle Bin is configured at the web application level by the server farm administrator. Each web application can have its own settings depending on the business processes and continuity requirements necessary to support the content hosted within that web application. To configure the Recycle Bin, use the following steps:

Figure 12-3 shows the Recycle Bin settings for a web application. The default retention settings have been left for the first stage, 30 days. In this example, the second stage has been turned off. This means that if a user empties the first stage, the document cannot be recovered through the Recycle Bin. Regardless of whether the second stage is turned on or not, 31 days after a document has been deleted it will no longer be able to be recovered through the Recycle Bin. Another caveat to keep in mind is that disabling the Recycle Bin entirely will immediately flush it. This means if you disable it and immediately regret doing so, there is good news and bad news. The bad news is that all of the documents that were in the Recycle Bin are gone. The good news is that your content databases have a lot of good white space in them. There’s a silver lining to almost anything if you look hard enough.

Keep in mind that while the first stage of the Recycle Bin counts against your site collection quota, the second stage does not. For example, if you specify a default Quota Template of 1GB per site collection on a web application, allotting a 50 percent quota for the second-stage Recycle Bin allocates 500 MB for the second-stage Recycle Bin and up to 1.5GB per site collection on the web application. This is important when sizing your content databases or trying to answer the age old question; “Why is my database so big!?” You can allocate up to 100 percent for the second-stage Recycle Bin quota.

Versioning

Versioning can be loosely compared to the Recycle Bin in that it provides self-service recovery of content for users — for example, if data loss occurs as the result of overwriting a document. Through versioning, SharePoint 2010 users can keep multiple versions of the same document in a document library; and in the event of an undesired change, such as an overwritten document or corruption, users can easily restore the previous version.

Versioning is configured by the site collection administrator on a per-site basis and is not enabled by default.

Versioning accepts the following configurations:

• No Versioning — The No versioning setting means prior versions of documents and their subsequent history, including comments, are not recoverable. No versioning is the default setting.
• Create Major Versions — This setting means that each iteration of a document becomes a full version of the document, using sequentially numbered versions (e.g., 1.0, 2.0, 3.0, etc). Users with permissions to the document library may view each updated version of a document. Note that this setting does not differentiate between draft versions and published versions.
• Create Major and Minor Versions — This setting means that documents can exist in one of two possible states, as denoted by their extension: Versions with a .0 extension represent a major version, whereas versions with a .1 through .9 extension represent a minor version of a document. This versioning setting provides the greatest degree of security granularity because in most scenarios, only users who can edit major versions can edit the minor versions associated with that item, whereas read-only users can only view the major versions.

Site collection administrators should manage versioning proactively due to the manner in which versions are maintained. Versions of files and documents are not represented as the differential between two or more documents, but as complete, new copies of those documents. For example, if a user opens a document and makes a minor grammatical modification and saves the document as a new version, it becomes a completely new document, with those changes and the previous version intact. You should proactively manage versioning by educating site collection administrators, establishing quotas on site collections in a web application, and monitoring storage utilization as needed. Figure 12-4 shows an example version history. Lack of attention to proper versioning implementation is one of the more common causes of Content Database growth due to overuse of versions, as well as causing restores of files from backups because of lack of use of versions.

Enabling and Configuring Versioning

To enable and configure versioning for libraries, follow these steps:

To enable and configure versioning for a list, follow these steps:

Exporting and Importing Sites, Lists, and Libraries

New in SharePoint 2010 is the capability to export lists, libraries, and sites through the SharePoint 2010 Central Administration user interface, in addition to new Windows PowerShell support and continued support of the SharePoint Administration Tool (STSADM). These new capabilities are based on PRIME (Publishing, Rollback, Import, Migration, Export), which was introduced in Windows SharePoint Services 3.0. PRIME is a feature for content migration from a source site to a destination site. The Content Migration application programming interface (API) provides a simple and flexible solution for migrating content between SharePoint sites. You can export the content related to a SharePoint Web site, along with any dependencies (e.g., security, roles, versioning, workflow, and other metadata), into a single or multiple XML-formatted files called content migration packages. After import to the destination site, the packaged data is extracted and interpreted. Content migration packages are portable, meaning you can also save the packages to a file server before migrating to a different server.

While the intention of the content deployment was to, well, deploy content, it can also be used as a rudimentary means of content recovery. It can be used to export lists or libraries that are of high importance (like the ones where you have your résumé, for instance) giving you a quick way to protect that data. It has another important function — getting that data back into SharePoint. Backups are great, but knowing how to get your backed up information back into production could be the difference between an “Atta boy!” and an “Outta here!” If you only need a specific list or library to be restored, you can use content deployment to shuffle content from a database restored to a different environment back to production. You could also use content deployment to move content between test and production environments.

Exporting Sites, Lists, and Libraries with Windows PowerShell

New Windows PowerShell cmdlets provide greater granularity than their SharePoint Administration Tool command-line operation equivalents. With the new Windows PowerShell Export-SPWeb cmdlet, you can export not only a site like you could in SharePoint 2007, but also lists and libraries, which can be restored into the same or other server farms.

To export (back up) a site, list or library with Windows PowerShell, enter the following cmdlet in the Microsoft SharePoint 2010 Management Shell:

The following options are available to the backup operation using Windows PowerShell:

• To forcibly perform the export operation, use the Force parameter. You can use this to overwrite an existing file.
• To stop the export process in the event of a warning or error, use the HaltOnError or HaltOnWarning switches.
• To preserve time stamps, security information, and user data, you must use the IncludeUserSecurity switch.
• To specify which type of file and list item version history should be included in the export, use the IncludeVersions parameter. A description of the values follows:
  • Last major version for files and list items (default)
  • The current version, either the last major or the last minor
  • Last major and last minor versions for files and list items
  • All versions for files and list items
• To disable file compression in the export package, use the NoFileCompression switch, which is recommended for better performance. Enabling compression can speed up the export process by approximately 30 percent. When content is exported it’s written to the file system. When compression is enabled, that content is then compressed. You can save time by not having that final compression step run. If your export jobs are failing you may also be able to fix them by disabling the file compression. Some timeouts and other errors may be introduced by the compression process.
• To suppress the generation of an export log file, use the NoLogFile switch; otherwise, an export log is generated in the same location as the export package.
• To specify whether or not the backup should be executed against a snapshot, use the UseSqlSnapshot switch.

To export a site, provide Export-SPWeb with the URL to the web. To export a list or library, provide Export-SPWeb with the URL to the specific list or library. Below are two examples. The first exports an entire site; the second only backs up a library called Docs in that web.

Exporting Sites, Lists, and Libraries with STSADM

If you are reading this book, we can probably tell a few things about you. You probably sat at the front of the class and ruined the curve for all your classmates. You’re an exceptional SharePoint administrator, are better looking than your peers, and can probably dance like Fred Astaire. Either that or you are one of the authors’ mothers. Regardless, if you have taken anything from this book hopefully you have picked up that Windows PowerShell should be your command line weapon of choice for SharePoint 2010. But if you have slower, less enlightened counterparts you may need to know how to do all this fancy exporting and importing with STSADM. This section covers that too.

To export (back up) a site with the SharePoint Administration Tool, open up a command prompt and change directories to the Bin directory of the SharePoint Root (c:program filescommon filesmicrosoft sharedweb server extensions14in). You can use the export operation to export lists or webs. Here is the usage.

• To overwrite an existing content migration package of the same name and location, use the -overwrite parameter.
• To stop the export process in the event of a warning or error, use the haltonfatalerror or haltonwarning switches.
• To preserve time stamps, security information, and user data, you must use the includeusersecurity switch.
• To specify which type of file and list item version history should be included in the export, use the versions parameter. A description of the values follows:
  • Last major version for files and list items (default)
  • The current version, either the last major or the last minor
  • Last major and last minor versions for files and list items
  • All versions for files and list items
• To disable file compression in the export package, use the nofilecompression switch. This provides the same performance improvement with STSADM as it does with PowerShell.
• To suppress the generation of an export log file, use the nologfile switch; otherwise, an export log is generated in the same location as the export package.
• To specify whether or not the backup should be executed against a snapshot, use the usesqlsnapshot switch.

Exporting Sites and Lists with Central Administration

While PowerShell and STSADM do very impressive jobs of exporting, sometimes you just need a comfortable, mouse-friendly way to do your tasks. Get your mousing finger stretched and ready to go, because you can also export sites and lists within Central Administration.

To export (back up) a site or list through Central Administration:

Importing Sites, Lists, and Libraries with Windows PowerShell

To import (restore) a site, list, or library with Windows PowerShell, enter the following command in the Microsoft SharePoint 2010 Management Shell:

The following options are available to the import operation using Windows PowerShell:

• To stop the import process in the event of a warning or error, use the HaltOnWarning or HaltOnError switches.
• To preserve time stamps, security information, and user data, you must use the IncludeUserSecurity switch.
• To suppress the generation of an import log file, use the NoLogFile switch; otherwise, an import log is generated in the same location as the import package.
• To specify how to resolve situations in which a file to be imported to a site already exists in that site, including options to add a new version, overwrite the file, and delete all versions prior to insert, or to ignore the file as it exists, use the UpdateVersions switch. A description of the values follows:
  • Add new versions to the current file (default)
  • Overwrite the file and all of its versions (delete then insert)
  • Ignore the file if it exists on the destination
• If you want to only describe the effect of the command, rather than actually perform the operation, use the WhatIf switch.

Importing Sites, Lists, and Libraries with STSADM

If you are forced to, or if you’ve lost a dare, you can also use STSADM to import sites, lists, or libraries:

The following options are available to the import operation in STSADM:

• To stop the import process in the event of a warning or error, use the haltonwarning or haltonerror switches.
• To preserve time stamps, security information, and user data, you must use the includeusersecurity switch.
• To specify which type of file and list item version history should be included in the import, use the updateversions parameter. A description of the values follows:
  • Add the imported files to the current file, which is the default.
  • Delete the current file and all its versions and replace them with the imported files.
  • Skip the file if it exists in the destination.

• To disable file compression in the import package, use the nofilecompression switch.
• To suppress the generation of an import log file, use the nologfile switch; otherwise, an import log is generated in the same location as the import package.
• To suppress the output of import progress information to the display window, use the quiet switch. This parameter is recommended for better performance, as the buffer of the display window is small compared to writing a file.

Backing Up and Restoring Site Collections

Sites and site collection backup and restore in SharePoint 2010 can be accomplished through the SharePoint Administration Tool (STSADM) in addition to Windows PowerShell and Central Administration. Site and site collection backup and restore is commonly used either to recover content that has been permanently deleted from the second-stage Recycle Bin or to recover corrupted data or pages.

While creating site collection backups may seem like a compelling solution to achieve continuity, it should only be used in conjunction with an existing overall solution, and limited to use on only the most critical site collections of 15GB or smaller, as it is resource-intensive from a time, storage, and processing perspective.

Backing Up and Restoring Site Collections Using Windows PowerShell

Not only can you use Windows PowerShell for exporting and importing sites, you can also use it to back up and restore entire site collections. This section will cover that.

The cmdlet Backup-SPSite will make a single file backup of a site collection. In contrast to the exports we covered previously, these backups are full fidelity. They back up non-content objects like workflow and alerts. Like their content deployment counterparts, site collection backups are portable and can be shuffled around on a farm, or restored to a different farm entirely as long as the destination farm is at the same build or later than the source farm.

You can use Get-Help in PowerShell to get the full usage of Get-SPSite, but the basic usage is shown here:

• To overwrite a previously used backup file, use the Force parameter.
• You can use the NoSiteLock switch to keep the read-only lock from being set on the site collection while it is being backed up. However, using this switch allows users to change the site collection while it is being backed up, which can lead to possible data corruption during backup. Unfortunately, the time when you will discover this corruption is when you try to restore the site collection. It is not recommended to use NoSiteLock.
• If the database server is running an Enterprise Edition of Microsoft SQL Server, we recommend that you also use the UseSqlSnapshot switch for more consistent backups.

Some smaller server farms may optionally choose to use site collection backups as their overall business continuity management scenario. While this is not recommended to support disaster recovery due to the constraints associated with the backup of site collections, Windows PowerShell opens the door to new opportunities to develop a scripted solution that can be run on demand or scheduled as a task with Windows Task Scheduler.

An example of a solution that would iterate through and back up all site collections in a web application with Windows PowerShell could be implemented as follows:

Backing up your site collections isn’t very useful without being able to restore them. Windows PowerShell provides a cmdlet to do just that, Restore-SPSite. Like you may suspect, using the Get-Help cmdlet will show you all of your restore options, but the basic usage is shown here:

Restore-SPSite has many parameters to make your site collection restoring experience more pleasurable. You can use the -DatabaseName parameter to have SharePoint 2010 restore your site collection to a specific content database. If that database is not on your default SQL instance, use -DatabaseServer to direct SharePoint 2010 to the appropriate server. If you are restoring your site collection on top of an existing site collection, use the -Force parameter. If you are overwriting a site collection that is over 1GB, use the -GradualDelete option to reduce the likelihood of database locks as the site collection is deleted before it is overwritten.

While most site collections are URL-based, if you happen to be restoring host-named site collections, use the -HostHeader switch followed by the URL of the web application that is hosting your site collection.

Backing Up and Restoring Site Collections Using STSADM

There are two operations to use with STSADM to back up or restore site collections. They function very similarly to their newer Windows PowerShell counterparts.

The backup operation handles the backup responsibilities. Stsadm –help backup will give you the full usage, but here is the general usage:

As with Backup-SPSite, you have the option of using -overwrite to overwrite an existing backup file. You can also use -nositelock to prevent the site collection from being locked before it is backed up. Even -usesqlsnapshot is there, which you can use if you have the Enterprise SKU of SQL Server.

To restore a site collection with STSADM, enter the following command from the Microsoft SharePoint 2010 Management Shell:

• If you are restoring a host-named site collection, use the url parameter to specify the URL of the host-named site collection, and use the hostheaderwebapplicationurl parameter to specify the URL of the web application that will hold the host-named site collection.
• To overwrite an existing site collection, use the overwrite parameter.
• If the site collection that you are restoring is 1GB or larger, you can use the GradualDelete parameter for better performance during the restore process. When this parameter is used, the site collection that is overwritten is marked as deleted, which immediately prevents any additional access to its content. The data in the marked site collection is then deleted gradually over time by a timer job, rather than all at once, which reduces the impact on server performance.

Backing Up Site Collections Using Central Administration

New in SharePoint 2010 is the capability to perform a site collection backup directly from the SharePoint 2010 Central Administration user interface. This provides administrators with a way to perform routine backup and recovery tasks without needing to log onto a server to access one of the available command-line options; however, you cannot restore site collections through SharePoint 2010 Central Administration, and you must use one of the available command-line options discussed in this chapter.

Follow these steps to perform a backup from Central Administration:

If you receive any errors, you can review them in the Failure Message column of the Backup and Restore Job Status page.

Restoring Content with Unattached Content Database Data Recovery

In SharePoint 2007 restoring content from backups can be painful, and it seems like nothing ever goes right. Unless you want to overwrite your production data, you need a recovery farm to restore you database to. Then you need to extract the site or site collection from there before you can get it to your production server. Hopefully that recovery farm hasn’t been used in a while, so it probably needs some Windows updates before it’s happy. And if you’ve upgraded SharePoint on your production server with a cumulative update or service pack, your databases won’t attach until you do the same to your test environment. The whole process has so many moving parts it’s almost guaranteed that something will go wrong. Wouldn’t it be great if you could recover content without that second farm, and without overwriting production?

Unattached Content Database Data Recovery is a feature available to the new Granular Backup capabilities in SharePoint 2010 that does just that. Unattached Content Database Data Recovery enables you to back up lists, libraries, sites, and site collections, and browse the content of a database or database snapshot attached to a SQL Server instance, but not associated with a web application. Unattached Content Database Data Recovery enables administrators to work with a content database even when a duplicate of that database is attached to its respective web application. In Office SharePoint Server 2007, these capabilities required a separate recovery server farm or web application to avoid URL conflicts that would arise if the database were attached to a production server farm.

To use Unattached Content Database Data Recovery, first attach a recent backup to either the server farm default or a separate SQL Server instance. Once the content database has been attached successfully to the SQL Server instance, refer to the following steps:

This section provided the basic information required to understand the methods to both successfully protect and recover content from corruption, accidental deletion, or other loss scenarios. If your organization has service-level agreements targeted specifically at content recovery scenarios, you should evaluate all of the options presented here; and through planning and practice, combine these strategies with your overall business continuity requirements, while keeping in mind that although content comprises the majority of information accessed in SharePoint, its protection alone does not provide an adequate disaster-recovery or high-availability solution. Testing is imperative to help you make an informed decision about which solution or combination of solutions should be implemented to protect your content.

Disaster Recovery

Disaster recovery is the process and procedures related to preparing for recovery or continuation of technology infrastructure in the event that the primary site where that infrastructure is provided is lost due to natural disaster or some other event, making that site unavailable to continue serving users. Disaster recovery processes and procedures are commonly guided by two principles:

• Recovery point objective (RPO) — RPO is a critical value when planning a business continuity solution and is impacted by factors such as restore duration from backup and replication performance.
• Recovery time objective (RTO) — RTO is important as it dictates the total amount of time required to bring the service back online. It should be mapped to any operating-level agreements established with ancillary technologies, such as Directory Services or network infrastructure, as these services will commonly need to be available before you can offer your service to users.

It is equally important to understand that any reduction in RPO and RTO objectives will often increase the costs associated with the technologies elected to provide the business continuity management solution. This section describes several solutions available in SharePoint 2010 to facilitate a business continuity management solution.

The first step when planning the business continuity management solution is understanding what needs to be recovered in the event of a disaster, keeping in mind that in most cases content comprises a deployment (see also “Content Recovery” in this chapter). Content is the foundation for most service applications and should be prioritized in most solutions — for example, prioritizing the recovery of Search over content provides no value, as Search requires content to crawl to effectively provide value to users.

An additional consideration that applies in continuity management solutions is the protection of customizations deployed to a server farm environment. Some of these customizations can be protected adequately using the functionality provided by SharePoint 2010, but in some cases you will need to catalog, manually protect, or replicate these customizations in the destination server farm environment.

Backup and Restore for Disaster Recovery

SharePoint 2010 provides new and improved tools and capabilities to protect its content, configuration, and customizations, including extending options that were previously available only through the command line to the user interface, new features to provide greater granularity, and overall improvements in performance and resiliency. In SharePoint 2010, backup and restore capabilities are distributed across two primary areas of functionality:

• Farm backup and restore
• Granular backup

Farm backup and restore, also known as catastrophic backup and restore, provides solutions designed to enable you to backup and restore components of a server farm or the entire server farm environment, in addition to providing entry points that enable you to configure backup settings and access backup and restore history.

In addition to an entire server farm, backup enables you to protect the following components:

• Configuration databases
• Web applications, to include settings and content databases
• Service applications, to include settings and databases where present
• Services such as InfoPath Forms, State, Application Registry, and User Code Solution services

Granular Backup provides solutions designed to enable you to back up site collections, export sites and lists, recover data from unattached content databases, and access backup history.

In addition to the features provided through SharePoint 2010 Central Administration, SharePoint 2010 continues to provide backup and restore capabilities through both the SharePoint Administration Tool and new capabilities through Windows PowerShell.

Backing Up and Restoring Content Databases

We have already demonstrated that there are many tools in SharePoint 2010 that you can use to accomplish a task. You have the option of using Windows PowerShell, the Central Administration website, or even STSADM, if you must. Backing up content databases is no different. In this section we cover the different ways you can back up your content databases in SharePoint 2010.

Backing Up and Restoring Content Databases Using Central Administration

SharePoint 2010 provides improved backup and restore functionality out of the box, including greater granularity, improved monitoring and reporting, and greater scale and efficiency. With SharePoint 2010 backup and restore, you can back up one or more content databases in either full or differential mode.

To back up a content database using SharePoint 2010 Backup and Restore:

Figure 12-13 shows how the final screen will look before the backup is run.

Remember that you can view the general status of all backup jobs at the top of the Backup and Restore Job Status page in the Readiness section, and see the status for the current backup job in the lower part of the page in the Backup section.

To restore a content database using SharePoint 2010 Backup and Restore:

Two options are available, New and Same Configuration:

Backing Up and Restoring Content Databases Using Windows PowerShell

New Windows PowerShell support enables you to perform common administrative tasks, apply varying levels of backup, and restore granularity.

To back up a content database by using Windows PowerShell, enter the following command in the Microsoft SharePoint 2010 Management Shell:

To restore a content database by using Windows PowerShell, use the following command:

Backing Up and Restoring Content Databases Using Microsoft SQL Server

SQL Server provides the greatest scale and selection of backup options available to SharePoint 2010 content databases, including Full, Differential, and Incremental.

Depending on your specific recovery point and recovery time objectives, you may often be required to combine these options to provide the broadest overall coverage and facilitate rapid recovery of content. For example, many enterprises are expected to provide a 21-day, disk-based backup regimen; in this scenario, a combination of three full and 18 differential backups are implemented to meet the requirements and minimize the storage footprint.

SQL Server provides a number of options and levels of granularity for performing database backups. Full backup is the simplest form of backup with SQL Server; it provides database administrators with additional options such as the capability to perform single data file or filegroup backups. SharePoint 2010 does not support partitioning schemes, which are required to fully support multiple filegroups, so these options are not discussed here; however, while SharePoint 2010 supports multiple data files, all data files should be backed up and restored as a single unit when working with SharePoint 2010 content databases.

A full database backup provides a complete copy of the content database and provides a “point in time” snapshot to which the database can be restored; however, it does not include the time during which the backup was running. This is important to understand in order to meet specific recovery point objectives, due to the increased backup duration that occurs as the size of the database increases.

Full database backups are the easiest to use and contain all of the data in the content database. When working with a small content database of 50GB or less, the usual best practice is to rely on just full database backups. However, as noted earlier, as the size of a database increases, so does the duration of the backup; and therefore it takes more time to finish and requires more storage space. In these cases, the best practice is to supplement full backups with differential backups, in order to ensure efficiency and performance in both backup and restore.

To perform a full database backup of an individual SharePoint 2010 content database:

To restore a content database backed up through SQL Server:

Database Snapshots

SharePoint 2010 also introduces support for database snapshots (to learn more about snapshots, see “SQL Server Snapshots,” earlier in this chapter).

Snapshots are a little tough to set up, and definitely not for the faint of heart. In this section you take a look at how to set them up, then walk through the steps. Figure 12-18 shows the before and after.

The query in the query window is the command that was used to create the snapshot. There is no way in the UI to do it. The first line creates the snapshot as a database named WSS_Content_Snap. The arrow points to where you will find it in the interface after it has been created. The next line, Name=WSS_Content, refers to the Logical name of the database file for the database you are making the snapshot of. In most cases it will be the same as the database name itself, as is the case here. The next line specifies the name of the file that will contain the snapshot, WSS_Content_Snap.ss. The final line specifies which database this will be a snapshot of. That’s all there is to it. Once you get the query written, press the Execute button in the menu bar, sit back, and let the magic happen.

Once you have the snapshot created you can treat it like any read-only database. You can mount it in SharePoint and render out the content, or you can use it to do an unattached database restore. When you’re finished with the snapshot you can delete it the same way you would a regular database.

Backing Up and Restoring Service Applications

The new service application architecture not only provides new and compelling scenarios previously not possible under Office SharePoint Server 2007’s SSP design, but also introduces new services, some with databases associated, that must be considered when planning your overall backup and restore strategies. Fortunately, SharePoint 2010’s native backup and restore capabilities enable both backup and restore of individual service applications, with their respective content where applicable, and backup and restore of only their unique configuration settings.

Backing Up and Restoring Service Applications with Windows PowerShell

To back up a service application using Windows PowerShell, enter the following command in the Microsoft SharePoint 2010 Management Shell:

To perform a restore, use this command:

Backing Up and Restoring Service Applications with Central Administration

Follow these steps to back up a service application using Central Administration:

Of course backups are only part of the solution. Let’s walk through restoring a service application from Central Adminstration.

Now that you’ve given SharePoint its marching orders it will fire off a Timer Job and start restoring your service application.

Backing Up and Restoring a Farm

A farm backup is useful when you would like to recover all elements of a server farm back to the same overall topology in addition to preserving the original farm’s content and configuration. As a result, a full backup should only be considered in scenarios with extended RPO and RTO objectives due to the lengthy downtime required to effectively bring the service online on standby hardware. Most large organizations with complex topologies will elect to leverage more granular protection options that provide a warm standby solution, such as SQL Server Log Shipping, rather than implement a solution based on backup and restore.

Some of the limitations when performing a farm-level backup and restore include the following:

• The farm where the restore will be performed must have the same topology as the original source farm.
• You cannot downgrade or upgrade topologies with farm backup and restore; for example, a multi-server farm backup cannot be restored to a single-server farm, and vice versa.
• Farm backups cannot be restored to other product versions, such as SharePoint Server 2007.
• A recovery farm should not be considered to be adequate protection unless specific RTO and RPO objectives allow for such a scenario. Warm standby solutions are always preferable in disaster-recovery scenarios.
• In multiple-server topologies, the backup directory must be a common share that all servers in the topology can write to and read from, and all accounts in the farm should have adequate access to that common share.

Backing Up and Restoring a Farm with Windows PowerShell

To perform a farm backup using Windows PowerShell, enter the following command in the Microsoft SharePoint 2010 Management Shell:

If an error occurs during the backup, you can view the spbackup.log file created in the backup directory. As a best practice, you should always use the Verbose switch to monitor the operation and its status.

For farms that have not been previously backed up, you must use the -Full switch.

To perform a farm restore, enter the following command:

As with a farm backup, if an error occurs during the restore, you can view the spbackup.log file created in the backup directory. As a best practice, you should always use the Verbose switch to monitor the operation and its status.

Backing Up and Restoring a Farm with Central Administration

Backing up your SharePoint farm in SharePoint 2010 is much the same as it was in SharePoint 2007, but in the interest of being thorough, let’s go ahead and walk through the steps:

SharePoint will now kick off a timer job to back up your farm. You can view its progress on the backup job status page that shows up after the backup starts.

Backing Up and Restoring Configuration Settings

In Office SharePoint Server 2007, a limitation of the Backup/Restore feature was that farmwide configuration settings and information could not be backed up and restored to another server farm. In SharePoint 2010, you can back up and restore only the configuration settings that apply to a specific component. This capability to seamlessly back up and restore configuration settings provides robust support for scenarios such as hardware migrations, replicating settings to preproduction or development environments, or facilitating the rapid build and deployment of production environments that share common settings and topologies.

When performing a complete server farm backup in SharePoint 2010, the configuration database is included; however, it cannot be restored. There are several challenges associated with restoring the configuration database — most notably, the configuration database stores server names and topology information. Therefore, when the restore operation is taking place on a new farm, there is uncertainty about how that information should be treated. The new farm will likely have different machine names and possibly a new topology.

The new “configuration only” backup capabilities mitigate these constraints, enabling you to restore the configuration database settings that are not affected by these unique properties. The configuration only backup extracts and backs up configuration settings from any configuration database, including the current farm’s configuration database, the configuration database on another farm, or a configuration database that is not associated with any farm.

Backing Up and Restoring Configuration Settings with Windows PowerShell

To back up configuration settings using Windows PowerShell, enter the following cmdlet in the Microsoft SharePoint 2010 Management Shell:

To restore configuration settings with Windows PowerShell, enter the following cmdlet:

Backing Up and Restoring Configuration Settings with Central Administration

Doing a Configuration only backup in Central Administration is nearly identical to the farm backup shown earlier in this chapter. The steps are the same, but to do a configuration only backup, select Back up only configuration settings in step 4, instead of leaving the Data to back up at the default value. See Figure 12-19.

This backup will go very quickly: don’t blink or you’ll miss it.

The steps to perform a restore of configuration settings nearly mirror the earlier steps for doing a farm recovery with content. Select the Restore from a backup option in Central Administration and choose the configuration only backup you just did. You can choose to restore the entire farm configuration, or the configuration of certain components. Once you’ve chosen which configuration you want to restore, click Next. You’re greeted with a familiar page asking if you want this restored as a new configuration or the same one. If you are restoring a farm with new computer names, web applications, or SQL servers, click New configuration, as in Figure 12-20, and click Start Restore.

Customizations

Just because you have all of your content doesn’t mean you have everything covered. A lot of work goes into making that pretty SharePoint page, and you have to make sure you get every last bit of supporting material. Customizations are a big part of that.

Customizations can be the most challenging piece of any recovery planning due to the dynamic nature of customizations in terms of life cycle, purpose, and location on a server. For example, with SharePoint, customizations commonly include the following:

• Assemblies deployed to the global assembly cache (GAC)
• Feature or site definition XML manifests
• Master pages, page layouts, and cascading style sheets (these objects are typically content database contained)
• Web Parts, site or list definitions, custom columns, new content types, custom fields, custom actions, etc.
• Coded workflow
• iFilters and corresponding Registry modifications
• Third-party solutions
• Resource files (.resx)

The most appropriate and seamless method of containing and managing the recovery of customizations is to leverage the capabilities provided by the development environment, such as Visual Studio Team Foundation, by which the developer or developers can maintain both the deployed build and version tree in a centrally managed system, in addition to any corresponding documentation. Using the native development environment, the development team can align its high-availability and disaster-recovery solutions with those tied to the SharePoint deployment, while mitigating the administrator’s need to document and protect customizations separately.

Customizations that fall outside of the scope of those that are self-contained within the development environment include the SharePoint 14 “hive” (%COMMONPROGRAMFILES%Microsoft SharedWeb Server Extensions14), inetpub (%WINDIR%Assembly), and the global assembly cache. These customizations should be protected through file system backup and documented accordingly, to include changes made to Web.Config manually outside of the object model.

IIS 7

Like customizations, there are a lot of SharePoint nuggets hidden in IIS, so it should be part of your backup plan too. The process of backing up and restoring a configuration has been made more convenient to administrators by adding command-line support through AppCmd.exe. You can use AppCmd.exe with the add backup, restore backup, and delete backup parameters to perform a full backup of the windowssystem32inetsrvconfig directory and subdirectories.

In addition to simplifying the process by which administrators can back up and restore IIS 7 configuration, IIS also includes a new feature that captures configuration history. With this new capability, IIS will automatically create history snapshots of ApplicationHost.config when a change is detected, which enables you to easily restore to a prior version. By default, IIS checks for a new version every 120 seconds and retains 10 prior versions of the file, which are stored in the %systemdrive%inetpubhistory folder. You can change any of these settings by editing the <system.applicationHost/configHistory> section in ApplicationHost.config.

Warm Standby Solutions

Cold standby solutions such as backup and restore account for only a small percentage of a business continuity management plan. In addition to those solutions, you should evaluate the available technologies and capabilities of warm standby solutions that enable recovery of a SharePoint 2010 deployment with minimal disruption in the event of a disaster or major failure in the primary site. Warm standby solutions provide a second copy of the data that can be leveraged in a secondary data center if necessary.

High Availability

High availability is the implementation of a system to ensure a certain degree of operational continuity during a given measurement period, typically defined by service-level agreements (SLAs), and can encompass the entirety of a solution or just a portion thereof.

Service-level agreements are a form of contractual agreement whereby the level of service is formally defined, and they can include both performance and delivery time. For example, a guarantee of 99.9% system availability may be a facet of a service-level agreement. Service-level agreements are commonly mapped to operational-level agreements, which define internal support relationships, such as those defined between two services — for example, infrastructure and the consuming application.

SharePoint 2010 offers new high-availability scenarios that provide capabilities to mitigate downtime, promote redundancy, increase resiliency, and drive a highly scalable architecture. Among these improvements are a new service application architecture, native support for SQL Server database mirroring, and improvements to the methods by which costly operations such as large list querying and site collection deletion are handled.

Load Balancing

Load balancing can be a combination of software- and hardware-based solutions designed to distribute workload evenly across two or more computers, such as two front-end web, query, or indexing servers in a SharePoint 2010 topology. The decision to leverage a software or hardware load-balanced solution is determined by the capabilities and scale you require to meet your objectives. These can include compliance requirements, geographic needs, and overall scale and performance in addition to manageability.

SQL Server Database Mirroring

SQL Server database mirroring is becoming a popular option not only to provide a highly resilient and performance-oriented data replication solution, but also to move toward commodity storage servers and inexpensive direct-access storage (DAS). SQL Server database mirroring can serve as either a high-availability solution or a disaster-recovery solution, but it cannot be both. SQL Server database mirroring works by maintaining two copies of a single database on separate SQL Server instances.

In a database mirroring session, one database, the principal, serves the database to clients; while the other, the mirror, provides a hot or warm standby server. Whether a database is a hot standby or a warm standby is dictated by the operating mode of the mirroring session:

• Synchronous — In a synchronous database mirroring configuration, database mirroring provides a hot standby solution that provides rapid failover without data loss (committed transactions). This is accomplished because each transaction must be acknowledged by the mirror before it is hardened on the principal. While this method offers the highest resiliency, there is the potential to lose inflight transactions in some scenarios.
• Asynchronous — In asynchronous configurations (i.e., sessions are not synchronized), there is the potential to incur data loss; therefore, it is considered a warm standby solution. Asynchronous database mirroring is commonly configured to support and drive disaster-recovery solutions due to its efficiencies over latent links, such as a WAN.

When implementing database mirroring with SharePoint 2010 as a high-availability solution, it must be configured synchronously in the High-safety with automatic failover operating mode, which includes a witness server. The witness server provides automatic failover by periodically “polling” the principal server to determine whether it is up and functioning. The mirror server initiates automatic failover only when the mirror and the witness remain connected to each other after both have been disconnected from the principal server. This configuration enables a seamless client experience if a database is compromised and unable to serve clients.

Table 12-1 provides an overview of SQL Server database mirroring availability according to SQL Server edition.

Table 12-1: Database Mirroring Features by SQL Server Edition

 

Most databases in SharePoint 2010 can be configured using a standard Windows PowerShell noun and verb combination, although in some cases varying statements are required to successfully configure database mirroring. While Windows PowerShell is most frequently used to configure database mirroring, the SharePoint 2010 Central Administration user interface also provides support for configuring database mirroring — the exception being the configuration database, which must be configured through Windows PowerShell.

Note that unlike previous versions of SharePoint, SharePoint 2010 supports database mirroring without the implementation of connection aliases or middle-tier software to manage the failover. This is possible because SharePoint 2010 databases are built on the SQL Native Client (SNAC) that introduces support for the Failover_Partner keyword in the connection string.

Although database mirroring can be configured through SharePoint 2010, it simply enables the support for database mirroring — it does not configure mirroring at the database level, which must be completed through the SQL Server management tools or Transact-SQL prior to enabling a database with SharePoint. To learn more about database mirroring and how to configure it in SQL Server, see http://technet.microsoft.com/en-us/library/ms189852.aspx.

Configuring Database Mirroring for the Configuration Database

To configure database mirroring for the configuration database, enter the following command in the Microsoft SharePoint 2010 Management Shell:

Configure Database Mirroring for Content Databases

Database mirroring for a content database can be configured with either Windows PowerShell or Central Administration.

To use Windows PowerShell, enter the following command in the Microsoft SharePoint 2010 Management Shell:

To configure mirroring on a content database using Central Administration, follow these steps:

Configure Database Mirroring for Service Application Databases

Many of the new service applications in SharePoint 2010 provide a user interface entry point to configure the failover partner when using database mirroring; however, they differ in implementation.

To configure service applications for database mirroring using Windows PowerShell, enter the following command in the Microsoft SharePoint 2010 Management Shell:

Failover Clustering

While SQL Server database mirroring support has been included in SharePoint 2010, full support of failover clustering remains.

Failover clustering helps ensure that applications and services, such as SharePoint, are available when you need them. A failover cluster is a group of computers working together to increase the availability of applications and services, such as SQL Server. The clustered servers are commonly connected by physical cables and software. In the event that one of the cluster nodes fails, another node takes over; as a result, users experience a minimum of disruption in service.

The key difference between database mirroring and failover clustering is that database mirroring provides a second warm or hot standby of one or more databases, whereas failover clustering protection occurs at the server level.

To learn more about failover clustering, see http://technet.microsoft.com/en-us/library/ff182326(WS.10).aspx.

Read-Only Mode

SharePoint 2010 supports configuring its content databases in read-only mode. When databases are configured as read-only, SharePoint 2010 detects and seamlessly responds to the situation and disables any user interface options associated with write and edit scenarios. This enables users to continue working normally with SharePoint 2010 by allowing them to retrieve data and work with content until the environment is placed into a read/write mode. Read-only scenarios can be used in disaster-recovery solutions in the secondary environment or in a localized secondary environment during patching and upgrade. Read-only mode is configured through SQL Server management tools or Transact-SQL.

To configure a database as read-only:

Repeat the preceding steps for each database to be configured.

HTTP Request Monitoring and Throttling

SharePoint is popular, sometimes too popular for its own good. There are times when a SharePoint server can get more requests than it can handle in a timely fashion. In the dark ages, with SharePoint 2007, those requests would get dropped in a somewhat random fashion. While a user getting an error trying to get to your portal home is bad, getting that same error when hitting Submit on their vacation approval form is even worse. To help reduce the impact of an overburdened server, SharePoint 2010 introduces HTTP Request Monitoring and Throttling. Hallelujah! Vacations everywhere will be saved!

How does this all work? Every five seconds each server checks various aspects of its performance. It looks at metrics like memory available and ASP.NET requests queued, and compares them against acceptable thresholds. If the server is overworked and exceeds the defined thresholds three times in a row, the red lights start flashing and the server goes into throttled mode. Web applications that have HTTP throttling enabled get some new instructions. They will not accept any new requests. New requests will be met with a very friendly, but firm HTTP 503 error, server busy. The server will, however, accept connections from existing sessions. This should help free up server resources to let that vacation request form get submitted. No new timer jobs will be started on that server, and any running timer jobs will be paused, if they can be. The server continues to check itself every five seconds, and stays in the throttled state until all the metrics it checks fall back into acceptable ranges. All of this will be logged in the server’s System log in the Event Viewer.

HTTP Request Monitoring and Throttling can be enabled through both Central Administration and Windows PowerShell on a per web application basis.

To view and change the values associated with HTTP Request Monitoring and Throttling, use these Windows PowerShell cmdlets:

You can use Get-SPWebApplicationHttpThrottlingMonitor -identity http://www.contoso.com to return the HTTP Throttling values. To change the values, you can use Set-SPWebApplicationHttpThrottlingMonitor.

To configure HTTP Request Monitoring and Throttling from Central Administration, follow these steps:

List Throttling

List Throttling is a new feature in SharePoint 2010 that enables administrators to proactively protect server resources from the impact of large lists and their associated views. In order to provide a consistent server response, SharePoint 2010 provides several settings that can be used to restrict queries executed against large lists. To provide the greatest amount of flexibility, these settings are configured on a per web application basis.

To configure list throttling from Central Administration, follow these steps:

Gradual Site Delete

Gradual Site Delete is an improvement in the manner by which site collections are deleted in SharePoint 2010, provided through the new Gradual Site Delete Timer Job Definition.

In SharePoint 2007 a seemingly innocent operation of deleting a site collection could make site collections inexplicably unavailable. When a site collection was deleted in SharePoint 2007, a SQL stored procedure was run. It was given the ID of the site collection that had been given its walking papers. The SQL stored procedure searched through all the tables in the content database that held the site collection, and deleted all rows that were associated to that ID. While this seems like a good idea, it turns out it could wreak a fair amount of havoc. A couple of tables could potentially have thousands of rows associated with a single site collection. When SQL starts deleting a large number of rows in a table it may choose to lock that table. Once it does that, all the site collections in the database will be offline until the rows are deleted and the lock is released. Users HATE that.

To help make SharePoint 2010 more resilient, this problem has been addressed. The folks at Microsoft went back to the drawing board and designed a whole new way to delete site collections in SharePoint 2010. Now when a site collection is deleted the job is broken down into smaller steps, so as to not anger SQL and elicit one of its nasty locks. First SharePoint deletes the pointer to the site collection in the configuration database, and from the Sites table in the content database. At that point it is no longer available to end users. As far as they know it is gone. Behind the scenes SharePoint has put a sticky reminder note on its monitor reminding it to delete those old rows when it gets a chance. Then, via a timer job, it deletes small groups of rows until all signs of the site collection are gone. It does this all under the cover of darkness and SQL has no idea. While this isn’t technically something a SharePoint 2010 administrator can do to improve SharePoint’s availability, it is worth mentioning in this section.

Summary

Whew, we covered a lot of ground in this chapter. The big message is that there are many ways to look at disaster recovery and fault tolerance. The techniques you use with your environment depend on which problems you want to protect against, and what your budget is.

The first thing to consider is content recovery. We would get so much done if it weren’t for those darned users. Recovering their content is one of the things we need to plan for. In this chapter we covered various methods of protecting users from themselves. These include how to use versions and recycle bins to recover data. We also discussed a variety of ways to back up content from lists, all the way to site collections.

High availability as described here crosses many boundaries and is not limited to strictly component redundancy; it not only spans technologies, but is contained and managed within the product itself, as illustrated in new resource throttling capabilities and how simple site deletion actions are managed. Like all aspects of continuity management, prior to embarking on developing a high-availability solution, you should clearly understand both your objectives and how SharePoint 2010 is intended to be used in your organization.

The cost and complexity of your high-availability solution will be largely based on your service-level agreements — a very conservative SLA may require a costly and complex solution to meet its requirements, whereas a very liberal SLA may require an inexpensive solution based primarily on warm standby solutions.

Disaster recovery is a critical component of a SharePoint deployment, and planning should begin once a topology has been identified. This planning should not only include consideration of your physical and logical topologies, but also ensure that your strategy supports all underlying RTO and RPO objectives established by your organization. The previous pages have covered some of the available technologies at a high level. While this chapter can’t tell you exactly what’s right for your environment, hopefully it did give an introduction to the tools you can use, and it got you thinking about what aspects of disaster recovery you need to consider.