Gathering requirements is definitely an art. It’s a balance between spending too little time (which ends up in a poorly designed server farm) or spending too much time, causing project delays, and going over budget. The term poorly designed, in this sense, doesn’t mean that it won’t meet the needs of the organization, but instead that it might not match the business needs but addresses issues that don’t really exist. Having a disaster recovery plan that works for everyone would be nice, but that simply isn’t the case. To get started with gathering requirements, you must know the relevant terminology. The two most important terms associated with SQL Server high availability are Recovery Time Objective (RTO) and Recovery Point Objective (RPO).

RTO is usually a number that’s heard when talking about uptime, such as 99.9 percent or something higher. Everyone wants a number that approaches 100 percent, but each 9 that’s added causes the cost to go up exponentially. The number of 9’s required depend heavily on the type of data being stored and who’s accessing it from where. SharePoint 2013 isn’t used to store transactional data, such as that stored by banks that process thousands of transactions every minute, so it doesn’t have the same requirements. However, the content stored in SharePoint is often mission critical and requires a high RTO. When figuring your RTO requirements, you need to keep the business environment in context. Consider the following important questions:

RTO can’t be determined just from a technological viewpoint. The opinions and requirements of business stakeholders also need to be taken into consideration. Also, the budget allocated to RTO must be considered. All these factors go into determining a realistic RTO.

Truly understanding RTO requires doing some math. Assuming that you’re dealing with an organization that runs 24 hours a day, seven days a week, you can do the following math:

You can easily see that even the addition of one 9 can dramatically affect the high availability of your organization. For example, an RTO of 99.99 percent doesn’t allow for the cumulative update of a server that might bring down the system. Therefore, you must have a plan that allows servers to be brought down without affecting the functionality of the system.

RPO isn’t discussed as often but is just as important during the requirement gathering phase. You must have a true understanding of the data involved to determine the RPO. When determining the RPO, you should take into consideration the following details:

This means that if an outage causes a loss of 30 minutes of data, requires an hour to come back online, and then requires 30 minutes to replace the lost data, you are looking at an RPO of 2 hours. This reflects true outage time because it calculates the amount of lost productivity.

When you gather requirements, calculating and translating the number of lost hours into a dollar amount often helps. This is simply the RPO times the number of people affected times the average salary per hour of the people affected. You can use this kind of information to help gather support for high-availability initiatives.

Understanding multi-subnet failover clustering

Multi-subnet failover clustering allows each cluster node to reside in a completely different subnet. As a result, clusters can be farther away on the network as well as geographically dispersed. Geographically dispersed clusters are often referred to as stretch clusters. Because these clusters can’t share data, a replication scenario must be enabled for the data in the cluster. Figure 1-1 shows a multi-subnet cluster.

Figure 1-1. Example of multi-subnet failover cluster

Clustering—just one of several options that enable high availability—is discussed later in this chapter. Having multiple servers in each node is possible and, depending on the configuration, SQL Server can come online as long as one IP address is available.

SQL Server mirroring provides an almost complete redundancy of the data used by SQL Server—almost because it depends on how SQL Server mirroring is configured. Another benefit is that SharePoint has fully supported database mirroring since version 2010, especially concerning content databases. Database mirroring is also fairly simple to set up and provides the following benefits:

As the benefits show, database mirroring provides a valid high-availability solution. It’s also one of the most commonly used methods of providing high availability. The main drawbacks are cost (because it requires, at minimum, another SQL Server) and disk space (because it’s a full duplicate, the storage requirements are now doubled). Assuming that you have the spare SQL Server (it doesn’t have to be dedicated to this function) and the disk space, you still need to understand some terms so that you have a better understanding of how SQL Server mirroring works:

Looking at the terminology can help you determine what’s happening in Figure 1-2. All three servers are communicating with each other, but only transaction log data is being sent from the principal server to the mirror server.

Figure 1-2. A high-safety database mirroring session with a witness

If you haven’t dealt with database mirroring before, this can seem like a lot to take in at one time, but with a little practice it will soon make sense. Before you start actually setting up a mirror, you need to consider some significant requirements for database mirroring.

