SharePoint Disaster Recovery Planning and Key Concepts : Assessment and Planning

This is not to say that disaster recovery planning should be left entirely to business owners until the process eventually flows downstream to those with technical responsibilities. On the contrary, SharePoint technical owners can undertake numerous assessment and planning activities in advance of their involvement in the business continuity planning process. By staying involved in the planning process, SharePoint administrators can ensure that the finished product is viable from both a business and a technical perspective. Otherwise, business owners may base their decisions on incomplete or inaccurate estimates and place unmanageable burdens upon the architecture or costs of your SharePoint environment.

Finally, it is worth noting that the terms business owner and technical owner are used primarily to identify roles for planning and usage, not specific identities or groups within an organization. Information technology groups commonly find themselves in the role of SharePoint technical owner, but it is relatively common for IT to also assume the role of business owner when their own processes, data, and intellectual property are stored within a SharePoint environment. In such circumstances, it is reasonable to expect that IT employees would own SharePoint disaster recovery planning from end to end and drive it themselves. A mysterious business owner wouldn’t suddenly become involved to ensure that IT remains solely in the role of technical owner.

Discovery and Documentation

In the early stages of disaster recovery planning, the goal for SharePoint technical owners is to fully understand and document the farm or farms they’re responsible for. If the SharePoint farm isn’t yet in production or is still in the planning stages, the expected operational end state should be the target of activities. This sort of analysis and documentation is a worthwhile objective even without the context of disaster recovery planning.

Focus discovery and documentation on four key areas: logical architecture, physical deployment, configuration data, and business data.

Logical Architecture

The logical architecture model of a system describes the logical components of the system, the purpose each of the components serves, and how the components interact with one another. It is also common for a system’s logical architecture model to identify interfaces and other points of contact between the system and other resources not tied directly to the system.

Whether based strictly on SharePoint Foundation 2010 or SharePoint Server 2010, all Share-Point farms possess a number of architectural aspects that should be documented before disaster recovery planning. Among these are the following:

• Internet Information Services (IIS) application pools

• SharePoint Web applications

• Service Applications, such as Search or Business Connectivity Services (BCS)

• Zones and associated alternate access mappings

• Web application policies

• Content databases

• Site collections (including host-named site collections)

• Sites

• My Sites

SharePoint farms that are based on SharePoint Server (not SharePoint Foundation) have additional architectural aspects that must be considered in addition to those just mentioned. The specifics vary based on the edition of SharePoint Server in use, but many of the enhancements revolve around additional services and applications such as PerformancePoint Services, FAST search integration, and InfoPath Forms Services.

When documenting the logical architecture of your SharePoint farm, direct your focus primarily to the logical components that are present and how they interact with one another rather than the capture of all details associated with settings and configuration. Some amount of configuration data is typically included within the documented model to accurately describe aspects of the logical architecture, but all of the nitty-gritty configuration and setting data is best inventoried separately as part of SharePoint disaster recovery planning.

Physical Deployment

The physical deployment model of a system describes the system’s implementation across a specific set of infrastructure components and hardware. Whereas the logical architecture model of a system focuses primarily on the components of a system and how they interact, the physical deployment model of a system gets into the specifics of the environment in which the system resides and operates.

Most physical deployment models have a number of similar characteristics regardless of the system or application being documented, and SharePoint physical deployment models are no exception. Such models commonly include both the hardware that directly constitutes the Share-Point farm and any ancillary hardware that is external to the immediate farm but required for the proper overall functioning of the SharePoint environment. Commonly found elements include these:

• Physical servers that both SharePoint and SQL Server use

• Storage equipment such as storage area networks (SANs) and network-attached storage (NAS) devices

• Switches and other core networking equipment

• Wide area network (WAN) connections and other remote access links

• Firewalls that are between or touched by SharePoint servers

• Hardware load balancers, stand-alone IP address management (IPAM) devices, and other specialty equipment

• Other supporting hardware, such as Windows Active Directory (AD) domain controllers

As with the logical architecture model, you should place greater emphasis on identifying the physical components of the SharePoint farm than on capturing every configuration setting associated with the infrastructure and hardware. Some configuration and setting data is naturally included as part of the physical deployment documentation.

Configuration Data

Configuration data is any data that is required for proper operation of a system, both internally and within its implementation environment. Applications and systems use and store configuration in a variety of ways, such as via files, databases, and the Windows Registry. Typical Share-Point farms leverage numerous configuration settings and settings storage facilities. Just three examples of the many locations and facilities within SharePoint alone include these:

• Configuration, Search, and Service Application databases

• Web.config files for SharePoint Web applications

• IIS7 configuration files (formerly the IIS metabase)

