Business Impact Assessment

The backup approach you use will ultimately be informed by the BIA because it is what determines your restore priorities. You must know your RTOs and RPOs for different content, from critical down to noncritical. This is the same as high availability in the sense that some content is more important and must be given higher resources. To understand how to back up SharePoint, you must first understand the architecture thoroughly so you can identify what you have to back up. As demonstrated in Chapter 4, this means collecting details of processes and the impact of their failure over a course of time as well as capturing interdependencies and dates/times that are particularly significant to the business. For example, the payroll site in SharePoint mainly needs to work at the end of the month, and a failure at that time will have a bigger impact than one in the middle of the month.

Some content users can quickly reproduce their content manually, or they may not ever need something again once it has been created. For example, a site used to plan a one-off event has no continued value. Business processes, however, are like IT processes: they are chains of tasks. To fully understand, capture, and back up a process, you sometimes have to ensure that the steps before SharePoint and after are also captured. Carefully backing up the payroll process may be of no value if the parts of the business process preceding it (such as capturing timesheets) or the parts after (creating payment transfers) are also not backed up. There are many dependencies that have to be taken into account in a disaster situation, not just in the planning but in the execution of the plan.

Dependencies

To successfully back up your SharePoint architecture and then successfully restore it requires a detailed understanding of all the dependencies within SharePoint required to make it work. Implicit in the need to backup/restore is the realization that your high availability tactics will eventually not be resilient enough. Data will be corrupted, hardware will fail, or some other event will mean you have to rebuild the platform from the last point you backed it up. Sometimes this may be planned: you may back up your farm to move it to another data center, for example.

In previous chapters you examined the dependencies of a disaster recovery plan, which include the following:

• Management signoff
• A BIA
• Stakeholder input on RTOs and RPOs
• Physical limitations and logistical planning

You also looked at what is required to put the DR plan into action in the context of an example organization’s broader disaster recovery planning.

• Who decides there’s actually been a disaster?
• Who deals with the disaster in general?
• Who in IT deals with the SharePoint farm disaster as distinct from the inevitable broader IT disaster?
• How will the SharePoint people know there’s been a disaster?

You have also learned some parts of the logical architecture of SharePoint, namely service applications. To back up and restore SharePoint successfully, you will need to understand these components better, as well as the parts of SharePoint included or not included in SQL Server databases. This is because the different backup options back up some things and not others.

Your core dependencies in SharePoint are the following:

• The configuration, specifically the logical architecture and service applications.
• The content stored in the form of data in SQL Server generated by the users.

If you can back up and reproduce only these things, you have the bulk of what is required to bring SharePoint back to life. But remember that SharePoint is an evolving system, and it may have evolved further functionality in the form of code—the part not included in the configuration or in SQL Server.

Code and Content

The part of the system you can’t have ready in advance as easily is the code created by developers and the content created by users that depends on that code to be present. For example, a developer could write a solution that includes creating structural elements like sites, lists, content types, and Web Parts. Restoring the content databases without restoring these code elements won’t get you far: they can’t be used until the structure they depend upon has been reinstalled as well. Reinstallation of a farm without documentation is a haphazard process at best, but asking users or developers to perfectly recall in the correct order and with all dependencies in place again is virtually impossible. As you will see, SharePoint’s built-in tools will capture code wrapped in solution packages and content in content databases, which contain the site collections users work in. This is the good news: the majority of what you have to preserve and recreate can be preserved and recreated.

If you now know you will need to back up the configuration, code, and content, how do you do it?

Backup Tools

There is a mistaken belief that the tools you choose will back up SharePoint for you. The reality is the tool only helps you back up what your users need. It can automate tasks and make them more efficient, but you choose what and when. The three main backup tools you have to choose from are

• SharePoint’s built-in backup tools (or third-party tools)
• SQL Server’s built-in backup tools (or third-party tools)
• The Windows file system’s built-in backup tools (or, most commonly, third-party tools)