Planning for a SQL Server cluster involves considerable more planning than for SQL Server mirroring. With mirroring, you can use existing SQL Server computers and choose which database or database set you want to mirror. This allows selective high availability and reduced resource requirements. With a cluster, it is all or none.

A cluster is made of two or more SQL Server nodes that act as a single SQL Server instance. Therefore, the resource requirements are the same for each cluster node, except for the data storage, which is shared among all nodes. To get a better understanding of a cluster, look at what makes up a SQL Server cluster instance:

A SQL Server failover cluster is referred to by a single name. You don’t connect to the individual servers but to the cluster instance name. On the network, the cluster appears as a single server. You must connect to the instance name rather than try to connect to a SQL Server’s IP address or machine name. Internally, one node does all the interactions with applications and synchs up the other nodes. However, any of the nodes can become the primary node.

SQL Server clustering has specific hardware requirements, especially if the clusters are geographically dispersed. Latency and network bandwidth are limitations that can cause a cluster to fail. You can make a cluster work with unapproved hardware, but doing so isn’t supported.

Storage Area Network (SAN) solutions work with SQL Server clusters, but some SAN solutions are incompatible with clustering. Check with the SAN manufacturer and with Microsoft to determine whether the available SAN solution is compatible.

AlwaysOn is the new high-availability option available with SQL Server 2012. It’s intended to provide a comprehensive disaster recovery and high-availability package to minimize downtime in organizations. AlwaysOn comes in two varieties:

Choosing which solution is best is similar to choosing between database mirroring and database clustering. The requirements are similar to their predecessors but provide additional enhancements. Because each solution is so different, this chapter looks at each one independently. AlwaysOn has had some improvements that might be significant enough to warrant an upgrade. Both AlwaysOn solutions rely on the Windows Server Failover Clustering (WSFC) infrastructure, which, combined with SQL Server, works to provide a robust high-availability platform.

AlwaysOn Failover Cluster Instances

The AlwaysOn Failover Cluster Instances (AlwaysOn FCI) technology replaces the SQL Server clustering technology available in earlier versions. As with any clustering technology, you need to consider many hardware and software issues before deploying. As with SQL Server clustering specifically, the entire instance fails over rather than just a single database or group of databases—something you need to consider when choosing a high-availability option. The following enhancements are available with SQL Server 2012 AlwaysOn failover clustering:

• Localized tempdb for improved performance

• Multi-site clustering across subnets to improve site protection (subnets are generally in the same physical location)

• Flexible failover policy

• Improved diagnostics

As with clustering, an AlwaysOn FCI relies on a single shared storage area, such as a WSFC group, a SAN, or a file share. This way, any one node can immediately take over for another node using the same set of data. Figure 1-3 shows how this can be represented.

Figure 1-3. A visual representation of how each node in a cluster uses the same shared storage

Because AlwaysOn FCI uses shared storage, this represents a potential single source of failure. The underlying storage implementation is responsible for providing data redundancy, such as mirrored disks in physically different locations. An AlwaysOn failover cluster can work with an AlwaysOn high-availability group to provide both instance and database high availability.

Important: Automatic failover

If an AlwaysOn FCI is in an AlwaysOn high-availability group with another cluster node, automatic failover isn’t supported.

An AlwaysOn FCI runs in a WSFC resource group. Every node within the cluster maintains its own synchronized copy of the configuration data and checkpoint registry keys. Only one of the nodes “owns” the resource group at any time, but any node can be the owner. In case of a failure or an upgrade, another node takes over ownership. Failure can be the result of hardware failure, operating system failure, or an application. The SQL Server binaries are stored locally on each node for improved performance, but the services are managed by the WSFC and not started automatically.

A virtual network name (VNN) for the entire node provides a single connection point for applications to connect to the cluster. The VNN points to a single node in the cluster. In the case of a failover, the VNN points to a new node. The application is unaware of a node failure, and no modification is required on the client application for continued uptime.

AlwaysOn failover clustering can use multiple subnets for its nodes. Because a single IP address is required to provide unattended failover, a virtual IP address needs to be assigned to each subnet in the failover cluster. During a subnet failure, the VNN is updated in the DNS to point to the new subnet. Clients require no changes to point to the new subnet, but a slight amount of downtime will occur depending on the DNS configuration.

