Thursday, May 20, 2010

SharePoint 2010 Business Continuity Management

Business Continuity Management

Microsoft uses the term business continuity management in terms of new features that they are providing to support your ability to manage SharePoint backup/restore, high availability and disaster recovery scenarios. On the topic of backup and restored there are several new improvements that you should take note of:

  • Farm backup is available in Central Admin and will do backups of each service and content database. Microsoft SharePoint Server 2010 supports backup of databases up to 600GB and supports both Full and Differential. However System Center Data Protection Manager 2007 supports up to 5TB with Full, Differential and Incremental.
  • New Configuration only backup - configuration database settings can now be written into an XML file. This provides the ability to create a new farm with the same topology of the original farm.
  • Content database backups that will start a SQL Server backup for each individual content database selected. You then have the flexibility to restore the content database with a new name or overwrite an existing.
  • Search backups are little more involved (there are two phases) to support both search indexes and the search database. It is important that the index is preserved because rebuilding them from scratch is an expensive operation. You have to understand a little bit about how searching and crawling work but at a high level, crawl services will search for new content and that new content will be merged into the index which users search against. In the first phase of the search back up, the merging of indexes will be stopped so indexes can be copied from the query servers. Crawling for new content will still continue. As well all search databases will be backed up. In the second phase, crawls will be paused and all new indexes that were created while Phase 1 was going will be backed up. Then crawling and merging will be restarted. The reason why this is done to minimize the downtime of crawling for new content. When restoring, indexes are first restored, then the search databases and finally indexes from the second phase and merged into the index backed up in the first phase. Search back ups are only supported through SharePoint Admin.
  • Service applications in general have their own back and restore routines. The search one we just discussed is special for search. SharePoint will launch SQL Server backups of any associated database to the service application along with the service configuration database. Again this is specific to SharePoint Admin and not supported by SCDP Manager 2007.
  • Backup and restore of Site Collections have changed such that they are more granular and support back/restore of data that is unattached to a content database. Remember that a content database may have one-to-many site collections stored within it. SharePoint 2010 now supports backing up a collection by extracting data out of the content database instance using Select statements and then saving data to file. It is even possible to have SharePoint create a snapshot of the content database and then create the site collection back up from the snapshot to reduce performance against the live content database. The now unattached backup (.bak file) and be restored into any content database you may have.
  • Ability to back up both site and lists from central admin is now supported with SharePoint 2010. Similar to the backup/restore of site collections, sites and lists are extracted out using SQL Select statements and stored on file (.cmp file). They can then be restored into any content database you may have.
  • Improved site deletion logic that ensures that minimizes site blocking by using timer jobs that will perform this operation in the background and do chunk based deletion.
  • There are new improvements associated to high availability that you should be aware of for SharePoint 2010. The most noticeable one is a new feature support to support SQL Server Database Mirroring for all databases. All databases configured within SharePoint can now take advantage of this. In central admin, it is now as simple is identifying the Failover Server name when for example creating a new content database.

Business Continuity Management Thoughts

All of these topics usually came up when I talked with clients about SharePoint 2007. Many of clients did not put enough forethought into how they were going to support backup/recovery, disaster recovery and high availability. I think in many cases well intended clients missed the fact that there is a strong correlation between the logical design of SharePoint and how data should be managed for backup/restore. Typically backup/restored was pushed off to network administrators who would just spin up new site collections and content databases without any thought to context to what was being done with SharePoint. They would not know who is accessing what, how often, why and from where. Things like security and service level agreements were not considered because some site collections are more important than others. The net result was extremely bloated content databases and company has no agility to react to change or to sustain operations without have to buy a third party tool.

Now with SharePoint 2010 we have some better features that allow us better manage data. It is really exciting to see the granularity that has been introduced and the new unattached database feature is really interesting. Plus as well, the new SharePoint PowerShell really enables administrators to write robust scripts to support backup/recovery. I still think the third party market for very rich backup/recovery tools.

My only point is that I do not like seeing new powerful, robust tools being used as a crutch for not thinking ahead. This all goes towards having strong SharePoint governance and procedures in place to understand how SharePoint data should be managed to ensure that service level agreements are met with the business. These means that a strategy should be put in place for tiered support and then have criteria that you measure all new solutions against. For instance, if a group needs a new document center along with some new custom web parts and workflows to manage that data, what is the plan for how the data will be backed up and restored based on business operating scenarios? The architect, designer, or developer creating SharePoint solutions must be able to explain how their solution fits in or affects continuity of operations for other deployed solutions. If they cannot, you have some long term problems.

No comments: