Maintaining SharePoint

In this section, we will discuss the routine activities that need to be performed in a SharePoint farm to keep it running properly. This includes installing new SharePoint releases and upgrades and performing regular backups. These are some of the least glamorous, and correspondingly most important, processes that IT professionals do every day. If all goes according to plan, the end users will never know that they are happening.

Backup and Restore Configurations and Content

Backing up data in SharePoint is just as important as backing up your e-mail or network file system. In this section, we will look at the tools and techniques supported by SharePoint to make backups of all the data within a SharePoint environment. Remember, too, that anything that is backed up may have to be restored. The planning for both scenarios goes hand in hand.

The term backup, as used in this section, refers only to data redundancy—that is, moving a copy of your critical data out of the farm so that the farm can be recovered to a known state within a known period of time if data is lost due to a failure.

Other forms of redundancy should also be considered when planning for the long-term use of any IT system. Hardware redundancy refers to having multiple servers performing the same function or having extra servers available to quick replacement in the event of hardware failures. Terms like Disaster Recovery (DR) and Business Continuity Planning (BCP) are often used inconsistently to refer to facility redundancy. A redundant facility allows the business to move operations to a different location in the event of a catastrophic failure such as a fire, earthquake, or flooding.

Hardware redundancy and facility redundancy are not directly addressed in this chapter, but a comprehensive data redundancy plan is a necessary component in any disaster recovery plan.

Recovery Requirements

When planning for backup, the requirements for recovery of lost data will drive the strategies and techniques to be used. The more aggressive the requirements are, the more the solution will cost to implement them. The requirements associated with backup can be categorized into three primary categories:

• Recovery point objective: Refers to how much data can be permanently lost in the event of a catastrophic failure. This goal is usually stated as a period of time such as one hour's, one day's, or one week's worth of data that may be lost. While it is tempting to say “We can't afford to lose ANY data!”, remember that such a requirement is all but unobtainable without massive costs. Setting a realistic objective for each type of data allows valid trade-offs to be made.
• Recovery time objective: Indicates how long the farm may be partially or completely unavailable while the recovery process is going on. Again, bringing the system back up instantly after a failure is not realistic. Restoring databases from tape or disk, reinstalling software, and rebooting and reconfiguring servers all take time no matter how well planned they are.
• Recovery granularity objective: Guides the type of restoration that may be called for. SharePoint contains many layers of data including farms, web applications, site collections, sites, lists, and list items. Using the correct tools, it is possible to restore data at any of these levels.

These recovery objectives form the most important parts of an organization's Service Level Agreement (SLA) with its users.

What Is Backed Up?

SharePoint is a more complex platform than the average e-mail or database server. It contains information in files, databases, the registry, and in proprietary stores.

Configuration information is stored at various levels and places throughout the farm. The central source of configuration data is the SharePoint configuration database in SQL Server. Each web application has its own web.config file that configures the IIS web site hosting the web application. Solution packages deployed at the farm level are also treated as configuration data as are the settings associated with the various Windows services running on the servers.

Service applications, such as Excel Services or PerformancePoint Services, are usually composed of an application configuration, a proxy configuration, and one or more databases. Depending on the service, restoring the proxy is often the most difficult because it is the item that connects the service to the rest of the farm. Be careful to plan service restorations thoroughly.

The search service is even more complex than the average service because of its distributed nature and the plethora of data repositories involved. In addition to the service assignments to servers, the search service depends on an administration databases, crawl databases, property databases, and multiple index files deployed on various servers.

SharePoint content is stored in content databases as described earlier in this chapter. In addition to sites and lists, content databases contain elements including InfoPath forms, workflows, sandboxed solutions, and certain site customizations.

While many customizations are stored in the content databases, others are not. Special care should be taken to ensure that these customizations are not left out of the recovery plan. Some of these are

• Farm solution files
• Site definitions
• XML configuration file changes
• Files deployed manually to the Global Assembly Cache (GAC), a web application's bin directory or the 14-hive directories
• Binary Large Objects (BLOBs) stored outside the content database using the Remote BLOB Storage (RBS) feature

New Features in SharePoint 2010

The 2010 release of the SharePoint platform introduced some new features that were sorely needed by administrators in previous versions. These features allow for more granular and flexible backup and restoration strategies to be implemented without the use of third-party tools.

Granular Backup and Restore

The Granular Backup feature allows an administrator to create a package that contains only a small subset of the content in a content database. This package can then be imported into another location within a SharePoint farm. This eliminates the need to back up and restore an entire content database just to retrieve one document or list item.

Unattached Content DB Export

SharePoint content databases are ordinary SQL Server databases. They are used to serve farm data only once they are attached to a web application. To recover older or misplaced content from a previously recorded backup, it is necessary to restore that backup to a SQL Server. In the past, the administrator would then be required to attach the content database to a SharePoint farm so that its content could be accessed. SharePoint 2010 now allows for data to be backed up (or exported) to a granular backup package without being in an attached content database. This prevents the other data in the content database from ever being made part of the SharePoint farm.

Backup Using a SQL Database Snapshot

Because it is possible to back up data from a detached content database, it is also possible to use a SQL Database Snapshot to better control the data being backed up. In a very busy system, it is sometimes difficult to make a consistent backup of a content database that is in constant use. Using SQL Server to create a database snapshot essentially creates a point-in-time image of the content in the database. The snapshot is a read-only representation of the database as it existed at the moment the snapshot was taken. The original database is still fully available to end users. Once the backup is completed, the snapshot can be discarded if desired.

Tools

Because of the variety of data making up a SharePoint farm, a variety of tools can be used to back up and restore some or all of this data. In this section, we will quickly describe the most commonly used tools and their pros and cons.

The Windows operating system contains its own file-based backup utility named Windows Backup. Because this tool is file-based, it should not be used for backing up SQL Server databases while SQL is running. It can be used for backing up the files that make up the SharePoint product and some of the configuration of the farm. Unfortunately, there are too many items that cannot be backed up safely, or at all, for Windows Backup to be a useful tool in a SharePoint context.

Most of SharePoint's data is housed in SQL Server databases. As such, it is tempting to use SQL Server's excellent backup tools. In many cases, such as individual content databases, this is a perfectly valid choice. However, there are configurations and files stored outside of SQL Server that are critical to restoring a complete farm configuration. While SQL Server backup is a component in a complete solution, it can never be the whole answer.

SharePoint 2010 includes its own internal backup and recovery system. When a SharePoint backup is initiated with this tool, the administrator selects how much of the farm to back up and what type of backup to perform (full, differential, or transactional). The backup is performed within SharePoint, which collects all of the configuration settings for the backed up components, along with backups of the relevant databases and files, and writes them to a directory structure in a file system on the network. These files can then be backed up to disk or tape as ordinary files. All of the control information needed to successfully restore the backup is included in the backup files.

The SharePoint backup system can be initiated using either CA or Windows PowerShell scripting. Oddly, one feature that is not a part of SharePoint's backup system is automation. There is no way to configure SharePoint to automatically back up some or all of a farm on a schedule. The recommended approach is to create PowerShell scripts for each backup action. These scripts are then scheduled to execute on a regular basis. This can be done using Windows Task Scheduler or some other task automation tool.

Finally, several vendors offer third-party SharePoint management tools. These tools can help simplify planning, automation, and recovery from failures. Microsoft's product in this category is Microsoft System Center. When dealing with backup and restoration in SharePoint, Microsoft offers the Data Protection Manager (DPM) add-on for System Center.

Software Updates and Patches

Like any piece of software, SharePoint 2010 requires the installation of regular patches and upgrades. Because a SharePoint farm consists of many services running on multiple servers and accessing various databases, installing software updates without corrupting the system or causing excessive downtime can be a challenge.

General Update Flow

Each update package received from Microsoft includes its own set of fixes and installation instructions. Always carefully review these prior to any update to a production farm. The overall process for deploying patches to a SharePoint farm is outlined in Figure 7-15.

Figure 7-15. Update process overview

The first step is to identify the updates to be deployed. Microsoft releases hotfixes and service packs with interdependencies and prerequisites. These need to be researched and understood before a deployment plan can be created. Once the outline of the steps to be followed is complete, the release should be scheduled and that schedule communicated to the end-user community.

