Developing a Best Practices Approach for Disaster Recovery for SharePoint 2013 – Part 1
When developing a disaster recovery (DR) and business continuity management (BCM) strategy for your organization’s SharePoint 2013 platform there are many different factors that must be taken into consideration as well as existing DR strategies your organization may already have in place.
These factors can differ based on the business vertical your organization is in which can add external factors around legal and regulatory compliance as well as how IT and the business view the criticality of the SharePoint platform and whether or not it is mission critical.
In most cases, SharePoint is viewed as one of the most business critical platforms in the organization and the DR and business continuity management (BCM) service level agreements (SLAs) are or should be very strict in regards to response time of an incident.
Other elements to consider is the damage to SharePoint’s reputation within the organization as a trusted system for which users can depend on in storing content and records and their view of its future reliability. This is critical because you do not want users going against governance policies and storing content in other locations because they have lost faith in the platform due to lengthy downtime or lost data.
There must be clear direction and an accurate inventory regarding SharePoint’s farm level restoration which should also encompass the possibility of a catastrophic loss of the SharePoint Server 2013 environment as well as loss of any hybrid connectivity in case of a cloud-based outage.
Your organization must develop clear documentation and processes that include the full scope of the records of all files, databases, and configurations necessary to return content and services to business-critical operation.
Documenting Your Organization’s SharePoint 2013 Platform
The direction and procedures described in this EPC Group blog post are organized into the following structure to assist you in developing tailored documentation for your organization SharePoint platform as follows:
- Preparation for SharePoint 2013 DR \ BCM
- Inventory of SharePoint 2013 and Related Components
- Backup of SharePoint 2013 and Related Content and Components
Preparation for SharePoint 2013 Disaster Recovery (DR) \ BCM
Preparation describes the key areas and components of a SharePoint Server farm and outlines the critical items the responsible parties within your organization must protect through proper inventory and backup procedures to provide as complete a restoration as possible.
Failure to itemize and backup any of these components or configurations may result in an inability to return expected levels of service and data availability.
Because a SharePoint 2013 platform consists of servers, services, and content, each component represents a critical aspect of the ability to provide a fully functioning SharePoint farm.
Even if your organization has deployed a relatively small SharePoint environment, the following sections and related components are just as vital to those of a large enterprise environments to ensure proper functionality and restoration of the organization SharePoint platform. These components include:
- SharePoint databases, including all content databases and Shared Services Provider (SSP) databases
- Customizations, including web parts, apps, site and list definitions, master pages, style sheets and features
- SharePoint configurations, including farm configuration databases, alternate access mappings, email settings and service accounts
- SharePoint binaries, including software, service packs and cumulative updates and hotfixes,
- Internet Information Services (IIS) configurations, including IIS metabase and Inetpub directories
- Operating System binaries, including OS, hardware drivers, software updates and server components
The SharePoint specific content that needs to be addressed will usually be the bulk of the backup and restore operations. SharePoint content includes all content found in the content databases, such as the site collection and all included sites, documents and list items, and even security, configurations, and associations.
The content database is by far the most important element of a SharePoint Disaster Recovery (DR) scenario but certainly not the only item that is required for some disaster recover scenarios.
In particular, the content databases will help restore:
- Entire site collections
- Any subsite in any site collection
- Any document library or list in any site in a site collection
- Web parts in web pages
- Site and list level configurations
- Security and user Information
For scenarios requiring the restoration of any of these items, the content database is required. However, be aware that some items, such as security or web parts, require entire site or in some cases entire site collection restores to gain access this information.
Elements related to how SharePoint provides and controls access to any contained content is handled through the web infrastructure portion of the logical architecture of a SharePoint farm. Web applications, authentication providers, application policies and other web-related items are required to properly restore a web infrastructure that interfaces with SharePoint.
A SharePoint content database is attached directly to a web application and is therefore accessed through the web application itself. Failure to have an accessible web application or have a web application with an incorrect configuration, may result in SharePoint content being inaccessible.
In addition, since web applications are web sites in Internet Information Services (IIS), physical files and file locations are also necessary to record and maintain.
Web Infrastructure elements include:
- Web Applications
- Web Application Settings
- General Settings
- Activated Features
- Associated Content Databases
- Alternate Access Mappings
- Authentication Providers
- Web Application Policies
IIS related elements include:
- Host Headers and/or Port Numbers
- SSL or Anonymous Access configuration
- Application Pool and Associated Application Pool ID \ Inetpub folder
- SSL Certificates
- Web.config customizations
Aside from content, SharePoint also utilizes a number of services that are managed within or through SharePoint and are connected and shared to all web infrastructure components of SharePoint, in particular web applications. Also, if you have SharePoint 2013 as well as a previous version of SharePoint installed such as SharePoint 2010, this may be managed through a Shared Service Provider or a Service Application.
A Shared Service Provider has associated web applications, service accounts, administration host sites, and service and content databases. All of these items need to be recorded and preserved to provide the unique information provided by the Shared Service to return the environment to a functioning, usable system.
Components of a Shared Service Provider include:
- Application Host
- Associated Web Applications
- Service and Content Databases
- Service Accounts
Each Shared Service may have its own set of configurations and may be necessary to be recorded to maintain functioning service for your organization’s SharePoint platform. However, protecting or recording the entirety of a Shared Service Provider can provide enough information to recreate one if it fails for any reason.
A Service Application is a later architecture supported by SharePoint that has similarities and differences to a Shared Service Provider. Similar to Shared Service Providers, a Service Application provides a specific service component for consumption by the entire Farm, and some types of services can be shared with other Farms.
Unlike Shared Services, the Service Application architecture is not monolithic and defines separate services rather than groups of services and thus multiple associations may be made to one Service Application, multiple Service Applications of the same type may be defined, and multiple cross-associations, including those of other Farms can be configured.
Components for Service Applications are identical to a Shared Service Provider, except that they are only used for specific Service Applications rather than groups of Service Applications.
Support Systems and Configurations
As you know, SharePoint requires the Windows Server Operating System (OS) to function as it is not a standalone system. As mentioned previously, IIS is leveraged from Windows Server to support the system function. Access accounts, also referred to as Service Accounts, are provided through Active Directory (AD) and are used for many cross-farm services and functions.
However, within all of this, SharePoint still requires its own binary installation files, which may also include hotfixes, cumulative updates, or service packs. Each of these layers of the support systems is required to return a failed installation or an entire SharePoint Farm if necessary. Furthermore, additional third-party applications that extend and enhance SharePoint functionality should also be considered and recorded.
The Support systems include:
- Windows OS version and all applied patches and updates
- SharePoint Farm Build Version for patches and updates
- SharePoint installation media and license keys
- Active Directory Service Accounts and passwords
- Setup/Admin Accounts
- Database Access Account (Farm Account)
- Application Pool Accounts (Content, Central Admin, SSPs)
- Farm Search Service Account(s)
- Default Content Access Account (Note: This may be the same as the Farm Search Service Account.)
- Third-Party applications | Custom or third-party solution (.wsp) files
This is part 1 of EPC Group’s “Developing a Best Practices Approach for Disaster Recover for SharePoint 2013 –From the Consulting Trenches“