You can target each of the examples listed with relative ease for automated backup operations. These items represent one type of configuration data you should capture when focusing on SharePoint disaster recovery planning. Documentation should include a description of each item, the location of the item (such as a database name or full file system path), and how the information represented by the item is used.

The second type of configuration data you must capture is data that is critical to farm operations but does not lend itself to easy targeting for backup. This can be data that is stored in multiple locations but must remain synchronized across all locations, data that is difficult to access due to its storage location or form, or even data that depends on or is stored within external systems. Two common examples of data that falls into this overall category are service accounts and passwords that are hashed prior to their storage.

Configuration data that falls into this second category does not lend itself to the same style of capture that was described for data that is easily backed up. Documentation should include the relevant information (such as service account username and password), the purpose of the information, and some indication of how the information is supplied or entered into the SharePoint environment. (The latter might be a reference to the Manage Account page within the Central Administration site where an administrator supplies the account information required to have SharePoint manage the account.)

Business Data

Whereas configuration data is information that a system uses to permit it to operate as designed, business data is information that flows through the system, is processed by the system, and is often stored by the system during the course of day-to-day operations. Business data is the data that end users care about and that normally has a dollar value attached to it during BIA activities. Business data can also be restricted by an organization’s internal policies or governed by laws such as the Sarbanes-Oxley Act of 2002 and Health Insurance Portability and Accountability Act (HIPAA).

Fortunately for disaster recovery planners, SharePoint uses a consistent and centralized storage model for the bulk of the business data it handles. Data going into SharePoint typically ends up in a SQL Server database. In the case of documents and attachments, data is commonly stored in a content database unless the content database has been configured to use a Remote Blob Storage (RBS) provider. In the absence of an RBS provider, the act of documenting content databases, their site collections, and the data that is contained within them arms you with the information you need to guide the development of a recovery strategy for documents and attachments. If you implement an RBS provider, you’ll need additional documentation steps to address the location or system this is directed toward.

In addition to content databases, SharePoint 2010 uses many Service Applications for everything from managed metadata to user profile information. These Service Applications commonly utilize SQL databases of their own for business data storage. Documenting the Service Applications that a SharePoint farm exposes and consumes, as well as the databases supporting these Service Applications, is an important step to ensure that business data doesn’t fall through the cracks.

Finally, it is worth noting that a SharePoint farm that leverages BCS within SharePoint 2010 may expose and surface business data through SharePoint that actually resides somewhere other than the SharePoint farm. The seamlessness with which external lists and external content types expose data for use can make it difficult to differentiate between SharePoint-resident data and business data residing within external lines of business systems. When documenting business data, it is imperative that you research and clearly identify the system of origin.

Dependencies and Interfaces

Judiciously documenting the four areas just discussed provides an overview of the SharePoint farm and how it operates, the environment it operates in, and how SharePoint-based data is consumed and processed. For SharePoint farms that operate independently of all other systems, this is all the information you need to prepare for the more formal process of disaster recovery design.

Unfortunately, few organizations use only SharePoint. Most organizations using SharePoint also have some combination of e-mail systems, file shares, additional line of business solutions, homegrown applications, and a whole host of additional systems too voluminous to enumerate. Realizing the value of SharePoint when used as a portal or intranet solution, many organizations go to great lengths to integrate SharePoint with these systems.

For purposes of disaster recovery planning, these external integration points represent areas that require special attention. A SharePoint farm that is restored to a fully operational state without external systems and stores it depends on is not going to be viewed as “fully operational” in the eyes of business users. When documenting the logical architecture, physical architecture, configuration data, and business data associated with a SharePoint farm, pay particular attention to interface points with other systems, stores, and services that are leveraged or represented in some form within SharePoint without actually being part of the farm themselves. Examples of such dependencies can include the following:

• Line of business systems that publish data consumed through SharePoint’s BCS functionality

• Custom user controls and Web Parts that interface with Web services exposed by other systems

• Service Applications in other farms that the target SharePoint farm consumes

• InfoPath forms that include logic to write portions of submitted form data to a non-Share-Point SQL Server database

• A simple Page Viewer Web Part that provides a browser-based view of a file share

Business users would likely judge a full restoration of the associated SharePoint farm without associated external systems as SharePoint being less than fully functional.

Identifying dependencies and interfaces with other systems goes beyond simply documenting a SharePoint farm. It requires an analysis of the purposes of a farm’s site collections, an inventory of implemented features (such as InfoPath forms and BCS connections to line of business systems), and an understanding of the operations being carried out by custom SharePoint solutions and components running within the farm. Often this process ultimately consumes more time than the documentation of the SharePoint farm. Nevertheless, the knowledge gained by the identification of these dependencies and interfaces is critical to any complete SharePoint disaster recovery plan design.