More Info: AlwaysOn Failover Cluster Instances

See http://technet.microsoft.com/en-us/library/ms189134(v=SQL.110) for more information on AlwaysOn FCIs.

SQL Server log shipping can be confused with database mirroring because both have similar functionality: The data from a primary server is sent to one or more secondary servers. Before looking at using SQL Server log shipping, you should look at the primary differences:

Here, you can see that the main points of concern in high availability are the necessity for a manual change of roles and the amount of time required for the secondary server to become the primary.

Because database mirroring and log shipping are so similar, knowing the terminology is important so that you can distinguish between the two. The following terms are used when discussing log shipping:

You can always use log shipping to provide an additional copy of a database. If any databases need to be archived periodically, need a very high level of disaster recovery, or require remote read-only access, log shipping is an excellent option because it’s relatively easy to set up compared to the AlwaysOn options. Before configuring log shipping, however, make sure that the following prerequisites are met:

To get a better understanding of high-availability options, look at the steps on how to configure log shipping. You could use T-SQL to configure log shipping, but the following steps show only the method available via SQL Server Management Studio:

Failing over to a secondary database isn’t as straightforward in log shipping as it is in database mirroring or one of the AlwaysOn technologies because of the time lag between the primary and secondary servers synching. Typically, the secondary database needs to be synchronized with the latest transaction logs before it assumes the duties of the primary server (unless a logical error occurs in which part of the database is corrupt and getting an earlier version of the data is necessary). Some transaction logs might not have even been copied to the secondary server and will need to be recopied (if possible). Failing over requires some additional manual steps, as follows:

Figuring out when logical errors occurred in the database requires some effort. As long as a backup and the transaction logs are available, getting to a point before the logical error occurred should be possible. This is an important component in many disaster recovery plans because it minimizes the amount of lost data.

Data redundancy is a cornerstone of any disaster recovery center. The amount of redundancy planning required depends on the data’s importance, the budget allowed, and the speed at which the data must be recovered. A multitude of disasters can occur, such as the following real-world examples:

Data redundancy can help prevent a disaster from turning into a catastrophe, in which the data is permanently destroyed. Several methods are available for providing storage redundancy. This chapter goes over some of the most common methods, but any storage plan requires a large amount of resources to provide true data redundancy.

Logins aren’t replicated with the data unless the entire SQL Server instance is replicated. In the cases of database mirroring, log shipping and AlwaysOn high-availability group replication doesn’t provide the SharePoint logins necessary for a successful failover. If a large number of servers are involved, maintaining the necessary logins can become a challenge. Even maintaining consistent logins between two servers can prove to be difficult. Nothing is more frustrating than performing an emergency failover and not having the logins in place to make the SharePoint instance function correctly. This isn’t an issue with SQL Server clustering and AlwaysOn FCI because every node in the cluster is a copy of the whole server, not just the databases involved in replication.

You can create a script of SQL Server logins on the primary server and then run it on all secondary servers (mirror, secondary server, or member of an AlwaysOn high-availability group). Because scripting logins is a fairly involved process, you need to take great care when creating a script because different versions of SQL Server need slightly different scripts. Also, any errors in the script can result in a non-functional failover database. To test the logins properly on the secondary database, you need to initiate a manual failover.

Answer the following questions to test your knowledge of the information in this objective. You can find the answers to these questions and explanations of why each answer choice is correct or incorrect in the “Answers” section at the end of this chapter.

Unless you are dealing with a very small server farm, you need to distribute SharePoint services across several servers for performance as well as consider high availability. SharePoint has many different services roles that you can distribute across servers. Any SharePoint server can assume any of the roles with some configuration changes, giving SharePoint the ability to be an extremely robust and highly available system if it’s configured correctly. A SharePoint server can provide these kinds of services:

Figure 1-6 shows how the services fit together and connect to SQL Server. Note that each service can have several servers—for example, a SharePoint 2013 farm could have five WFEs, three search servers, and two application servers. The number of different configurations depends totally on the resources available and the demands of your particular SharePoint environment.

