Chapter 9
Configuring SharePoint for High-Availability Backups
WHAT’S IN THIS CHAPTER?
- Identifying business needs for disaster recovery
- Backing up and restoring SharePoint content and configuration
- Ensuring SharePoint’s resiliency against the unexpected
In the day-to-day business of IT, the unexpected can and does happen. To whatever extent possible, we need to anticipate the unexpected. Hardware will fail. Users will make mistakes. As an administrator, your job is to minimize the impact of these failures on your users, as well as yourself and your business. Planning is key to ensuring that when disaster strikes, your business can recover with an acceptable amount of service interruption.
Understanding what options are available out of the box is the first step to devising a plan and determining what is acceptable to your business. Every business situation is different, with different requirements and acceptable costs. For example, an internal SharePoint intranet farm for a small business doesn’t have quite the same uptime demands as a public-facing e-commerce SharePoint site selling decorative spoons with pictures of cats on them. This chapter covers the most common failure scenarios an enterprise is likely to face, along with the different out-of-the-box options available in SharePoint 2013 for proactively devising a strategy and recovering from them.
DETERMINING YOUR BUSINESS REQUIREMENTS
As a business, your first duty is to your customers. In an IT shop, your customers are typically your end users. In order to effectively meet the needs of your customers, the following agreements are put into place to define the level of service that is expected from a service provider:
- Service-level agreement (SLA) — This is an agreement between the service provider and the consumer of services. In this case, that’s the party responsible for the keeping the SharePoint lights on and the end users. Having a good SLA in place protects both parties. It gives customers an accurate expectation of services that will be provided and offers IT protection from customers who might demand more than the SLA defines. Some common requirements for an SLA are outlined below:
- Service availability — This defines the availability requirements for services such as networking and server infrastructures, not accounting for planned maintenance times. This is normally expressed as a guaranteed percentage of uptime, i.e., 99.999% or 99.95%.
- Performance — This defines the expected performance thresholds of the service, beyond which must be considered out of threshold and must be resolved.
- Reliability — This generally defines the amount of times business impacting service interruption can be tolerated.
- Operational-level agreement (OLA) — This agreement defines the roles and responsibilities between different operational groups. In the case of a complex ecosystem such as a SharePoint farm, it could be shared between Active Directory support, SQL Server Database support, and SharePoint support teams. Additionally, as other Microsoft products become more tightly integrated with SharePoint, such as Lync and Exchange, it may also be necessary to involve these support teams in the OLA.
At the forefront of any examination of business needs vs. acceptable loss will be business continuity planning (BCP). BCP is a defined process for building a road map that maintains operations in the event of a service-interrupting catastrophe.
The first step in the process is the analysis phase, which as its name suggests is used to analyze the threats, and potential impact of these threats, on the business. The threats could be fire, earthquake, hacking, loss of power, locust invasion, or anything else that can result in data loss or downtime. The impact of these threats must also be analyzed and guarded against. The following objectives help to define the tolerance of the business against these threats, and later help to identify the technical implementations required to meet these tolerances:
- Recovery-point objective (RPO) — This objective identifies the maximum amount of data loss that is tolerable. For example, a business might define that no more than one hour of data can be lost at any given time. It might also be defined as something more specific, such as “recovering files that existed at midnight when the backups run.” The shorter the RPO, the more expensive the solution.
- Recovery-time objective (RTO) — The RTO defines the maximum amount of time allowed to restore service. For example, it might be defined that data must be restored within three hours of an outage. When combined with the preceding RPO, only one hour of data may be lost but it may require up to three hours to restore it according to the RTO. As with the RPO, the shorter the RTO, the more expensive the solution.
- Recovery-level objective (RLO) — The RLO defines the granularity level at which you must be able to recover (i.e., entire farm, web application, site collection, site, list or library, or item).
As noted for each objective, the more granular the level of recovery, the more expensive the solution generally becomes. Of course, ideally your users want no data loss (short RPO), immediate availability (short RTO), and recovery down to the item level (short RLO). Unfortunately, you cannot completely eliminate the possibility of downtime or data loss, and the closer you get to that unobtainable goal the more exponentially expensive the solution gets. Unless your company has a collection of solid gold coins that fills a swimming pool, like Scrooge McDuck, you need to find a compromise that balances customer needs with the IT department’s budget and manpower.
The second step in the process is the solution design phase. This phase is intended to identify the most cost-effective implementations for meeting the preceding objectives regarding tolerable data loss and downtime. For this phase it is essential to understand what out-of-the-box capabilities and features are available in not only SharePoint 2013, but also SQL Server, Windows Server, and IIS so that you can identify and recommend the most effective solutions based on the analysis of business impact and the identified objectives for mitigating it. It is also important to understand that different types of data require different levels of impact mitigation. However, the chosen solution, typically based on the most critical data, usually ends up applying to all the data. In addition, it is during this phase that documentation is created detailing the implementation and testing of the recommended solutions.
The implementation phase technically implements the selected solutions and tests them for intended functionality. Once the implementation phase is complete, it is time to move on to organizational testing. During this phase, the solutions are tested under real workloads to validate projected workloads, adjusting as necessary, to ensure stability and reliability of the recovery objectives, and to drive acceptance within the organization.
After testing is successfully completed, the final phase is maintenance. During this phase, data accuracy is verified, documentation is handed off, and further testing is conducted at regular intervals to ensure that the solutions remain functional as the business and its requirements change.
The rest of this chapter discusses the methods available for content recovery, disaster recovery, and high availability using SharePoint 2013. These features play a significant role in designing solutions to meet the needs of your business continuity plan.
CONTENT RECOVERY
The most accessible, and most frequently used, method of data recovery in SharePoint is at the content level. Several options are available for content recovery depending on the retention policies in place and the nature of the deletion or corruption from which you need to recover:
- Version history
- Recycle Bin
- Export and import of subwebs
- Site collection backup and restore
- SQL Server snapshots
Some of the preceding recovery methods provide more than one way to accomplish the task, including PowerShell, Central Administration, and even SQL Server Management Studio, all three of which is covered in detail in this section.
Content Storage Overview
Before we get into the methods for recovering data, it is important to understand how the data itself is stored in SharePoint. Each content database is created with a common table structure, with tables for Site Collections, Users, Web Parts, Lists and Libraries, and the documents themselves. Each item in these tables is relationally linked to the items in other tables via ID columns. For example, in order for SharePoint to know that item.docx belongs to a specific library, there is an entry for the document in the dbo.AllDocs table in the content database with a Document ID column for the document itself, as well as a reference List ID column pointing to the library it belongs to in the dbo.AllLists table.
The document itself is stored in another table called dbo.DocStreams as what is called a binary large object, or BLOB, with a reference Document ID column pointing to the document in the dbo.AllDocs table. In other words, the way data is represented to an end user does not translate directly to how the data is stored and interacted with in the content databases. A document does not physically reside in a SharePoint list as displayed in the browser. Instead, it is associated with it in the manner just described.
As long as you have a good content database backup, you will have a way to recover all content — even if a site or list is corrupted and no longer viewable via the browser. It may require some creative thinking to access it, but it is there. A good database backup means you can probably save both your users’ content and your job. And of course, always keep a backup of your resume on a USB thumb drive at home. You know, just in case that database backup isn’t as good as you think it is.
Version History
While version history is not a disaster recovery technique in the classic sense, it is your first line of defense against users making potentially unwanted changes to files, or even corruption. The version history provides users with a self-service means to quickly revert to an earlier version of any documents or list items.
Versioning is not enabled by default on user-created document library apps when they are created. However, some system-created apps, such as those that are created by activating the Publishing Infrastructure feature, do enable version history by default. To enable versioning, a user must have at least Manage List permissions to the desired app. The version history configuration dialog consists of four sections:
- Content Approval – This section specifies whether the Content Approval workflows for the current library are required when submitting changes. Whether or not content approval should be enforced depends on business processes and how much control users should have over changes.
- Document Version History – This section offers options for version history retention such as No Versions, Create Major Versions (1.0, 2.0, 3.0, etc.), and Create Major and Minor (also known as Draft) Versions (1.0, 1.1, 1.2, 2.0, 2.1, etc.). Note that only the major versions option is available for lists, while both major and minor versions are available for libraries.
- Draft Item Security – In a list this section is grayed out unless Content Approval is enabled, while for a library the setting is activated when minor versioning is enabled. It controls who can see Draft items once they are submitted. Options are Any User, Users with Edit permissions, or Approvers.
- Require Check Out – This section specifies whether an item must be checked out prior to being edited. Enabling this option for a library prevents multiple users from editing the same document concurrently, potentially overwriting each other’s changes. It also enables users to submit check-in comments when they upload their changes.
In previous releases of SharePoint, storing multiple versions had the potential to significantly increase the size of your content databases because each uploaded version of a file was stored as an entire file. For example, suppose you had a 100MB PowerPoint file in your content database explaining why cats are better pets than dogs. If someone opened that document and simply replaced the word “cat” with “kitties” on the first slide, the new version would occupy another 100MB of space in the content database. Before you know it, your content database is as big as a house.
SharePoint 2013 introduces a new technology called Shredded Storage. This technology enables SharePoint to store only the changes made to a document, instead of the entire file each time. Of course, despite the magic of Shredded Storage, all your site collections should have size quotas in place to ensure they don’t grow out of control.
Enabling Versioning
The following steps describe how to configure versioning for libraries:
Enabling version history for a list is virtually identical to libraries, but with a few minor differences:
Reverting to a Previous Version
To restore a previous version, perform the following steps:
Although versioning isn’t technically a disaster recovery technique, it can be quickly used by a user to bring back an old version of a document if the current version is corrupt or unacceptable for some reason.
The Recycle Bin
The Recycle Bin has been around since Windows SharePoint Services (WSS) 3.0 and has seen many enhancements over the last couple of versions. The Recycle Bin offers a self-service capability for users to recover deleted content — whether it be documents, lists, or list items. SharePoint 2010 Service Pack 1 added the Site and Site Collection Recycle Bins, which are covered in more detail here.
The Recycle Bin is enabled by default and can be configured at the web application level through Central Administration. The Recycle Bins themselves are divided into the following stages:
- Stage 1 — The first-stage Recycle Bin is the highest level. It is available directly to end users for self-service recovery. The minimum permissions necessary to use the stage 1 Recycle Bin is Contribute or higher. The files in this Recycle Bin have not been removed from the content database and are therefore included in the overall site quota until the configured number of retention policy days has been reached. The default retention policy is 30 days, but farm administrators can change this setting for the web application through Central Administration.
- Stage 2 — The stage 2 Recycle Bin is found at the site collection level and is accessible only to site collection administrators. When a user deletes a file from the stage 1 Recycle Bin, it is moved here. Items are then retained in the stage 2 Recycle Bin for the configured number of days, which has the same default 30-day retention policy as stage 1, unless it is configured otherwise.
Farm administrators can configure the maximum size limit to specify when the oldest files in the Recycle Bin should be deleted automatically. SharePoint determines the age of the file according to when it was first deleted, not when it was moved to the stage 2 Recycle Bin.
Files in the stage 2 Recycle Bin do not count toward the site collection quota. Instead, the size of the Recycle Bin is calculated at a percentage (default is 50%) of the size of the site collection quota. This means that in addition to the size quota for each site collection, you must also factor in an additional 50% overhead on the content database size for stage 2 Recycle Bin growth. If no quota is assigned to the site collection, then there is no limit to the size of the stage 2 Recycle Bin. Be sure your site collections have quotas.
Configuring the Recycle Bin
The Recycle Bin is enabled by default and configured at the web application level in Central Administration. To configure each web application’s Recycle Bin policies, use the following steps:
Recovering Items from the Stage 1 Recycle Bin
For readers who keep accidentally deleting their content, this Recycle Bin is for you. To get your content back, follow these steps:
Recovering Items from the Stage 2 Recycle Bin
If you can’t find your document in the stage 1 Recycle Bin, the next place to look is the Site Collection Recycle Bin. To get to the Site Collection Recycle Bin, you need to take a slightly different route:
Recovering a Site Collection from the Site Collection Recycle Bin
Site Collection recovery is handled a little differently. Obviously, you can’t restore a site collection from within the stage 2 Recycle Bin, as it would be contained within the site collection you are trying to recover! Instead, site collections must be recovered through the PowerShell cmdlet, Get-SPDeletedSite. This recovery method is unchanged from SharePoint 2010 Service Pack 1, where it was first introduced. To recover a deleted site collection, do the following:
Get-SPDeletedSite
Get-SPDeletedSite –Identity "SiteId" | Restore-SPDeletedSiteIf at this point you are thinking that recovering a deleted site collection is the best thing since sliced bread, there are some shortcomings to keep in mind. First, only site collections that are deleted from the browser can be recovered. If a site collection is deleted from PowerShell, or from code, it can’t be recovered. Second, in order to recover a site collection, the user running PowerShell must be in the ShellAdmins group of that content’s database.
Exporting and Importing Sites, Lists, and Libraries
SharePoint 2013 maintains much of the Content Deployment feature set that provides the functionality for the Export and Import process from SharePoint 2010. Using either Central Administration or PowerShell, it is possible to export and import lists, libraries, or even whole webs, with a number of options for maintaining security settings and version history. The exported content is compressed into Microsoft standard CAB files with an extension of .cmp (which is an acronym for content migration package), and it may span one or more files.
The Content Deployment application programming interface (API) in SharePoint is primarily intended, as its name suggests, for deploying content between site collections, web applications, and even farms. However, a side benefit is that it can also be used to deploy that content out to the filesystem (considered exporting) to be later imported to the same location as a data recovery tool, or to an alternate path. This flexibility makes it a useful tool not only as a backup strategy, but also in your development and migration from testing to production strategies.
Before using the import and export cmdlets, ensure that you are a member of the WSS_ADMIN_WPG local group on the server you are logged into. If you have a lot of servers in the farm and need to add this privilege to all of them at once, you can use the following command in the SharePoint 2013 Management Shell to add a user to the WSS_ADMIN_WPG group on all servers, and add the user to the SharePoint_Shell_Access role in the farm configuration database and any content databases where data is being either exported or imported:
Add-SPShellAdmin contosoadministratorThis is covered in more detail in Chapter 7, which focuses on PowerShell.
Exporting Sites, Lists, and Libraries with PowerShell
Windows PowerShell cmdlets provide a great deal of functionality and automation to the arsenal of SharePoint 2013 features. The Export-SPWeb cmdlet provides the capability to export not only webs, as the name suggests, but even lists and libraries, which can be imported back to the same farm or other SharePoint 2013 farms.
When using the Export-SPWeb cmdlet, the following options are available:
- Identity — This parameter specifies the URL or GUID of the web you want to export.
- Path — This parameter specifies where you want to save the .cmp files to the filesystem.
- Force —This switch lets you overwrite existing .cmp files from previous export attempts.
- IncludeUserSecurity — This specifies that you wish to maintain site- and item-level permissions, along with time stamps, in the exported content.
- IncludeVersions — Use this parameter to set the version level of history files to export. The following values can be specified for this parameter:
- Last major version for files and list items (default)
- The current version, either the last major version or the last minor version
- Last major and last minor version for files and list items
- All versions for files and list items
- ItemUrl — This parameter specifies the URL or GUID of the object you want to export. It is used for granular backups of lists and libraries within the site specified in the Identity parameter.
- NoFileCompression — Use this switch to disable compression of the exported content. This can be useful in situations where processing and memory resources are limited or you just want to increase the performance of the export. If your exports are failing due to time outs or other errors, this may be able to resolve them. Instead of writing out a .cmp file, the export is written to a directory.
- NoLogFile — This switch suppresses the creation of a log file during the export, which by default is generated in the same location as the export package.
- UseSQLSnapshot — If SharePoint is using an edition of SQL Server that supports snapshots, you can use this switch to specify whether the export should be executed against an SQL snapshot. To export a site using Windows PowerShell, use the following command in the SharePoint Management Shell:
Export-SPWeb –identity http://portal.contoso.com -path C:ackupssite.cmp
To export a list or library, use the following command syntax, (all on one line) adding the ItemUrl parameter:
Export-SPWeb –identity http://portal.contoso.com
-path C:ackupslist.cmp –ItemUrl
"/Shared Documents"To see all the parameters for this or any other PowerShell cmdlet, use the following syntax from the SharePoint 2013 Management Shell:
Get-Help Export-SPWeb -fullImporting Sites, Lists, and Libraries with PowerShell
Similar to the export functionality, the Import-SPWeb cmdlet provides the capability to import sites, lists, and libraries via the SharePoint 2013 Management Shell with the following options:
- Identity and Path — These parameters are used as you would use them with the Export-SPWeb cmdlet.
- ActivateSolutions — Use this switch if you want to automatically activate User Solutions during import.
- Force — As its name implies, this forces the import to continue, which is useful for overwriting existing content at the destination URL.
- HaltOnError and HaltOnWarning — These cause the import process to stop for failures, letting you know something went awry and enabling you to view the logs to determine what went wrong without having to wait for the entire import process to complete.
- IncludeUserCustomAction — This parameter specifies whether or not to import user custom actions during import.
- IncludeUserSecurity — This specifies whether or not to import the site and item-level security. This option is useful only if you specified the IncludeUserSecurity switch during export.
- NoFileCompression — Use this switch if the export was done using the same switch. Mixing compression switches between export and import packages results in failed imports.
- NoLogFile — As with the Export-SPWeb cmdlet, this suppresses the creation of a log file during import.
- UpdateVersions — This parameter, specifies the overwrite policy you want to use during import. You don’t need to know what values were used for IncludeVersions in Export-SPWeb. All versions will be imported based on the following values:
- Append — Adds new versions to the current file (this is the default if nothing is specified)
- Overwrite — Deletes the existing file, then inserts the imported file and all of its versions
- Ignore — Skips the file if it exists on the destination
To import a site, list, or library, use the following syntax: (enter this all on one line)
Import-SPWeb http://portal.contoso.com
-Path C:ackupslist.cmp -UpdateVersions
OverwriteWhen importing a site, the URL into which you are importing must be using the same template as the exported content. For example, if an exported site was created using the Team Site template (STS#0), the destination site must also use the STS#0 template.
Exporting Sites, Lists, and Libraries with Central Administration
As you can see, PowerShell provides a lot of flexibility when you are performing exports and imports, but sometimes you just need a quick and easy way to export some desired content. Central Administration also provides a way to export sites, lists, and libraries easily.
As we go through this section you will notice that the Backup and Restore page in Central Administration doesn’t offer any means for importing your newly exported package. You will still need to use the PowerShell cmdlets covered earlier to perform an import.
To export a site, list, or library using Central Administration, do the following:
Why is there a UNC path, and not just a normal drive path? If you’ve set your farm up correctly (Least Privilege), your SharePoint Timer service is running as a user who has no privileges to the local filesystem on the Central Administration server. Requiring a UNC path forces you to configure a new file share (don’t use the default admin file shares!) on any one of your servers, and give both the Timer Service and the SQL Service accounts Read/Write permissions to it. This little bit of up-front work offers greater flexibility and greatly reduces the likelihood of a failed export due to unknown permissions requirements, which could make your server less secure.
The reason this is not a requirement when exporting with PowerShell is because, as you’ve seen, the PowerShell code executes directly as the logged-in user, not the Timer Service. If the user is logged in directly to the server, it stands to reason that the user has permissions to the destination folder. If the user doesn’t, PowerShell is kind enough to point that fact out.
Note that nondeclarative workflows and alerts are not exported with the content. Declarative workflows (workflows created with SharePoint Designer) will get exported, however they will not automatically be re-associated with their targeted lists or libraries. This is because the export and import tools are primarily focused on content deployment, so functionality that is not content is not always brought over. This is also true for many third-party add-ons that may have been used through the sites.
Also of note is that exports and imports, in addition to being part of a backup strategy, are also intended to be used to duplicate subsites, sometimes in the same farm. When exporting and importing a subsite, web and list IDs do not get retained. This can have a significant impact on web parts, or other processes, that refer to specific list IDs, and these will need to be reconfigured to point to the new list IDs once the import is completed. Be sure to test content exports and imports to verify that they cover all the pieces you think you are covering before you consider your disaster recovery mission accomplished.
Backing Up and Restoring Site Collections
Up to this point you have seen that sites, lists, and libraries can be backed up using PowerShell or Central Administration, but only PowerShell can restore them. The same holds true for site collection backups and restores with the exception of restoring from an unattached content database, which can only be done through Central Administration, not PowerShell.
Site collection backups can be a very useful tool in any backup strategy, but its usage should be limited to very important site collections under 100GB in size. That’s because the site collection backup and restore can be very resource-intensive for the SQL server, which can affect performance or even fail if the site collection coexists with other active site collections in the same database. In any case, for site collections over 100GB, it is recommended that you backup and restore the content database itself, as covered later in this chapter.
Backing Up Site Collections with PowerShell
Like exports and imports, PowerShell is a very effective tool for performing site collection backups, whether you want to automate the task or just have more flexibility and control over it.
The Backup-SPSite cmdlet produces a single-file backup of a site collection with a .bak extension. Unlike the exports you performed earlier, these backups are full fidelity, meaning workflows, alerts, and everything else within the site collection is backed up. Site collection backups are portable, but with some restrictions. If you want to restore the site collection to the same farm from which it was backed up, you have to do some fancy footwork. A content database can contain only one copy of a given site collection. If you want to restore your backup to the same web application from which it was backed up, you need to either delete the original site collection or create a new content database into which the backup can be stored. Aside from that, the site collection backup may be restored to either the same farm or a different farm, as long as the destination farm is the same build or later as the source farm.
The Backup-SPSite cmdlet for performing a site collection backup offers some familiar and some not-so-familiar parameters for control:
- Identity and Path — These parameters, and the Force switch, should be familiar to you now. They work the same here as they do with other commands in this chapter.
- NoSiteLock — This switch specifies that the site collection should remain read/write during the backup operation.
- UseSQLSnapshot — If SharePoint is using an edition of SQL Server that supports snapshots, this switch specifies that an SQL Database Snapshot will be created when the backup begins, and all site collection data will be retrieved directly from the database snapshot, which is then deleted automatically when the backup completes. This parameter ensures that a valid backup occurs while enabling users to continue reading and writing to the site collection during the backup. It is not necessary to specify the NoSiteLock parameter when specifying this parameter.
The syntax for performing a single site collection backup is as follows (enter it all on a single line):
Backup-SPSite –Identity http://portal.contoso.com/sites/legal
-Path C:ackupslegal.bak
[-Force] [-NoSiteLock] [-UseSQLSnapshot] [-Verbose]The beauty of PowerShell is the ability to get more done with less administrative effort. For example, if you needed to back up 30 site collections across 10 web applications, it would be a huge hassle to run the preceding command so many times. Instead, you can use the following syntax to loop through each web application in the farm, then each site collection, and back each one up (again, enter this all on a single line in PowerShell):
Get-SPWebApplication | Get-SPSite –Limit All | ForEach-Object{$FilePath =
"C:ackups" +
$_.Url.Replace("http://","").Replace("/","-") +
".bak"; Backup-SPSite –Identity $_.Url –Path $FilePath}Before you go off to conquer the world of site collection backups, check the size of any site collections you will be backing up to ensure that you won’t exceed your server’s drive space and risk corruption. The following command will print out the size of all of your site collections, in megabytes:
Start-SPAssignment -Global; Get-SPWebApplication | Get-SPSite |
ForEach-Object{
(Get-SPSiteAdministration -Identity $_)} |
ForEach-Object{Write-Host $_.Url "size in megabytes: ";
[math]::truncate($_.DiskUsed / 1MB)}; Stop-SPAssignment -GlobalRestoring Site Collections with PowerShell
Site Collection backups are not much good unless you can restore them. As you likely assume, just as there is a Backup-SPSite cmdlet, there is a complementary Restore-SPSite cmdlet. As always, using the Get-Help cmdlet will provide all the gory details about the Restore-SPSite cmdlet.
Along with the regulars such as Identity, Path and Force, the Restore-SPsite cmdlet has some additional parameters that provide flexibility in terms of how your site collections are restored:
- DatabaseName and DatabaseServer — These parameters enable you to direct the restore to not only a specific content database, but even to an alternate SQL server than your default.
- HostHeaderWebApplication — This parameter restores the site collection as a host-named site collection (i.e., the site collection is named site.domain.com instead of /sites/sitename). When this parameter is used, the Identity parameter becomes the URL of the host-named site collection, while the HostHeaderWebApplication parameter is the URL of the web application that will host the site collection.
- Force — If you are using the Force switch to overwrite an existing site collection that is very large, it is recommended to use the GradualDelete switch. This switch specifies that the existing site collection should be deleted slowly over time to minimize the resource impact on the SQL server during the restore.
To restore a site collection using PowerShell, use the following syntax (you guessed it, all on a single line in PowerShell):
Restore-SPSite –Identity http://portal.contoso.com/sites/legal
-Path
C:ackupslegal.bak [-DatabaseServer <Database Server Name>]
[-DatabaseName
<Content Database Name>] [-Force] [-GradualDelete]
[-Verbose]Backing Up Site Collections with Central Administration
Similar to the export functionality, Central Administration provides functionality for performing site collection backups. Unfortunately, the same limitations apply — namely there is no functionality for restoring a site collection through Central Administration. You must use PowerShell, as discussed earlier in this chapter, to restore any backed up site collections to your farm.
To perform a site collection backup using Central Administration, follow these steps:
Whether you back up your site collections with PowerShell or Central Admin, you need to practice restoring them before a disaster strikes. Those practice runs let you test the process in peace without your phone ringing constantly, your IM client blinking incessantly, and your boss tapping his foot impatiently while you figure out how to restore a site collection. It’s much easier to figure it out without all those distractions. A couple of practice runs will also help you build your confidence, so in the unlikely event of a SharePoint disaster you’ll know you can restore that important content, and maybe you’ll be able to avoid that painful knot in the pit of your stomach.
Restoring from an Unattached Content Database
Imagine a situation in which a deleted document has expired or was emptied out of the stage 1 and stage 2 Recycle Bins. It wouldn’t make sense to restore an entire content database, site collection, site, or even a whole library just to retrieve this one document. Any of these method’s actions would result in a lot of collateral damage, as all the other documents are restored along with these containers.
Recall from earlier in the chapter that as long as you have a content database, you can always recover data. This is your first line of defense for the preceding situation. The capability to restore a content database to SQL Server and then recover data from it without ever attaching it to a web application is a feature that was added in SharePoint 2010, and it remains a lifesaving option in SharePoint 2013.
In order to restore content from an unattached content database, do the following:
Recovering from SQL Server Snapshots
SQL Server snapshots are a feature of SQL Server Enterprise Editions only. This feature enables you to create a read-only view of the source database that is transactionally consistent with the source database at the time the snapshot is created. Restoring a snapshot to a live site overwrites previous values, bringing the content in the database back to the point in time at which the snapshot was created.
Although snapshots are useful for both reporting and recovery, they can have an adverse effect on the performance of an SQL server. This is due to the overhead of writing previous values to the snapshot because they are overwritten in the source, as well as the disk space required for an ever-growing snapshot. For this reason, the snapshot functionality is best used in development scenarios or as a method of rollback during a content push that may have undesirable effects.
Support for database snapshots was introduced in SharePoint 2010 and continues in SharePoint 2013. The only means for creating a snapshot is by using T-SQL statements through supported APIs, or via SQL Server Management Studio as shown in Figure 9-16. The method for creating the snapshot in SQL Server 2012 is virtually identical to its predecessors.
Some SharePoint operations, such as Backup-SPSite, automatically manage the creation of the SQL Server snapshot if you use the appropriate parameters.
BACKING UP AND RECOVERING FROM DISASTER
The preceding sections have covered many out-of-the-box features provided by SharePoint 2013 for recovering deleted or corrupted content. While these features should be an integral part of any business continuity plan for quickly recovering lost content, none of these features are truly sufficient for disaster recovery scenarios.
If your SQL server crashes, or the entire farm is wiped out due to a natural disaster and has to be rebuilt, recovering the data through individual site collection restores would be an arduous task, and it really only covers the content. You also need to get the rest of the farm services and service applications back up and running as quickly as possible. You would also need rebuild all the web applications and configure them. This section covers your available options for meeting the disaster recovery needs of your business continuity plan.
SharePoint 2013 provides tools and features to help you protect the following aspects of your farm and recover quickly from disaster:
- Full farm backup and restore
- Configuration databases
- Web applications
- Service applications
- Services
As with all content backup and restore functionality, all of the preceding disaster recovery backups can be performed through Central Administration and Windows PowerShell.
Backing Up and Restoring Content Databases
So far this chapter has focused on backing up and restoring different content within a content database. However, in a disaster or migration scenario, you are going to need a way to back up and restore entire content databases using either full or differential (any changes since the last full backup) methods.
Backing Up Content Databases with PowerShell
To back up a content database using Windows PowerShell, use the following syntax (on a single line):
Backup-SPFarm –Directory <Backup Folder> –BackupMethod (Full | Differential)
–Item
<Content Database Name> [-Verbose]Restoring Content Databases with PowerShell
Restoring a content database via Windows PowerShell is very similar in syntax to the backup command (on one line):
Restore-SPFarm –Directory <Backup Folder> –RestoreMethod Overwrite
–Item
<Content Database Name> [-BackupId <GUID>] [-Verbose]Backing Up Content Databases with Central Administration
To back up a content database using Central Administration, follow these steps:
After the backup starts you can view the status of the job on the Backup and Restore Job Status page, shown in Figure 9-18. Selecting the View History link on the page will show you the status of previous jobs that have been run. If you have already browsed away from the page, you can get back to it by returning to Backup and Restore and clicking Check Backup and Restore Status under the Farm Backup and Restore section.
Restoring Content Databases with Central Administration
Unlike previous examples, in which you could only back up certain content through Central Administration, but not restore it, you can restore content databases directly through Central Administration:
- New Configuration — This option allows you to perform a restore using alternative configurations such as different server names, web applications, and a different database server. Selecting this option enables the fields for these three parameters, enabling you to change their configuration. This is useful in a migration scenario, or perhaps to restore to a recovery farm so you can recover content without impacting a live farm.
- Same Configuration — This option restores the data directly back to its original location, overwriting as it goes. This is most useful if you just have missing content that you need to put back, but it overwrites any existing content.
Backing Up Content Databases with SQL Server
In addition to the core SharePoint backup and restore functionality, SQL Server provides several options for backing up and restoring content databases. Full and Simple recovery models enable you to specify whether you just want database backups at regular intervals (Simple), or whether you will need point-in-time recovery (Full).
If you have a third-party backup utility, you will probably use the Simple recovery model. Otherwise, you are likely to run into disk space issues as your SQL transaction logs grow very large without any maintenance. If you will be doing your backups via SQL maintenance plans, you may want to use the Full recovery model, which provides greater flexibility at the cost of more frequent backups. Maintenance plans can be configured to automatically truncate and shrink the transaction log files every time they are backed up, preventing the unmanaged growth mentioned earlier. It is not uncommon to see hourly transaction log backups to greatly reduce the risk of data loss in the event of a disaster and to keep the transaction log sizes small. For the greatest safety, you should never store the backup files on the same storage location as the original data files, but be aware that frequent transfers of large backup files across the network is not without its own impact on available resources.
In addition to the recovery models there are backup types, including Full, Differential, and Incremental. Depending on your specific recovery point and recovery time objectives, you will most likely combine these options to meet business needs. The Full database backup is the simplest form of backup, providing a complete copy of the content database. This works well for smaller databases for which the backup can be accomplished in a minimal amount of time. For larger databases it is common to move to a less frequent Full backup, weekly in some cases, with daily Differential or Incremental backups to pick up any changes since the Full backup.
Differentials capture any changes since the last full backup, so they tend to get bigger as the period between the last Full backup and the next Differential backup grows. When restoring via a Full/Differential combination, you only need to restore the Full database and then the last Differential right before the point-in-time you need restored. This can greatly speed up recovery time and is less likely to succumb to a bad backup due to data corruption in the backup files.
Incremental backups capture changes since the last Incremental backup was taken. This results in very fast and very compact backup files. However, when restoring, it is necessary to first restore the Full backup and then restore every Incremental up to the point in time you need restored. The other downside is that if any of the Incremental backup files in the chain are lost or corrupted, you won’t be able to recover anything past that recovery point.
Follow these steps to perform a Full backup of an individual SharePoint 2013 content database using SQL Server Management Studio:
Restoring Content Databases with SQL Server
To perform a restore of an individual SharePoint 2013 content database using SQL Server Management Studio, do the following:
Backing Up and Restoring Service Applications
The service application architecture of SharePoint 2013 expands upon the service applications provided in the previous version. Several new service applications, with associated databases, have been added, while others have been updated or removed. The methods for backing up and restoring service applications remain much the same as they were before.
As with many of the other backup and restore scenarios covered previously, the two options available are Windows PowerShell cmdlets and Central Administration. Using these tools you have the option to back up entire service applications, including data, or just each service application’s unique configuration.
Backing Up Service Applications with PowerShell
To back up a service application using Windows PowerShell, you first need to get the path and name of the service application you want to back up using the following command:
Backup-SPFarm –ShowTreeThis command outputs a tree structure of the farm layout. You need to know the full path of the service application through this tree in order to use to the Backup-SPFarm command. It looks something like the following:
FarmShared ServicesShared Services Applications
Business Data Connectivity ServicesTo perform the backup of the service application, use the following syntax in the SharePoint Management Shell, replacing the example –Item path with the correct path to your service application:
Backup-SPFarm –Directory C:ackups –BackupMethod (Full | Differential)
–Item
"FarmShared ServicesShared Services Applications
Business Data Connectivity Services" [-Verbose]Restoring Service Applications with PowerShell
To perform a restore of a service application, first look up the Operation ID of the backup you want to restore from using the following command:
Get-SPBackupHistory –Directory C:ackups –ShowBackupTo perform the actual restore, use the following syntax:
Restore-SPFarm -Directory C:ackups -Item "FarmShared Services
Shared Services
ApplicationsBusiness Data Connectivity Services"
-RestoreMethod Overwrite [ -BackupId <OperationID>] [-Verbose]Backing Up Service Applications with Central Administration
Backing up and restoring a service application in Central Administration is nearly identical to the content database backup. To perform a service application backup, do the following:
Restoring Service Applications with Central Administration
To restore a service application through Central Administration, do the following:
- Login Names and Passwords — This is the login and password for the application pool under which the service application runs. The default is the service application account name that was backed up. To continue with this account you just need to provide the password for that account.
- New Name — This is the display name of the service application. You should specify a different name here to avoid conflicts.
- The following three database configuration options will be repeated for each database associated with the service application being restored:
- New Directory Name — This is the location where you want the SQL Server database files to be stored when they are restored to SQL Server.
- New Database Name — This is the database name. Choose a new name to avoid naming conflicts.
- New Database Server Name — The database server name enables you to either use the original database server or specify a different one.
Backing Up Service Applications with SQL Server
Many service applications have databases; and when they do, the contents of the database are what you really care about — the configuration of the service application itself is pretty trivial. In most cases you can back up the service application’s database in SQL Server and restore it to a new instance of that service application. You’ll still need to configure it, but you won’t lose any data.
For instance, if you back up your Managed Metadata service application database, you’ve backed up all your term sets. To recover that data you could create a new Managed Metadata service application, in either the original farm or a new one. When you’re asked to provide a database name for the service application, give it the name to which you restored the database. When the Managed Metadata service application comes online, it will have all the terms that were in the database. You may still need to configure the service application’s permissions, or whether it’s the default Managed Metadata service application, but that’s small potatoes compared to re-creating the terms themselves. The following service applications support being created with restored databases:
- Managed Metadata
- Business Connectivity Services
- Search (Admin database only)
- User Profile Service (Social and Profile databases only)
- Secure Store
Backing Up the Farm
The capability to perform a Full farm backup is useful in situations for which an entire farm topology needs to be recovered to existing hardware or to a standby configuration. However, the usefulness of this type of backup depends on your RPOs and RTOs, as this sort of farm restore results in prolonged downtime in order to bring a new standby farm online. Organizations with large, complex topologies will be better served using more efficient methodologies such as a warm standby solution using SQL Server log-shipping to maintain up-to-date copies of the farm databases between live and standby SQL servers.
In addition to Full farm backups is the capability to back up just the farm configuration. This feature makes hardware migration scenarios, and duplicating farm configurations between development and production, a breeze. The farm configuration backup backs up only the elements of the configuration that are not tied to the unique properties of the farm being backed up, such as server names, web applications, service applications, and so on. This enables you to duplicate the root configuration of your farm, such as InfoPath Forms Service configuration, sandbox solutions, farm solution configuration, and so on, without having to worry about differences in topology.
Backing Up the Farm with PowerShell
To perform a farm backup using Windows PowerShell, enter the following command in the Microsoft SharePoint 2013 Management Shell:
Backup-SPFarm -Directory <Backup folder> -BackupMethod {Full | Differential}
[ -Verbose]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. If you only want to capture the farm configuration, add the -ConfigurationOnly switch to the preceding command.
Restoring the Farm with PowerShell
To restore from a full farm backup, use the following syntax:
Restore-SPFarm -Directory C:ackups -RestoreMethod {New | Overwrite} [ -Verbose]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, always use the -Verbose switch to monitor the operation and its status. Similarly, use the -ConfigurationOnly switch to restore only the farm configuration.
Backing Up the Farm with Central Administration
By now a pattern should be emerging. Backing up various elements of a farm is done using the same Perform a Backup link in Central Administration. The primary difference is the selections you make. To perform a backup of the entire farm, do the following:
Restoring the Farm with Central Administration
To restore a farm through Central Administration, do the following:
- Restore Options — Select from New Configuration or Same Configuration. New configuration enables you to specify new server names, web application names, or database servers. Same Configuration assumes that all the pieces of the farm are the same as when the backup was taken.
- Login Names and Passwords — This specifies the login and password for the application pools under which the service applications and web applications will run. The default is the account names that were backed up. To continue with these accounts you just need to provide the passwords for each account.
- New Names — This specifies the display name of the service applications and web applications. You should specify a different name here to avoid naming conflicts. Also, many of the service application and web application configurations have additional modifiable fields where you can customize their restored configuration.
Backing Up IIS
Another area that you should address in your backup strategy is the IIS configuration of your SharePoint farm. While not recommended as a restore source due to SharePoint’s control of the site configuration, the backups should be performed as a documentation strategy to keep track of nonstandard changes to the web.config file or the folder structure of the sites in case they ever need to be rebuilt.
IIS includes a command-line utility for performing backups and restores of the windowssystem32inetsrvconfig directory. This is the location where all IIS configuration settings are stored.
In order to back up your IIS configuration, run the following command:
%windir%system32inetsrvappcmd.exe add backup "First IIS Backup"Use this to restore:
%windir%system32inetsrvappcmd.exe add restore "First IIS Backup"In addition to the capability to perform the preceding on-demand IIS backup, IIS 7 has an out-of-the-box feature that automatically captures the configuration history as changes take place. This feature takes snapshots of the ApplicationHost.config file anytime a change is detected, enabling you to restore up to 10 previous versions. IIS checks every 120 seconds for a new version of the ApplicationHost.config file, and then stores the versions in the %systemdrive%inetpubhistory folder. You can find and change the settings that specify how often IIS checks and where the versions are stored in the <system.applicationHost/configHistory> section of the ApplicationHost.config file itself.
Backing Up Customizations
Although all your content will be backed up with the content databases, if you have made any sort of customizations you should be sure to back up every piece of supporting material to ensure a smooth recovery. Some of the possible customizations include the following:
- Registry modifications in support of third-party add-ons such as an iFilter
- Custom assemblies deployed to the global assembly cache (GAC)
- Web.config changes made manually, outside of the object model
Customizations that are typically contained within the content database, but could have elements found elsewhere in the filesystem, such as new SharePoint Features which are the primary type of customizations deployed in on-premises configurations, include the following:
- Master pages, cascading style sheets (CSS), or custom page layouts (though these should really be stored in SharePoint)
- Web Parts, site and list definitions, content types, custom actions, and so on (these should be installed via Solutions)
- Third-party solutions
The preferred method for backing up customizations deployed by a development team is to use the built-in features of the development environment, such as Visual Studio Team Foundation, through which the development team can maintain version histories of the codebase along with any related documentation. The benefit of this development method is that it makes it much easier to redeploy any solutions in the event of a disaster.
In addition to the preceding examples, there could also be customizations that fall outside the scope of the development environment’s control. Other places that you might find additional customizations include the SharePoint 15 root, located at %commonfiles%Microsoft SharedWeb Server Extensions15, the website root folder, at %systemdrive%inetpub, and the GAC, at %windir%Assembly. It is important to ensure that any customizations deployed to these locations are well documented and captured in the standard filesystem backups.
HIGH-AVAILABILITY CONFIGURATIONS
Up to this point the chapter has discussed what to back up and what to do in the case of an outage, or worse. However, as stated by Ben Franklin, “An ounce of prevention is worth a pound of cure.” This is just as true when it comes to technology, if not more so. This section covers several things you can do to both avert and weather a bad storm caused by hardware failures, natural disaster, and anything else known to keep administrators from sleeping well at night.
SharePoint 2013 offers several configurations to support scalability, redundancy, and efficient mitigation of downtime. The configurations discussed in this section cover load-balancing, SQL Server 2012 AlwaysOn Failover Clustering and Availability Groups, request-throttling, and site collection gradual deletion. Each of these configurations has a price tag that must be weighed against any service-level agreements in place in your organization.
Load-Balancing
SharePoint 2013 supports several options for load-balancing the environment, some of which can be configured within SharePoint itself, and others that will likely require additional hardware and resources. The most common configuration is to load balance through either a hardware or a software load balancer to ensure that requests going to the SharePoint sites are divided equally among the web front ends. Whether you choose a hardware or a software, load balancer will mostly depend on the capabilities and scale required to meet your objectives.
New to SharePoint 2013 is the Request Manager service. This new service works in concert with a hardware or software load balancer. It enables a SharePoint administrator to define rules that control what traffic goes to which web front-end server. One of the many rules you can create is based on server health, which helps you balance the load and relieve your farm’s busiest servers. You can read more about the Request Manager service in Chapter 2, “Architecture and Capacity Planning.”
SharePoint’s service application architecture enables you to create multiple service endpoints throughout your farm to help with load-balancing and failover redundancy of service application requests. You can accomplish this by doing the following:
Once you have a service running across multiple servers, SharePoint will manage the service application requests in a round-robin fashion. A service application proxy will request an endpoint for a connected service application from SharePoint’s internal load balancer, which is a software component that executes in the same process as the proxy itself. The load balancer keeps a cache of each of the service application endpoints, and returns the next available endpoint.
SQL AlwaysOn Failover-Clustering
Introduced in SQL Server 2005, failover-clustering remains one of the most valuable means for averting SharePoint disasters, as the majority of SharePoint configuration and content is stored within the databases themselves.
Clustering enables the use of a local online spare, referred to as a passive node. If the first, or active node, reboots, has a service crash, or dies altogether, the passive node becomes active and picks up where the previous server left off. Because the active and passive nodes share the same storage, this can shave hours, and in some cases days, off of a hardware or software failure recovery. The clustered servers are directly connected by a network connection through which a “heartbeat” signal is bounced between the servers. Anytime the active node does not respond to a heartbeat, the passive node assumes all clustering responsibilities.
The clustering itself is accomplished through the use of software such as Microsoft Clustering Services. You can find more information on configuring a cluster at http://technet.microsoft.com/en-us/library/cc731844(v=ws.10).aspx.
SQL Server AlwaysOn Availability Groups
SQL Server clustering is great for protection against local hardware or software failures, but it is not going to be much help if your server room is flooded, or in the case of a power outage. Although SQL Server mirroring has been deprecated as of SQL Server 2012, SharePoint 2013 also offers support for the new SQL Server 2012 Availability Groups (AG) in order to provide the capability to replicate your configuration and data to different geographic locations in either a hot or warm spare configuration. Some of the enhancements in SQL Server 2012 Availability Groups over mirroring include the following:
- You can configure up to four additional copies of your databases across different SQL server nodes.
- You can configure the copies to be a mix of synchronous and asynchronous, to meet the communicative limitations between the nodes.
- AGs enable a separate SharePoint recovery farm to have read-only access to the mirrored databases on a remote SQL Server node. This is useful in DR scenarios for which you need immediate access to recover up-to-the-minute data.
The two configuration types for Availability Groups allow for both high availability and disaster recovery at the same time, which is in stark contrast to SQL Server mirroring:
- Synchronous — This configuration provides a hot standby solution for rapid failover with minimal (in-flight transactions at the moment of network disruption) data loss. It is accomplished by requiring that the mirror acknowledge each transaction before it can be committed to the principal database. This configuration provides the quickest failover and data resiliency, but it has inherent inefficiencies when long distances separate the servers, such as network problems or issues with the mirror database, which can have a detrimental impact on the principal. This configuration should be used when the network link between nodes is greater than 1Gb with less than 10ms of latency.
- Asynchronous — This configuration is better suited to disaster recovery scenarios, as it operates in high-performance mode, rather than high availability. This provides greater efficiency and has less impact on the principal if there are minor errors with the mirror. This configuration is ideally suited to slower network links between SQL Server nodes, such as with WAN links.
Availability Groups are included only with the Enterprise Edition of SQL Server 2012. For those still using Standard Edition of SQL Server 2012, or earlier versions of SQL Server, mirroring is still an option supported by both SharePoint 2013 and SQL Server 2012, but it is scheduled to be phased out of the product line in future releases.
HTTP Request Throttling
As with any website, there may come a time when the user load overtakes your server resources in the farm. This can lead to lost farm data if a user clicks Submit and gets an error. The obvious solution is to add more servers or give your existing servers more resources; but despite how my Dell loves this option to vendors, it can sometimes involve lengthy order and delivery processes, not to mention the red tape associated with justifying new expenses.
In the meantime, you don’t want your users to experience extremely long page load times and latency when trying to access their content — or worse yet, dropped sessions altogether. A feature added in SharePoint 2010 and continued in SharePoint 2013 is HTTP Request Monitoring and Throttling. Servers use the settings of this feature to determine how to handle resource load on each of the SharePoint servers in the farm. Each server checks resources every five seconds to determine load, comparing the data against the defined acceptable thresholds. If a server exceeds the acceptable thresholds three times in a row, it goes into throttled mode. Web applications that have the HTTP Throttling enabled stop accepting new session requests, opting to instead deliver an HTTP 503 error, “The server is busy now. Try again later.” Meanwhile, existing sessions continue to function, ensuring that the impact of server load is as minimally disruptive as possible.
Additionally, no new timer jobs will start on that server, and any running jobs will be paused if possible. The server continues to check itself every five minutes, and remains throttled until the server resources fall back below the defined thresholds. All the throttling activity is logged to the System log in the Event Viewer. By default in SharePoint 2013, HTTP Request Monitoring and Throttling is enabled for any new web applications that are created. However, you can disable it through either PowerShell or Central Administration (covered in the following sections).
Enabling HTTP Request Monitoring and Throttling with PowerShell
To get the current values associated with HTTP Request Monitoring and Throttling via PowerShell, use the following syntax:
Get-SPWebApplicationHttpThrottlingMonitor –identity http://portal.contoso.comTo change the current settings for HTTP Request Monitoring and Throttling, use this syntax:
Set-SPWebApplicationHttpThrottlingMonitor –identity http://portal.contoso.comEnabling HTTP Request Monitoring and Throttling with Central Administration
To configure HTTP Request Monitoring and Throttling from Central Administration, follow these steps:
List-Throttling
In addition to overall server resource monitoring and throttling functionality, SharePoint 2013 helps administrators proactively limit resource consumption caused by large SharePoint list views. This is accomplished through settings that can be used to restrict queries executed against large lists. These settings are configured per web application, which provides the flexibility to choose behavior rules based on need or importance.
To configure list-throttling from Central Administration, follow these steps:
- List View Threshold — Specifies the maximum number of items that can be retrieved in a single request. The default value is 5,000; the minimum value is 2,000.
- Object Model Override — Users to whom you give appropriate permissions can override the list view threshold programmatically. The default is yes, leaving it up to the administrator to determine who has this access.
- List View Threshold for Auditors and Administrators — This setting enables a greater number of items to be queried by auditors and administrators when using the object model. Default setting is 20,000 items.
- List View Lookup Threshold — This setting specifies the maximum number of Lookup, Person/Group, or Workflow status fields that are returned in a single request. Default setting is 8.
- Daily Time Window for Large Queries — This setting specifies a time and duration during which users can execute large queries without triggering the configured thresholds. This setting is disabled by default.
- List Unique Permissions Threshold —When querying a list view, items are security trimmed to ensure that users see only what their permissions allow. When a large list also has an excessive amount of individual permissions, it takes longer to trim and return relevant results. This setting specifies the maximum number of unique permissions that an individual list can support. The default value is 50,000.
Gradual Site Deletion
In the good old days, sodas cost a dime, the talky movies cost a quarter, and you could take SharePoint down simply by deleting a web or site collection. In some rare, though not nearly rare enough, circumstances, if a web containing a lot of documents was deleted, SQL Server would lock the AllDocs table as it deleted them all. As you surely know, a locked AllDocs table makes for very sad SharePoint. As soon as that table locked, all the site collections in that content database were unavailable. As SharePoint’s adoption grew, this scenario became more and more common. Microsoft put their best and brightest minds to finding a solution. Gradual Site Delete was the silver bullet they came up with, and it’s a pretty good one.
Gradual Site Delete operates via a timer job to efficiently dispose of deleted sites with minimal impact to the server’s resources.
The Gradual Site Delete timer job, which is scoped at the Web Application level, breaks up the site deletion into smaller chunks, which are less likely to cause resource contention. The first piece that is removed is the pointer to the Site Collection from the configuration database and from the Sites table in the content database. The timer job deletes 1,000 rows at a time until the site has been completely removed. Although there isn’t any configuration that a farm administrator can change to affect how this job executes, it warrants a mention in this section to round out our discussion of making a farm more highly available.
SUMMARY
As you can tell from the size of this chapter, you have many methods for protecting SharePoint data and configuration. The types of business problems you are protecting against and the budget you have to work with will largely determine which of these techniques you make use of in your business continuity planning.
Content recovery tends to be the first and most important aspect of any backup strategy. The more end users can do for themselves in regard to using the Recycle Bin and versioning functionality, the better. In addition to entire content backups, you also looked at methods for backing up or exporting specific pieces of content such as lists, sites, and site collections.
The second area of attention for mitigating catastrophe is to make use of the high-availability support in SharePoint 2013, and related products such as SQL Server Failover Clustering and AlwaysOn Availability Groups. The scope of your high-availability solution will be largely determined by your service-level agreements and budget constraints.
Disaster recovery is something that everyone needs and hopes never to use. When all else fails, a good disaster recovery solution can save the day. Although numerous technologies and methods were discussed in this chapter, no one solution will fit every scenario. This introduction to what SharePoint 2013 has to offer should help you get started building a solid business continuity plan. Remember, the three most important parts of any business continuity plan is test, test, and test. Test restoring your backups. Test failing over your databases. Test it all. That’s the best way to build confidence in your plan, and hone your skills. The best way to get better at anything is to do it a lot.