Biswajit.HD
Member
- Joined
- 5 Aug 2011
- Messages
- 2,287
- Reaction score
- 281
SharePoint has become vital to the business infrastructure and, in many companies, it's even used as the company's face to the world: its public facing website. Because of this dependency and high visibility, a well-thought-out disaster recovery strategy for SharePoint is imperative.
Three types of disasters can impact SharePoint:
• Content deletion -- the most likely type of disaster to occur; happens when a user simply deletes some content that they, or someone else, needs.
[REVIEW: 10 things we love about SharePoint 2010]
• Machine failure -- when farm and environment are working and stable, but a single machine has failed. Machine failure disasters (unlike content deletion) affect the entire SharePoint user base.
• SharePoint farm failure -- the worst type of SharePoint disaster; takes the whole facility hosting your SharePoint farm offline. The cause could be anything from a lost Internet connection to a natural disaster, but the result is that SharePoint is unavailable to everyone, which directly affects the business.
The impact of each type of disaster can differ significantly. A content deletion disaster usually is a localized event that doesn't affect business continuity. Machine failure disasters may or may not have a noticeable impact on business continuity, depending on which server failed and how its services are used, so it's important to know how your company uses SharePoint when planning your disaster recovery strategy.
The loss of the entire SharePoint farm is disastrous for almost all companies. Farm loss can cost the organization thousands of dollars an hour in lost wages and revenue, so keeping SharePoint properly protected is paramount to keeping the business running.
Developing a DR plan
Before you develop your DR plan, make sure your service level agreement covers two aspects of disaster recovery: the Recovery Point Objective (RPO) and the Recovery Time Objective (RTO). The RPO defines the amount of data that acceptably can be lost, from a certain point in time. The RTO, on the other hand, defines how long it will take to get recovered content back to the user. The RTO is separate from the RPO, but both affect the end user.
A backup strategy is the foundation for any DR plan, and should start with a method for backing up your content databases. If you also have external SharePoint content, backing up your content databases alone won't be sufficient. SharePoint 2010 supports two methods for storing binary content in locations outside of SQL: the older External Blob Store (EBS) and the newer Remote Blob Store (RBS).
EBS support in SharePoint really only affects upgrades from SharePoint 2007, while RBS is the method SharePoint 2010 administrators use on new farms. Hooks built into SharePoint support the RBS functionality, but the product itself doesn't do it. You will need a third-party RBS solution if you want that functionality.
Besides backing up content, you also need to be able to recover that content when it's needed. Practice your recovery routine periodically to make sure it's solid and all the moving pieces work correctly. This gives you a heads up if any of the process has broken, and makes an actual disaster seem less disastrous when it actually happens.
What your SharePoint recovery tool should include
Once you have a good SharePoint disaster recovery plan, the next step is to determine the tool you need to facilitate the plan. SharePoint includes several out-of-the box DR options, but you will quickly outgrow them as your farm grows.
SharePoint enables you to export the content of individual sites, which can be helpful for content disasters, but is not enough to address other types of disasters. SharePoint 2010 also has native support for backing up site collections, which will protect content and some settings, but does nothing to protect against machine or farm failure.
SharePoint includes the ability to do full farm-level backups for things like content, configuration, solutions and service application information. These backups can be coupled with another feature -- unattached content database recovery -- to recover content down to the individual list or library, and can be used to restore an entire farm.
Since this approach backs up entire databases and service applications, it can be used to restore individual components if a machine or drive fails, and could potentially be used to recover a farm in a different location if the primary facility goes down. But, because an entire restore is required after the primary fails, bringing the recovery farm online takes a long time. Plus, the farm-level backups don't back up 100% of a farm's settings, so some extra work is still needed to complete a restore.
To top it all off, none of the out-of-the-box SharePoint backup solutions have native support for scheduling or monitoring. They may work for small farms, but aren't robust enough for mission-critical SharePoint installations. For those, you will need a third-party tool to protect your farm.
Three types of disasters can impact SharePoint:
• Content deletion -- the most likely type of disaster to occur; happens when a user simply deletes some content that they, or someone else, needs.
[REVIEW: 10 things we love about SharePoint 2010]
• Machine failure -- when farm and environment are working and stable, but a single machine has failed. Machine failure disasters (unlike content deletion) affect the entire SharePoint user base.
• SharePoint farm failure -- the worst type of SharePoint disaster; takes the whole facility hosting your SharePoint farm offline. The cause could be anything from a lost Internet connection to a natural disaster, but the result is that SharePoint is unavailable to everyone, which directly affects the business.
The impact of each type of disaster can differ significantly. A content deletion disaster usually is a localized event that doesn't affect business continuity. Machine failure disasters may or may not have a noticeable impact on business continuity, depending on which server failed and how its services are used, so it's important to know how your company uses SharePoint when planning your disaster recovery strategy.
The loss of the entire SharePoint farm is disastrous for almost all companies. Farm loss can cost the organization thousands of dollars an hour in lost wages and revenue, so keeping SharePoint properly protected is paramount to keeping the business running.
Developing a DR plan
Before you develop your DR plan, make sure your service level agreement covers two aspects of disaster recovery: the Recovery Point Objective (RPO) and the Recovery Time Objective (RTO). The RPO defines the amount of data that acceptably can be lost, from a certain point in time. The RTO, on the other hand, defines how long it will take to get recovered content back to the user. The RTO is separate from the RPO, but both affect the end user.
A backup strategy is the foundation for any DR plan, and should start with a method for backing up your content databases. If you also have external SharePoint content, backing up your content databases alone won't be sufficient. SharePoint 2010 supports two methods for storing binary content in locations outside of SQL: the older External Blob Store (EBS) and the newer Remote Blob Store (RBS).
EBS support in SharePoint really only affects upgrades from SharePoint 2007, while RBS is the method SharePoint 2010 administrators use on new farms. Hooks built into SharePoint support the RBS functionality, but the product itself doesn't do it. You will need a third-party RBS solution if you want that functionality.
Besides backing up content, you also need to be able to recover that content when it's needed. Practice your recovery routine periodically to make sure it's solid and all the moving pieces work correctly. This gives you a heads up if any of the process has broken, and makes an actual disaster seem less disastrous when it actually happens.
What your SharePoint recovery tool should include
Once you have a good SharePoint disaster recovery plan, the next step is to determine the tool you need to facilitate the plan. SharePoint includes several out-of-the box DR options, but you will quickly outgrow them as your farm grows.
SharePoint enables you to export the content of individual sites, which can be helpful for content disasters, but is not enough to address other types of disasters. SharePoint 2010 also has native support for backing up site collections, which will protect content and some settings, but does nothing to protect against machine or farm failure.
SharePoint includes the ability to do full farm-level backups for things like content, configuration, solutions and service application information. These backups can be coupled with another feature -- unattached content database recovery -- to recover content down to the individual list or library, and can be used to restore an entire farm.
Since this approach backs up entire databases and service applications, it can be used to restore individual components if a machine or drive fails, and could potentially be used to recover a farm in a different location if the primary facility goes down. But, because an entire restore is required after the primary fails, bringing the recovery farm online takes a long time. Plus, the farm-level backups don't back up 100% of a farm's settings, so some extra work is still needed to complete a restore.
To top it all off, none of the out-of-the-box SharePoint backup solutions have native support for scheduling or monitoring. They may work for small farms, but aren't robust enough for mission-critical SharePoint installations. For those, you will need a third-party tool to protect your farm.