Figure 1-6. How each SharePoint Service connects with the database as well as the WFE

Search server

A SharePoint Search server crawls and indexes SharePoint content as well as returns query requests. These tasks don’t all have to reside on the same server, and depending on how much content is being indexed, one search server might not be able to handle all the search functions. Separating the search server from the WFE provides the single biggest performance improvement (in a farm that has SQL Server on a separate server); otherwise, putting SQL Server on its own server would provide the biggest improvement. The search server is made up of a number of components that can be distributed across multiple servers to provide high availability:

• Crawl component crawls content (SharePoint or other content such as websites or file shares) and extracts crawled properties and metadata to send to the content processing component.

• Content processing component receives information from the crawl component, and then processes and sends it to the indexing component. It also interacts with the analytics processing component and is responsible for mapping crawled properties to managed properties.

• Indexing component receives information from the content processing component and writes it to the index. It also handles queries and sends back results to the Query processing component.

• Query processing component handles incoming query requests and sends them to indexing component for results. It also handles optimization of queries.

• Analytics processing component analyzes what users are querying on and how they interact with the results. This information is used to determine relevance, generate recommendations, and generate search reports.

• Search administration component manages administrative processes as well as changes to the search topology, such as adding or removing search components and servers.

You can distribute the search service components across multiple servers to provide high availability as well as improve performance. The Search Application Topology page in Central Administration shows which components are running on which servers (see Figure 1-7).

Figure 1-7. Each search component running on the server named SP13

The importance of each component varies in how it relates to high availability. Even if all search components were non-functional, SharePoint would still serve up content through the WFE. Of course, when a user tries to do a search, it comes back as the search service being unavailable, depending on which services are down. For example, the crawling component could be unavailable, but search would still return results; those results just become out of date until the crawling component is restored. To determine the high-availability plan for search services, you must first define what the high-availability goals are.

A SharePoint Server can handle one or more service instances. Typically, the services moved from the WFE are the search service and application services such as Excel Services, but any service can be moved from the primary SharePoint instance. Generally speaking, search will be the most resource-intensive service to be considered for separation from the primary SharePoint server.

To configure the services available on a particular SharePoint 2013 server, follow these steps:

Figure 1-8. Part of the Services On Server page, showing some of the services that can be started or stopped

The distribution of search services and application services depends on the organization’s individual business requirements. A properly prepared high-availability plan allows for redistribution of services depending on the analysis of server demand. You can always add another SharePoint server in the future to offload demand, but many physical and financial requirements need to be taken into consideration during the planning stages. For example, if the server room has no space to add another SharePoint server, that should be noted in the high-availability plan.

Physical distribution of servers occurs for two primary reasons:

During the planning phase, you can do the following to prepare for disaster recovery and plan for performance:

When you’re planning for physical server distribution, taking a look at the underlying physical storage of data is important. Data is typically stored on a Redundant Array of Inexpensive Disks (RAID) or Storage Area Network (SAN). These two technologies represent the vast majority of disk configurations used in high-availability systems. The configuration of these technologies can greatly affect the high availability of the SharePoint farm (as well as the SQL Server implementation). To better understand how these technologies affect the SharePoint implementation, take a deeper look into how each one of them works.

Network redundancy means that communication pathways exist, even if a particular link goes down. Because many real-world examples are known of when links go down, planning for them can help keep the SharePoint farm up and running. The following are examples of issues that arise where network redundancy is necessary to maintain service:

The exam doesn’t expect you to be a certified network engineer, but you should be aware of these issues and how to plan for them. You should also be prepared to offer suggestions on how network redundancy can help to improve the overall uptime of the SharePoint farm. Many technologies are available to help improve network redundancy, but most of them are beyond the scope of this book. However, one that falls within the realm of this exam is Network Load Balancing (NLB).

NLB is most often discussed when WFEs are discussed. With this method, a single IP address or vanity URL can be used to connect to a set of WFEs (a user connects to only one server at a time, no matter which server). Noting that Central Administration can also be load balanced is important, although it’s typically installed on only one server (best practices are that it’s running on more than one SharePoint server even if it’s not load balanced). NLB is configured outside of SharePoint on each server in the NLB group.