Figure 6-1 shows that, for example, if you use SharePoint backup for Service Applications, it backs up some settings to files and also uses the SQL backup tool (in the overlap between the two) to back up content in SQL Server databases. However, if you only use SQL Server’s backup tools, you only capture the data in SQL Server, and in that case, the databases would have to be attached to a Service Application in the restore/DR farm. Note also that if some customizations are made to SharePoint but not through SharePoint itself, these have to be recorded and backed up separately—for example, any change to the Web.config file not made via SharePoint Central Administration.

Documentation

I will describe the tools that capture parts of a farm’s infrastructure, but there is still no substitute for good documentation. Think of documentation as the main form of backup you will rely on in the disaster situation—the tools you use to restore it are simply a means to that end. In the end, documenting what you or others have done in the process of creating and evolving the SharePoint farm will be the absolute most important thing you will need to restore it. Content databases are actually quite simple to back up. They’re just a set of tables, after all. It is the system they have to fit into that is complex and has to be thoroughly documented. When your production farm was designed, it likely had two important documents.

• Solution Architecture, which described the business requirements and the architectural decisions made to address them.
• Detailed Design, which showed the steps to implement the architecture. This would have included screenshots and tables of configuration data like server names and names of service accounts.

These documents may not exist for a number of reasons. Perhaps an external company installed SharePoint and the task of documenting the process was not included, or SharePoint simply grew from a user’s need on a server under their desk, and so no planning or documenting was done. Whatever the reason, an opportunity was lost to document how the production farm and other farms were installed and configured. What has also been lost is that perhaps this process didn’t go perfectly smoothly because of some idiosyncrasy in your network. A workaround was likely discovered but the information about it is either lost or only partly remembered. Not knowing about any pitfalls means that recreating the production environment will take longer as these workarounds will have to be rediscovered. If this documentation is available, it is very useful as you now have the first document in your disaster recovery plan. If you don’t have it, do it now! While your production farm is operational, capture as much detail as you can about how it has been set up. The main parts to capture in SharePoint are

• Server names
• Service accounts
• IIS configuration: Application pools and accounts used in them
• Service applications and how they are configured. Focus on the more complex like the User Profile Service and Search
• Other Central Administration settings such as outgoing and incoming mail servers, and how often and how large your different kinds of logs are captured
• Web application settings
• Alternate access mappings
• Network topology including DNS settings and load balancing settings
• Any delegation of rights within administration such as administering a specific service
• Any availability settings like mirroring
• Overall topology: which servers host which service application instances and proxies (more on what there are later)

As with SharePoint itself, there should also be documentation created by the network and SQL Server people in your organization for the installation of the Windows servers and their network configurations, and details of the SQL Server installation and configuration. SQL Server, for example, should have detailed documentation on how its clustering, mirroring, or log shipping were set up. This will go beyond the generic information provided by Microsoft, as it will detail the specific server names, configurations, and, to some extent, the rationale behind the configuration in terms of how it fits the needs of the business. There is generic information on the Internet for these things, but the documentation I am referring to here specifically reflects the design of your organization’s environment.

If none of this is documented, it is a serious risk to your SharePoint farm. Don’t think that the person who did the original installations will be available to do the reinstalls and that they will remember what to do. While some people do have eidetic memories (perfect recall), most of us don’t. This is why documentation of the installation and configuration of your SharePoint farm and its dependencies, Windows Server and SQL Server, is essential. If it was not done previously, it must be done now as part of your backup preparation process. Bear in mind that your production system is running and accessible now; if it fails, you won’t have the opportunity to look up its settings when you have to reproduce them.

Backup and Restore in Central Administration

Despite this caveat, the SharePoint farm backup tool in Central Administration will capture as much of SharePoint for you as any other automated tool. As you can see in Figure 6-3, it is used to back up, restore, change settings, view a history, and check the status of a current backup job. This chapter has screenshots from SharePoint 2010, and while the look of these pages has changed slightly in later versions of SharePoint they are still mainly the same.

