By Terry Engelstad
MCP, MCSE, CCNA, MCDBA, MCTS, MCITP
AIS Network Operations Manager
The complexity and diversity of the Microsoft SharePoint platform also applies to its disaster recovery options. When it comes to protecting your SharePoint farm from the effects of a catastrophic event, there are numerous tools and best practices. But which is the best fit for you?
I recently completed reading and studying the SharePoint 2010 Disaster Recovery Guide by John L. Ferringer and Sean P. McDonough. It’s a worthwhile read, if you have the opportunity and particularly if you are trying to determine whether your current procedure for backing up SharePoint environments provides adequate and proper recovery capabilities.
The book explains that there are three kinds of recoveries:
- Site Collection
- Full Farm
If you need to do Content recovery, then the Content Database needs to be backed up. If you need to recover a Site Collection, then the Site Collection needs to be backed up. Content is backed up as part of a Site Collection, but a Site Collection is not backed up as part of Content. If you need to recover a full farm, then you need to do a Full Farm backup. Merely backing up the individual SQL Server databases does not capture enough information to recover a full farm. There are additional components that get installed on the server; these are not in a SQL Server database and therefore will not be available for a recovery.
This means that if your current procedure is to back up the SQL Server databases, then that method will not work for Full Farm recovery of SP 2010 Foundation or Server. According to Microsoft, this is an un-supported practice, which means you may get lucky and it might work, but then again, maybe not.
The only fully supported method for a full farm recovery is to do SharePoint Full Farm Backups. SharePoint Full Farm Backups are executed via:
1) SharePoint Central GUI,
2) PowerShell commands, or
3) stsadm command line.
Execution via PowerShell or stsadm can be scripted as batch jobs and scheduled. A full farm backup ends up including the SQL Server databases, but it also picks up the IIS configuration, the Hive, GAC components, and Customized Code – everything required for Full Farm Recovery.
In some circumstances, there may be a difference in the amount of space and time used to create a Full Farm Backup. FFB creates an un-compressed, directory structure, which would subsequently be backed up to storage for 14-day (or otherwise) retention. The “un-compressed” part will not be affected by those implementations using SQL Server Web Edition, since Web Edition doesn’t compress backups. For those implementations using SQL Standard or SQL Enterprise, this would result in additional disk space being consumed, because what was once compressed will no longer be compressed.
How are you approaching SharePoint 2010 disaster recovery? I encourage your comments.