Have you successfully test-restored your SharePoint farm from backup? Do you even complete quarterly disaster recovery (DR) drills? If yes, then please do not read on.

 

The rest of you have probably experienced that SharePoint backup and disaster recovery are not as straightforward as one would think. The problem here is that SharePoint disaster protection is often regarded as just another task for the IT department, like backing up Exchange, SQL Server or the corporate file shares.

 

Unfortunately, it is not that simple, as SharePoint consists of numerous components that are spread across multiple servers. Simply backing up the content databases can lead not only to the loss of important data, but also to very long RTOs (Restore Time Objectives). In the worst case, the backed up database will not re-attach to the disaster recovery farm and your stakeholders will breathe down your neck, as they scream for their documents back.

 

Let's take a step back and take a look at what is involved with backing up SharePoint. Here are the components that we need to protect:

 

a) Content databases located in SQL Server

 

b) Configuration database, also located in SQL Server

 

c) All custom code installed to the 12 (SharePoint 2007) or 14 (SharePoint 2010) hive

 

d) All libraries registered in the GAC (Global Access Cache)

 

e) The web.config

 

f) Service applications (SharePoint 2010) or Shared Services Provider (SharePoint 2007)

 

g) Timer jobs and console applications installed on the server

 

h) IIS configuration

 

i) Ideally, we'd also protect the search index, as it might take days to re-crawl all data sources

 

j) If applicable: MS Project or Team Foundation Server databases

 

The above list shows that SharePoint disaster protection is not as simple as it first appears. To reach your RTO (Restore Time Objective), RPO (Restore Point Objective) and RLO (Restore Level Objective), thorough planning and testing are needed. It is essential to have the entire DR process documented and tested, as your organization should be able to restore its data independently of key staff members leaving. In the ideal case, we recommend basic test-restores every month and full SharePoint DR drills once per quarter. The more your organization entrusts its documents and business processes to SharePoint, the more important these test runs become.

 

 

The most significant shortcoming of backups through SharePoint Central Admin is that they cannot be scheduled. Therefore, Central Admin backups are only useful for ad-hoc tasks, like taking a backup that will be restored to the staging or development environment. Also, please note that this type of backup does not protect all parts of SharePoint (IIS settings, web.config, customizations not deployed as solutions, etc.).

 

Writing custom PowerShell/Stsadmin backups provides a lot more flexibility in terms of RTO, RPO and RLO. In other words, you can create backup jobs of different granularity and run them on Windows Server timer jobs.

This approach can be combined with scheduled virtual machine backup jobs to create a "safety net" to fall back onto in case your backup scripts were not entirely up to date. This can quickly happen when individual user groups are allowed to deploy their own code, workflows or third-party web parts.

 

Third-party backup tools like the Idera Backup Manager provide an easy-to-use visual interface that allows for granular scheduling of backup jobs. Idera's tool also offers full content search capabilities and self-service document recoveries for authorized site users and protects not only the content database, but also configuration and service application databases. This leads to a significant improvement in terms of RTO (see datasheet for more features).

 

High Availability (HA) solutions for SharePoint will help you to almost entirely avoid downtime in case of disaster. HA tools like Neverfail operate on the byte level, constantly replicating the servers in your SharePoint farm to passive mirror instances. The mirrored servers can be located at a different geographic locations. As soon as the passive servers detect the failure of any production farm servers, the disaster recovery farm takes over all user requests. This failover usually occurs within minutes and protects all aspects of your SharePoint farm.

 

In addition, third-party tools like the Metalogix Selective Restore Manager allow users to quickly restore data by directly connecting to an offline content database. This tool can be of tremendous value when it comes to quickly restoring specific mission-critical content elements, either to a file share or to a disaster recovery farm. You will still lose some SharePoint fidelity, but at least you can get to all your files, instead of having them buried in the content database.

 

Long story short, SharePoint DR is not as simple as one might think it should be, but it's also not as complex as it sometimes sounds. Diligent planning is key. And don't forget to have the various business stakeholder groups sign off on RTO, RPO and RLO. Finally, test, test, test.

 

To contact the authors with questions, please email Richard Clarke or Torsten Volk.