All of the options listed in Figure 6-3 assume you have a running farm to back up or restore to. In a disaster recovery situation, if you have got back to the point where you can see this Central Administration page, you are 90% back to where you were before the disaster. Central Administration provides tools for performing individual backups of the entire farm, individual site collections, sites, libraries, or lists. A full farm backup can be restored from Central Administration, but tools are not provided for scheduling recurring backups or for restoring individual site collections, sites, libraries, or lists. These operations can be managed using PowerShell scripts. To schedule automated recurring backups, use the PowerShell cmdlets in scripts that are scheduled with the Windows Task Scheduler. I’ll talk more about PowerShell next.

Backup Using PowerShell

SharePoint itself doesn’t include a tool for scheduling backups; this is done via PowerShell. A backup can also be done via STSADM, but this tool is being slowly deprecated, so it’s recommended to use PowerShell. Furthermore, I recommend you use PowerShell rather than the options in Central Administration to perform and automate your backups because PowerShell commands can be placed within scripts that can be scheduled with the Windows Task Scheduler. The dependencies for scheduling and running PowerShell-based backups successfully are permission and path related (with thanks to Todd Klindt for these).

• Your Central Administration application pool account must have read/write access to the location of the backups.
• Your SQL Service account must have read/write access to the location of the backups.
• If you’re running a farm backup from STSADM or Windows PowerShell, the account you’re running it as must have read/write access to the location of the backups.
• The location must be accessible from the SharePoint machine the backup is running on.
• The location must be accessible from the SQL instance that SharePoint is trying to back up.
• This is why all the examples are UNCs (\servershare) and not local paths (e:ackups).

To perform a backup with PowerShell, do the following:

1. On the Start menu, click All Programs.
2. Click Microsoft SharePoint Products.
3. Click SharePoint Management Shell.
4. You use the PowerShell command Backup-SPFarm to start your backup.

    Note   For help and examples, type get-help Backup-SPFarm –examples.

5. The following script will start a full backup to e:ackup. To do so, create a new text file in Notepad and add the following line:

   Backup-SPFarm -Directory e:Backup -BackupMethod full

6. PowerShell files use the .ps1 extension, so save this file as e:ScriptsBackupSharePointFarm.ps1.
7. For security, Windows Server won’t allow PowerShell scripts to run by default. Thus, you need to adjust the Execution Policy to allow them. To do this, issue this instruction at the PowerShell command line:

   set-executionpolicy RemoteSigned

8. Next, enter the following command in the Task Scheduler as your scheduled command line action, or enter it in a batch file that you schedule to run:

   powershell -command e:ScriptsBackupSharePointFarm.ps1

9. The account on which the task runs has to have farm administrator permissions, or at least PowerShell permissions; otherwise it can’t run properly.

Speeding Up Backups

The GUI in Central Administration does have some advantages over the PowerShell commands, however. For example, backups can be made faster by increasing the number of threads used for backing up and restoring (Figure 6-4). Using the Central Administration tool doesn’t mean you can avoid all planning and thought in your backup process, however. For example, you must also specify a location for your backup. I recommend you create the backup on the machine and then copy it to the network. A backup of 600GB in SharePoint will take 6 hours, so factor in the time to do this that doesn’t clash with other operations. Another way to speed up backups is to first do a full backup and then only do subsequent differential backups. You will see these options on the “Perform a backup” page. The differential backups are faster because they only copy what’s changed, not the total farm.

Recommendation

Full backups create a new backup of the complete farm. Differential backups create a backup of all the data stored in databases that has changed since the last full backup. Naturally this means you must have first created a full backup. As well as speed, an additional advantage of a differential backup is it uses fewer resources. This is important because a backup will consume all available I/O resources until it has completed its job, so shorter is better. If you perform one full backup per week during nonpeak hours plus a differential backup every night, you will have a good balance between the two. This will depend on the amount of new content your users add. If it is a small percentage, you might only need to create a full backup monthly. If you have the option, perform the backup to a different disk than SQL Server itself. For the backup, RAID 10 is recommended, because of its fast write performance, as opposed to RAID 5, which is slow because it has to maintain parity information. For more information on choosing the appropriate RAID options for SharePoint see http://technet.microsoft.com/en-us/library/cc298801.aspx .