Because NLB operates at the network driver level, the TCP/IP stack isn’t aware of it. Figure 1-9 shows how the communication layers are stacked to help get a better understanding of how the layers communicate with each other.

Figure 1-9. Communication stack showing how NLB sits below TCP/IP, indicating that the WFE isn’t aware of it

Figure 1-9 clearly shows that the WFEs aren’t aware of the network load balancing occurring because items in the stack are aware only of layers immediately below or immediately above.

Now that you have a graphical understanding of how NLB works in the communication stack, you can focus on how it’s implemented from a practical standpoint. The following steps, for Windows Server 2008 R2, show how to configure NLB:

NLB must be installed on every server that’s part of the NLB cluster before it’s added to via the Network Load Balancing Manager tool. After NLB is configured, if an individual server goes down, the load is automatically redistributed among the remaining servers. NLB determines whether a server is up via a “heartbeat” that each server sends out. If the Network Load Balance Manager doesn’t receive a “heartbeat” for 5 seconds (by default), it assumes that the server is unresponsive and routes requests to the other servers in the NLB cluster. This is referred to as a convergence, and the server with the lowest priority number takes over as the default. If the server that was down (unresponsive heartbeat) comes back online during the convergence, it becomes part of the group. If it doesn’t, it must be added back in via the NLB Manager tool. The convergence takes only a few seconds, so the total outage (assuming that a user was accessing the downed server) should be about 7–10 seconds. For other users, the cluster is down for only a few seconds.

You can add or remove a server from the NLB cluster at any time. This greatly improves uptime of the SharePoint server farm and allows for maintenance of servers with minimal downtime. NLB provides a number of additional features in Windows Server 2008 R2, including the following:

Using SQL Server load balancing with Active/Active clustering isn’t supported. Active/Active refers to two separate SQL Server instances using each other as failovers. This is different in that a single SQL Server instance uses one or more cluster nodes as failovers in case the primary node fails. Database mirroring or AlwaysOn high availability still relies on a single SQL Server instance to receive transactions and then push them out to secondary servers so that both methods rely on a single SQL Server instance to interact with for transactions. Log shipping also has a single server as a bottleneck for inputs because the secondary servers only receive content and can’t be used for write transactions unless a failover is initiated. Even if clustering is set up, it still relies on a single server to receive the transactions and then replicate them to the other servers.

Planning for SQL Server load balancing is an advanced topic and requires considerable planning and resources. Generally, giving the primary SQL Server node more memory and network bandwidth resources gives more of a benefit than trying to load balance several SQL Server instances. One option for balancing some of the load is to use linked servers. This allows for a database that resides on one SQL Server instance to appear as it is on another SQL Server instance. The following section describes this option in more detail.

A SQL Server alias allows for SharePoint to switch from one SQL Server instance to another should a disaster occur. SharePoint does this by connecting to the alias rather than directly to the SQL Server instance. If that SQL Server instance goes down, SharePoint can be pointed to a mirrored instance and be back up by just changing the details of the alias.

You can create a SQL Server alias in just a few steps. The following steps create an alias on a SharePoint 2013 server with Microsoft SQL Server 2012 client connectivity components installed on it:

After you configure each the SharePoint 2013 server with the appropriate alias, you can install the SharePoint 2013 farm. Where it asks for the database server, enter the alias rather than the actual server name. If you’ve already installed your SharePoint farm, you need to run the SharePoint Products Configuration Wizard and choose Disconnect From This Server Farm on the Modify Server Farm Settings page. After you disconnect, you can rerun the SharePoint Products Configuration Wizard and connect to an existing SharePoint farm by using the alias instead. Clicking Retrieve Database Names should bring back the existing configuration database. You also need to supply the farm passphrase and a port number (or use the one that’s generated). Finally, all respective SharePoint services need to be restarted.

If the SQL Server Configuration Management client tools aren’t available on the SharePoint server, you can create an alias using the SQL Server Client Network Utility as follows:

When these steps are complete, the aliases are complete and a farm can be installed or reconnected as described earlier.