Testing product updates is just as important as testing custom code releases. Specifically, you need to be sure to test the exact sequence of steps to ensure that any conditions unique to your environment are accounted for. The best approach is to create a test server farm that matches the production environment as closely as possible. Be sure to have at least one of each type of server (database, application, web front-end, etc.) that exists in the production farm. Place a copy of the production content databases and services on the test farm, and be sure to include any customizations that exist in production. Performing a successful upgrade on the test farm gives much greater confidence that the update will succeed in production.

Before beginning any major configuration change in a production server farm, always make sure that a complete, current set of backups is available. This will ensure that, should a problem be encountered during the update, a rollback to the previous configuration will be possible. Do not forget to practice recovering from backups from time to time. A backup that cannot be successfully restored is not a real backup.

Once the backups are in place and the update has been tested, you just need to wait for the scheduled maintenance window to actually perform the update. Bear in mind that even if you plan the update to create little or no downtime, updates should still be scheduled for a time window when unexpected problems will cause minimal disruption. We will discuss the details and strategies for managing updates in the following sections.

After the update is complete there should be a plan for verifying that the system is back up and running properly and that all services are available to the users. This plan should include verifying the patch levels in CA, ensuring that all services are running and all customizations are working as expected.

What Is Updated?

The exact updates performed when deploying a package depend on the nature of the changes being released. Service packs typically contain large numbers of updates and may require significant downtime to deploy. Hotfixes, on the other hand, generally contain one or two specific changes and can often be deployed very quickly with little or no downtime. The components updated fall into two major categories: product files and databases.

Product files can be executable files like EXEs and DLLs or support files like ASPX or XML files. These files need to be installed on each server in the farm. SharePoint 2010 updates implement the concept of backward compatibility. This means that the product files can be loaded before the final upgrading of the farm because newer files always support farms that include servers using older configurations. There are limitations to the support offered by backward compatibility, depending on the changes being made, but the concept helps to make deploying updates much simpler than in previous versions of SharePoint. As each server and component is patched, the farm administrator can verify the versions deployed using CA (Figure 7-16).

Figure 7-16. Manage Patch Status (Central Administration)

SharePoint relies on a number of SQL Server databases. Each of these databases contains tables, views, and other objects that support the storage and retrieval of information for the SharePoint farm. Each of these databases may be updated by a software update. For example, a table may need to be created or altered in one of these databases. CA can also be used to monitor upgrade processing in SharePoint's databases (Figure 7-17).

Figure 7-17. Manage Databases Upgrade Status (Central Administration)

Update Phases

Any release package will come with some instructions for installation, but the general steps involved are similar, as shown in Figure 7-18.

Figure 7-18. Software update phases

Installing software updates in a large farm happens in two phases: patching and upgrading. These phases map to the deployment of product files and the updating of database objects, respectively.

In the patch phase, the package installer is run on the servers in the farm, starting with the server hosting the CA web site. This ensures that the processes associated with CA are never running on an older version of SharePoint's executables than other servers in the farm. After CA is patched, the other servers are patched as well.

In the upgrade phase, the SharePoint 2010 Products Configuration Wizard application is run on each server to perform any remaining actions required to complete the upgrade of the farm. The most common tasks performed involve modifying one or more of SharePoint's databases, but other actions may be taken as well. The upgrade phase usually takes much longer to complete than the patch phase because of the need to update large amounts of data in some cases.

Again, always be sure to read the instructions supplied with the update package because there may be special considerations that will change the order of operations for the update process.

Strategies

The discussion up to now has given a general outline for how updates are applied. What if your environment has special needs? How much downtime can you afford? Can you commit hardware and personnel resources to reducing downtime?

SharePoint 2010 supports three main strategies for managing a software update deployment. Table 7-2 compares the pros and cons of each.

The three strategies listed trade simplicity for downtime. In the first case, a simple server-by-server installation and upgrade are performed. This requires the farm to be taken offline while the update is performed. The second scenario uses the backward compatibility concept to update the servers' software in one phase and then upgrade the farm's databases individually or in groups to limit downtime.

The final option involves creating a completely separate standby server farm that is fully operational. The production content is migrated into the standby farm, where it is upgraded, while the active farm continues serving users. The content databases in the active farm should be locked to prevent updates during the upgrade because those changes would be lost. When the update is complete, the standby farm is switched into the active position and the previous active farm becomes the standby. Obviously, this process requires a great deal of planning and hardware investments, but it has the potential to completely eliminate downtime in many situations.