Transaction Logs

In SQL Server, each database has at least one data file and one transaction log file. SQL Server stores the data physically in the data file. The transaction log file stores the details of all the modifications that you perform on your SQL Server database and the details of the transactions that performed each modification. Because the transactional integrity is considered a fundamental and intrinsic characteristic of SQL Server, logging the details of the transactions can’t be turned off in SQL Server. Transaction logs are automatically backed up when you back up the farm, Web application, or databases by using either SharePoint Central Administration or Windows PowerShell.

The transaction log file is logically divided into smaller segments that are referred to as virtual log files. In SQL Server, you can configure the transaction log file to expand as needed. The transaction log expansion can be governed by the user or can be configured to use all the available disk space. This is something you will want to avoid as it will threaten the availability of your farm.

To keep your transaction logs manageable, use the following guidelines:

• Set the size of the transaction log files to a large value to avoid them expanding automatically.
• Configure the automatic expansion of transaction log files by using memory units instead of a percentage after you thoroughly evaluate the optimum memory size.

BLOBs

BLOBs (binary large objects) are used in Remote BLOB Storage (RBS). RBS is a way of storing files outside SharePoint content databases. This is done for a number of reasons.

• To save money: SQL Server storage is more expensive than using a SAN, NAS, or even a Cloud tier.
• To improve performance: Uploading or downloading to SQL Server can be slow for larger files.
• To manage data more easily: Now your storage is centralized.
• To be compliant: SEC 17a-4, for example, requires an organization to store certain account-holder documents on a specific type of compliant storage tier.

SharePoint Server backup backs up remote BLOB stores but only if you are using the FILESTREAM remote BLOB store provider to put data in remote BLOB stores. If you are using another provider, you must manually back up the remote BLOB stores.

Workflows

Workflows are a special case of customizations that you can back up and recover. The good news is that the definition data and workflow history are preserved in a SharePoint backup. The in-process workflow state is even preserved. Any SharePoint Designer workflow steps that are in the middle of a wait period during the backup will resume and complete after the backup is finished.

As Microsoft suggests, make sure that your backup and recovery plan addresses any of the following declarative or custom declarative workflow scenarios that apply to your environment. Declarative workflows, such as those that you created in Microsoft SharePoint Designer, are stored in the content database for the site collection to which they are deployed. Backing up the content database protects these workflows. Declarative simply means that parts of the workflow are prewritten, in this case by SharePoint Designer, so that everything doesn’t have to be coded from scratch.

Custom declarative workflow actions have components in the following three locations:

• The Visual Studio assemblies for the Activities are stored in the global assembly catalogue (GAC).
• The XML definition files (.ACTIONS files) are stored in the 14 (or later) TEMPLATE{LCID}Workflow directory.
• An XML entry to mark the activity as an authorized type is stored in the Web.config file for the web applications in which it is used.

If your farm workflows use custom actions, you should use a file backup system to protect these files and XML entries. Similar to SharePoint Server features such as Web Parts and event receivers, these files should be reapplied to the farm as needed after recovery.

Workflows that depend on custom code, such as those that are created by using Visual Studio, are stored in two locations. The Visual Studio assemblies for the workflow are stored in the Global Assembly Catalog (GAC), and the XML definition files are stored in the Features directory. This is the same as other kinds of SharePoint Server features such as Web Parts and event receivers. If the workflow was installed as part of a solution package, backing up the content database protects these workflows.

If you create a custom workflow that interacts with a site collection other than the one where the workflow is deployed, you must back up both site collections to protect the workflow. This includes workflows that write to a history list or other custom list in another site collection. Performing a farm backup is sufficient to back up all site collections in the farm and all workflows that are associated with them.

Workflows that are not yet deployed must be backed up and restored separately like any other data file. When you are developing a new workflow but have not yet deployed it to the SharePoint Server farm, make sure that you back up the folder where you store your workflow project files by using Windows Backup or another file system backup application.