If you’re using database mirroring, AlwaysOn High Availability Groups, or log shipping, you should install SharePoint using a SQL Server alias to enable switching to a new SQL Server instance. The only high-availability options that don’t benefit from an alias are database clustering and AlwaysOn Failover Cluster Instances. This is because if one node goes down in a cluster, another node takes over, but the SQL Server instance name stays the same. This doesn’t prohibit an alias from being used in a clustering environment; in fact, it’s encouraged in case the cluster itself fails and a backup needs to be restored to a new SQL Server while the cluster is restored.

Answer the following questions to test your knowledge of the information in this objective. You can find the answers to these questions and explanations of why each answer choice is correct or incorrect in the “Answers” section at the end of this chapter.

SharePoint needs to be backed up independently of SQL Server. You can back up SharePoint in a couple different ways, but to understand what a SharePoint backup versus a SQL Server backup means, you need to look at the SharePoint components that need to be backed up:

The farm configuration is stored in the central administration database but should also be backed up independently of the normal SQL Server backups. This provides several benefits, including marking a farm configuration as a “golden” copy so that if corruption happens to the configuration, you’re not trying to figure out when the last uncorrupted copy was backed up. Also, the backup can be kept local, which makes restoration easier for the SharePoint administrator. In many organizations, the person responsible for the SharePoint farm doesn’t have the rights (and perhaps training required) to restore a SQL Server database. A SharePoint farm backup allows that person to restore a farm configuration independently.

When deciding on a schedule, the recovery model is important to consider. By default, SharePoint content databases have the full recovery model, which provides a greater level of recovery but takes up more hard drive space. To better understand the recovery model, look at the options in Table 1-1.

Most databases use either the Simple or Full recovery model. If you are using the Simple recovery model, backing up the data more frequently is important so that the amount of data lost is minimized. The main issue with the Simple recovery model is that it’s not available if high-availability options such as database mirroring or AlwaysOn High Availability Groups are being used.

The primary tool used to back up a SharePoint 2103 farm is the Backup Tool available in Central Administration. You can use this easy-to-use graphical interface tool to back up the farm configuration as well as well as content databases. This tool has several types of backup types available:

Central Administration backup provides a simple interface, but you need to consider some exceptions when using it. Although it’s a great tool to use to back up farm configuration information, it should be used with caution as part of your content database backup strategy. Central Administration Backup can write to only a file location, not to tape, so enough file space must be available to handle the backup. Because it doesn’t automatically get rid of old backups, they can add up quickly, depending on the type of backup. Finally, Central Administration has no built-in way to schedule backups. The only reason to use Central Administration Backup for content databases would be for archiving purposes. However, it’s a valid backup strategy for having a locally available backup of the configuration data.

Configuration-only backups will be the primary function of the Central Administration Backup tool because no other built-in tool provides backups of configuration data with such completeness. This doesn’t mean that it backs up all the configuration information necessary to restore a SharePoint server. Several important items aren’t backed up by the Backup tool:

These settings should be backed up separately for each server in the SharePoint farm.

Backing up just the SharePoint configuration is straightforward with the Central Administration user interface. Follow these steps:

SharePoint creates a folder in the backup location (such as spbr0000) each time a backup is performed. When you do a restore, you need to know which folder to choose to restore the proper backup. In the specified backup folder is a spbrtoc.xml file that specifies the backups available and when they occurred. Within each backup folder are two files that explain the contents of the folder—spbackup.log and spbackup.xml—in case you need to examine the contents of what was backed up.

You can also use PowerShell to perform SharePoint backups in a similar way as Central Administration because it provides the equivalent functionality. It’s useful if you will be repeating the same type of backup or if you plan to automate any backup function. Being familiar with the syntax of the PowerShell backup commands is important:

Backup-SPFarm -BackupMethod <Full|Differential> -Directory <UNC Path> [-Configuration
Only] [-Force] [-Item <named component>]

If you save scripts that you use regularly, you can run them whenever needed rather than have to rewrite them every single time.

SharePoint also provides an object model that programmers can use to perform backups. This will be more involved than would benefit most organizations, but it’s available for more complex farm implementations as well as third-party organizations that want to develop tools to provide comprehensive backup solutions.

