Comprehensive SharePoint 2007 Disaster/Recovery

High availability is a requirement and is usually at the top of the priority level for most real-world production environments. Luckily, for SharePoint there are a lot of options on how to configure your farm in order to load balance, cluster and provide the appropriate level of fault tolerance, given your budget, resources and timeline. Overall, there's been a lot of good material on the Web and in books that describe various approaches to backing up SharePoint environments. Joel Oleson has one of the better blog posts that give you all the information for what needs to be backed up and the tools that are available in SharePoint Backup Restore, High Availability, and Disaster Recovery. Most of the information available will give you the basic overview and provide a high level strategy on how to backup your SharePoint Farm. The reason most articles provide strategy vs. detail is because each environment can vary significantly and therefore, would alter the specifics of your Disaster/Recovery (D/R) plan. Factors that may influence the process are:

• 3rd Party Backup Software such as http://www.commvault.com/ and http://www.avepoint.com/
  
• Service Level Agreements (SLA)
  
• Server configuration (cluster vs. stand alone)
  
• Quantity of data to backup
  
• Server processing power and disk speed
  
• Intern-connectivity speed between servers including source and target locations for data backups
  
• Disk to Disk or Disk to Tape approach
  

The purpose of this article is to provide the details for how to fully backup a SharePoint environment. Because I am not using any 3rd party tools which include nice features such as incremental or full backups, the process will backup everything on a nightly basis. As a result, this approach is not the cleanest or fastest one out there and may fall outside the boundaries of your product environment SLAs. Alternatively, you may choose to use this approach for development or staging environments if you wish to cut down on backup software licensing costs. This document focuses ONLY on backing up SharePoint related data and not server related data. The goal is to backup SharePoint and Restore SharePoint, not the entire server. As a result, data such as event logs and the C drive is not included. Apply the contents of this article with your standard D/R plan for Windows 2003 servers to achieve full D/R plan for the server.

Note: There will be overlap, so adjust as necessary. For example, this article will backup all SharePoint sites using STSADM causing a backup of content and configuration databases. If you plan on using SQL Maintenance Plans to backup databases, this is where the overlap will occur. I prefer to have this type of overlap as it provides multiple options during the restore process.

Because SharePoint environments are broken into the following basic categories:

• SharePoint databases
  
• Search Indexes
  
• Web Front End Servers
  
• Windows SharePoint Services Sites
  
• Personal Sites
  

To back everything up, I will break out the information into the following three sections: Web Front End, Index and Database.

Web Front End

Web Front End servers contain all of the files that are used to call and render content to the user. Information is either pulled from local cached data (index data), Index server and content or configuration databases. Because of that, the web front end does not typically contain much data to backup. Whether or not you are doing custom development, it is still good practice to back up the entire SharePoint installation folders which will contain the out of box files along with custom templates, site definitions, list definitions, and custom ASPX files among other things.

To backup a Web Front End server, you can make your life a lot easier by working with a series of Batch files that can help automate the process. These batch files are important, because they contain the command line options that can be scheduled on your server during the most appropriate times for your maintenance period. Because the batch files are dependent on specific executables, the paths used in these examples are based on default installations. You may need to change those to reflect your specific installation. Additionally, it is recommended to place your batch files in a single folder for simplified management. For example, you can create a folder C:\SharePointBackups\ConfigurationItems (assuming your C drive has adequate disk space).

Nevertheless, the following data needs to be backed up on your SharePoint Front End Web Server:

Data	Process
System State	To backup the system state, you can create a BAT file that is scheduled to run with the following command: ntbackup backup systemstate /J "Backup Job" /F "C:\ SharePointBackups \backup.bkf"
GAC Assemblies	When doing custom development and deploying fully trusted web parts, DLLs will be installed in the GAC. It is safe practice to just backup all of the GAC assemblies folder located at: C:\WINDOWS\assembly
IIS Sites	Backup all of the home directories for all of the IIS sites
IIS Logs	Backup all of the log directories for all of the IIS sites Also include backing up: C:\WINDOWS\system32\LogFiles Note: The default location for SharePoint Usage logs are located at: C:\Windows\System32\LogFiles\STS\ and will be included in this backup. If you change the default location for this path, then that directory must also be included in your backup plan. Other Windows SharePoint Services logs (Optional): STSAdm.log and OWSTimer.log from the C:\Documents and Settings\ Windows_SharePoint_Services_Administrator_Account \Local Settings\Temp directory.
IIS Configuration	To backup IIS configuration, you must backup the IIS metabase configuration file (Metabase.xml) and the matching metabase schema file (MBSchema.xml). Microsoft provides a VBS file to simplify the process. Execute the following manually or in a BAT file to schedule: Cscript.exe iisback.vbs /s <YourServerName> /u Administrator /p <YourAdminPassword> /backup /b IISBackupUp /overwrite
SharePoint Resource Files	Backup all files located at: C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions
SharePoint Webs	To backup SharePoint applications, you can use STSADM. Create a bat file using STSADM to backup each SharePoint Web application in your farm. Every step listed on this table is required on each Front end Web Server with the exception of this one. C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\BIN\STSADM.EXE -o backup -url <SiteURL> -filename <FileName.dat> -overwrite

Index

Index servers propagate index data to the query servers (typically your Front End Web Servers), but you can't recover from there if you have system failure, drive, sector or file corruption. There are two ways to backup your index server: STSADM and Central Admin.

Data	Process
Index Server	To backup SharePoint index, you can use STSADM. Create a bat file using STSADM to backup the SharePoint Index application in your farm. C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\BIN\STSADM.EXE -o backup -url <SiteURL> -filename <FileName.dat> -overwrite

Database

This section will provide the basics for backing up SQL Databases in SQL Server 2005. There is no difference in backing up SharePoint databases that would cause you to make any changes to your standard SQL Server D/R Plan. The truth is that there are a lot of options that can and should be exercised when maintaining a high availability SQL Server installation. This article won't go into that level of detail, but will provide the basic information I like to see when backing up SQL databases.

Creating a Maintenance Plan in SQL Server makes your life a whole lot easier. There is a wizard that will walk you through the steps for backing up all of your databases. The important things to keep in mind are:

1. Select an output directory that has adequate storage and will not run out of disk space without some type of alerting. This drive can be a local drive configured to store backup data. I typically like to keep at least 2 full backups on this drive and keep older backups on my backup store
   
2. Put the SharePoint backup in a job that backups up databases are set to Full Recovery Mode. I prefer to separate databases in Full Recovery Mode vs. Simple just to keep a separation of the different models.
   
3. Create a maintenance plan for integrity and index rebuilding. This would not be done on a daily basis, but would need to comply with your SLA.
   
4. Setup some kind of alerting through SQL Database mail and/or notification services in case there are issues with your maintenance plan
   
5. Choose a maintenance job schedule that does not overlap with other processes. Make sure they are set to kick off one after another and they are coordinated with your backup plan. This is very important because you do not want your SQL job executing its maintenance job while your backup software is trying to backup at the same time
   

Example SQL Server 2005 Maintenance Schedule

Operation	Purpose	Time Frame
Backup – System Database Job	Backs up system databases	2200 hrs (daily)
Backup – Simple User Database Job	Backs up user databases set to simple recovery model	2300 hrs (daily)
Backup – Full User Database Job	Backs up user databases set to full recovery model	0000 hrs (daily)
External backup to disk/tape	Backups all of the first three operations	0300 hrs (daily)
Check Database Integrity	Runs DBCC CHECKDB on all user databases	0700 hrs (weekly on every Sunday)