A SharePoint backup schedule varies from a SQL server backup schedule. It should be driven by change, not by time. Whenever a significant environmental change occurs, you should perform a backup. Sometimes this might happen multiple times in a day, and sometimes weeks or months might pass without a need to back up SharePoint. This means that a manual process must be involved to start the backup process.

The following are some examples of when a full SharePoint backup should be performed:

These backups can’t be scheduled and should be performed by a SharePoint administrator. A snapshot of the server provides additional protection if you are using a virtual machine (VM); a backup of the entire server via disk or tape if you aren’t using a VM provides additional protection and options for recovery. These backups do require significantly more resources than just backing up the pertinent information required for SharePoint.

A scheduled backup of the farm is also a good idea and should be part of high-availability planning. Central Administration doesn’t allow for scheduled backups, so you need to use another method. For example, you can create a PowerShell script and then set up a Windows timer job to automate it.

SQL Server is where SharePoint stores the bulk of the content that needs to be backed up. If you can recover a content database, you can build a new SharePoint server and attach to it, thus recovering the data within. Determining a SQL Server backup depends on a number of factors, including some that will be out of your hands but must still be considered:

A typical scenario would be doing a full backup once a week and doing a differential every day during the week. This scenario would generally be used in an environment that backs up the databases to tape or to a shared storage area such as a SAN. (Tape has the benefit of being cheaper, but a SAN provides a quicker recovery time.) As part of the backup schedule, the service level agreement (SLA) should be determined. Using differentials saves money but requires more time to restore because the most recent full backup must be restored before you can restore a differential.

If a VM is being used for SQL Server, backups of the individual content databases should still be used because restoring a single content database from a VM is impossible. The backup VM could be used to bring up a temporary instance, and then a single content database could be saved from it and restored to the production database.

An up-to-date reproduction of your production environment is a great asset in development and testing. Every cumulative update and service pack should be tested in a non-production environment that matches as closely as possible the production environment. In many situations, however, this is prohibitively expensive. Not every single SharePoint server in the production farm needs to be reproduced in the non-production environment, but if at all possible, the reproduction should include all the production environment content. This is to allow for an environment that’s as close to the real thing as possible without having a perfect replica.

If you are dealing with VMs, the process is much easier than if you are dealing with physical servers. You can simply take a snapshot of the servers involved and copy them over into the non-production environment replacing any out of date servers.

A non-production environment consists of at least the following items:

With these three items, you can create a non-production environment with a high degree of certainty that your solutions, cumulative updates, or service packs behave similarly to the production environment.

Keeping content refreshed is tricky if development is being done in the non-production environment (as is typical). Often, development is being stored in the content database. Items such as all client-side scripts, changes to master pages, workflows created out of the box (OTB) or with SharePoint Designer, changes to .aspx pages, and so on are all stored in the content database. A simple database restore would wipe all this work out unless everything had been re-created in the production environment before the content refresh. In these situations, determining how and when to refresh the content is up to the individual organization.

If you want a non-production environment with almost current (depending on the frequency of the updates but potentially less than an hour old) data all the time, you can use Content Deployment. SharePoint provides Content Deployment OTB. This can be used to keep a non-production environment current with scheduled data. Content Deployment can found in Central Administration or can be run via PowerShell or the SharePoint object model. For the purposes of the exam, this book focuses on the Central Administration method. Later, this book explores in detail the content deployment methods and configuration.

Earlier, this chapter went over how to back up a farm configuration. Assuming that you backed up your configuration at that time, you can now recover it. Some settings have to be recovered manually, but you can start with recovering the farm configuration by using the built-in configuration restoration method in Central Administration. Because the Central Administration restore method uses a graphical UI that presents a visual representation of what’s being restored, you will less likely restore something unintended.

A configuration backup must be done from a full backup and not a differential. (A differential backup is applicable only to content databases.) To better understand the process, you need to look at the steps involved:

You can use Central Administration to back up components. If you need to be able to recover an application, you should have backed them up as described earlier in this objective. If you have done a full farm backup, you can simply choose an individual component to restore (such as Excel Services) from the entire backup. Ensuring that you have backed-up settings since any major changes to a service application were made is important. If you have a current backup, the restoration process is fairly straightforward via Central Administration. Even if you back up service applications, you should store in a location that’s not in SharePoint a documented list of which services are on which servers.

Central Administration provides individual component backup. For example, if you want to back up only the Machine Translation services, you could use the OTB backup-and-restore services to back up just this one component so that it can be recovered quickly. For the purposes of illustration, the following steps restore a single service application, a previously backed-up instance of the InfoPath Services:

Several viable options are available for recovering content. Each one has its pros and cons, but they can all provide a full recovery of all the content from a content database. This section covers the following options:

Backing up a content database with SQL Server or backup-and-restore products such as Data Protection Manager (DPM) by Microsoft is a standard disaster-recovery protocol. When a restore is required, you can restore over the existing content database, in which case everything that has been changed since the backup is lost, or you can restore to a new database, in which case you can look at the backed-up data and choose what you want to recover. This feature is extremely useful if you just want to recover certain parts of the content database, such as a corrupted site or list.

Recovering a specific list or document library is best done using additional software because a list or document library template is limited to 25 MB by default. DPM enables you to back up and restore individual libraries and lists. If a library or list is below the limit, a list or library can be saved as a template (with content) to a temporary location by going through the galleries section of the site collection settings page. When it’s saved to the temporary location, you can upload it to the production SharePoint farm and restore it in the proper location. If a library or list exceeds the SharePoint specified limit, another product needs to be used, such as Microsoft DPM.

Restore-SPSite [-Identity] <String> -Path <String> [-AssignmentCollection
<SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-ContentDatabase
<SPContentDatabasePipeBind>] [-Force <SwitchParameter>] [-GradualDelete
<SwitchParameter>] [-HostHeaderWebApplication <String>] [-WhatIf [<SwitchParameter>]]

Mount-SPContentDatabase [-Name] <String> [-WebApplication] <SPWebApplicationPipeBind>
[-AssignNewDatabaseId]

Mount-SPContentDatabase "Contoso Sales" -WebApplication http://contoso/sales
-AssignNewDatabaseId

Get-SPContentDatabase –ConnectAsUnattachedDatabase -DatabaseName <DatabaseName>
-DatabaseServer <DatabaseServer>

Answer the following questions to test your knowledge of the information in this objective. You can find the answers to these questions and explanations of why each answer choice is correct or incorrect in the “Answers” section at the end of this chapter.

In this scenario, database mirroring provides the best option. It provides high availability, and the 5 minute failover is well within the amount of time needed to fail over to the secondary database. Using AlwaysOn High Availability Groups isn’t a good solution because SQL Server 2008 R2 is the available server and, based on the training and version, isn’t a viable option. Clustering isn’t an option because it doesn’t provide high availability of the content databases, and log shipping isn’t a good option due to the amount of time it takes to manually move over to a new database.

You need to deal with two issues in this thought experiment. The first is how to distribute the load across multiple WFEs. Network Load Balancing (NLB) is an excellent choice for this because it not only provides a way to distribute the processing load across several servers, but it also automatically detects when a Windows Internet Name Service (WINS) server becomes unavailable. This solves both the primary and secondary goals of the WFE requirement. The database failover goal can be solved by using SQL Server aliases. Because you know that SQL Server is being mirrored, you can modify the alias to point to the secondary or WINS server if the primary goes down or has been brought down for maintenance. Therefore, the combination of NLB and SQL Server aliases should provide a solution that meets the business goals outlined.

In this scenario, you are presented with a difficult decision. Because the SQL Server high-availability plan is out of your hands, you have only the choice of which recovery model to use for the SharePoint farm content databases. Clusters aren’t aware of what recovery model individual databases use, so the only factor involved is how much disk space is being used and if point-in-time recovery is required. Because point-in-time recovery wasn’t specified as a requirement, you can use the Simple recovery model to save space because the logs are truncated every time the database is fully backed up. Alerting the people involved that point-in-time recovery isn’t possible in this scenario is always prudent. This is based on using SQL Server backups and not a third-party backup process.