none
Define : SharePoint Backup , Restore & Disaster Recovery Plan

    Question

  • Hello,

    I'm in process to define Backup, Restore and Disaster Recovery Plan.

    I've defined some scenario as listed below.

    Please, provide some input on below table

    • Cause of Disaster

      Resolution

      Approximately recovery time objective

      (Database Size ~ 4 GB)

      Approximately recovery time objective

      (Database Size ~ 50 GB)

      Approximately recovery time objective

      (Database Size ~ 100 GB)

      Restore tool selected

      Is this plan tested?

      SharePoint Server Failure

      Restore Whole Farm Backup of Previous day on Production Environment

       

      4 Hrs

       

      16 Hrs

       

      23 Hrs

      SharePoint Central Admin Tool

      No

      Site Collection Failure

      Restore Site Collection from Farm Backup of Previous day on Production Environment

       

      2 Hrs

       

      8 Hrs

       

      16 Hrs

      SharePoint Central Admin Tool

       

      Database Failure

      Restore Farm Backup of Previous day on Production Environment

       

      4 Hrs

       

      16 Hrs

       

      23 Hrs

      SharePoint Central Admin Tool

       

      Web site failure

      Restore Website from Farm Backup of Previous day on Standby System and then export to Production Environment

       

      2 Hrs

       

      8 Hrs

       

      16 Hrs

      SharePoint Central Admin Tool

       

      Content / data lost

      Restore Content/Data from Farm Backup of Previous day on Standby System and then export to Production Environment

       

      2 Hrs

       

      8 Hrs

       

      16 Hrs

      SharePoint Central Admin Tool

       

      Hardware Failure/ OS failure

      Create New SharePoint Environment with same name and  configuration of SharePoint Production Environment and Restore Farm backup

       

       

       

      SharePoint Central Admin Tool

      No


    Thanks, Sam
    Tuesday, November 30, 2010 3:52 PM

Answers

  • Sam --

    The first thing that jumps out at me is that I wonder if you would be able to directly restore a site collection from a full farm backup without having to first restore it to a standby system, I don't think that the farm backup option (regardless of whether you're using Central Admin or PowerShell) allows you to go any more granular than a web application or content database for a restore. If I'm remembering things right, you'll have to either specifically target the site collection for a backup through Central Admin or PowerShell or first restore the backup to your standby system and then specifically target the site collection.

    Second, I'm not sure that a whole farm backup is going to help you in the event of a server failure (the 1st item in the table). Is this for a SharePoint 2010 farm with multiple servers? If you lose a SharePoint server, a full farm backup is not going to restore everything that you need in order to get a server ready to be added back into a farm. If you lose a single server out of a multiple server farm, I think the best way to go would be to:

    • Remove the downed server from the farm entirely
    • If possible, consider activating that server's services or service applications on other servers until the server can be returned to the farm.
    • Restore or rebuild the server. My thought is to approach this more like you're building a new server to join to the farm than to restore the original one. Make sure that all of the software and configurations on the server that were originally on the server are back on it.
    • Join the server back into the farm

    A SharePoint full farm backup does not include a lot of items on your server's file system and items in its OS that you'll need to have in place should you completely lose that server, such as IIS configuration, web directories, web.config files, NLB settings, SSL certificates, etc. You must make sure you account for all those things in your backup strategy, b/c the SharePoint backup tools do not.

    Third, have you considered using PowerShell scripts and Windows Scheduled Tasks instead of Central Admin to back up your farm, so that you can turn it into a scheduled process rather than a manual one? This will go along way to removing the human element of the process and ensuring that its done in a regular and repeated fashion.

    Does that help?

    John


    MCTS: WSS v3, MOSS 2007, and SCOM 2007
    MCITP: Enterprise Project Management with Project Server 2007

    Now Available on Amazon - The SharePoint 2010 Disaster Recovery Guide. Also available - The SharePoint 2007 Disaster Recovery Guide.
    My blog: My Central Admin.
    Tuesday, November 30, 2010 6:55 PM

All replies

  • Sam --

    The first thing that jumps out at me is that I wonder if you would be able to directly restore a site collection from a full farm backup without having to first restore it to a standby system, I don't think that the farm backup option (regardless of whether you're using Central Admin or PowerShell) allows you to go any more granular than a web application or content database for a restore. If I'm remembering things right, you'll have to either specifically target the site collection for a backup through Central Admin or PowerShell or first restore the backup to your standby system and then specifically target the site collection.

    Second, I'm not sure that a whole farm backup is going to help you in the event of a server failure (the 1st item in the table). Is this for a SharePoint 2010 farm with multiple servers? If you lose a SharePoint server, a full farm backup is not going to restore everything that you need in order to get a server ready to be added back into a farm. If you lose a single server out of a multiple server farm, I think the best way to go would be to:

    • Remove the downed server from the farm entirely
    • If possible, consider activating that server's services or service applications on other servers until the server can be returned to the farm.
    • Restore or rebuild the server. My thought is to approach this more like you're building a new server to join to the farm than to restore the original one. Make sure that all of the software and configurations on the server that were originally on the server are back on it.
    • Join the server back into the farm

    A SharePoint full farm backup does not include a lot of items on your server's file system and items in its OS that you'll need to have in place should you completely lose that server, such as IIS configuration, web directories, web.config files, NLB settings, SSL certificates, etc. You must make sure you account for all those things in your backup strategy, b/c the SharePoint backup tools do not.

    Third, have you considered using PowerShell scripts and Windows Scheduled Tasks instead of Central Admin to back up your farm, so that you can turn it into a scheduled process rather than a manual one? This will go along way to removing the human element of the process and ensuring that its done in a regular and repeated fashion.

    Does that help?

    John


    MCTS: WSS v3, MOSS 2007, and SCOM 2007
    MCITP: Enterprise Project Management with Project Server 2007

    Now Available on Amazon - The SharePoint 2010 Disaster Recovery Guide. Also available - The SharePoint 2007 Disaster Recovery Guide.
    My blog: My Central Admin.
    Tuesday, November 30, 2010 6:55 PM
  • Thanks John, for your prompt reply.

    We are running everything on Single Server. I'ven't tested above listed plan as its required lots of time. Before I go and test any of above listed plan I wanted to talk others view.

    Do you have any best approch in your mind to define Backup/Recovery plan? if yes, then please let me know.

    Even creating Standby System and then restoreing everyting for single file seems very time consuming. If you know any other way then pls let me know.

    I'm aware of that whole Farm Backup is not gonna work in case of whole system failure. What's your suggestion in this case?

    Your help will be really appriciated.


    Thanks, Sam
    Wednesday, December 01, 2010 3:47 PM
  • Sam --

    Is this a physical or virtual server? If its virtual, you may be able to use snapshots or backups of the entire VM as a protective measure for a whole system failure. I say "may" b/c the only way that's supported by MS for SharePoint is if its a single server farm, but even then I'm still not 100% confident that there won't be problems, I've never tried it myself.

    For whole system failure protection, to me it comes down to first understanding what your budget (both time and money) for protecting the environment are, then understanding the capabilities and limitations of the tools and processes you can afford based on that budget, then coming up with tried and tested processes to protect against that failure based on the outcome of those first two items. It sounds like you're heading in the right direction with that based on this analysis you're showing.

    If you've got the budget to spend on it, purchasing a specialized backup/restore tool for SharePoint can be the quickest way you can implement a comprehensive solution for full protection that is (or at least should be) thoroughly tested and proven.

    If you don't want to, or can't, purchase a tool, then there's going to have to be a time investment in protecting your environment. Using SharePoint's provided tools, a full system failure means that you have to plan to do the following:

    • a system (hardware and OS) recovery or rebuild, depending on your protection measures of that resource
    • a SQL Server recovery or rebuild, depending on your protection measures of that resource
    • a farm rebuild, with the restore of some configuration data but not all
    • content recovery

    So in that case, here's why that is going to require a time investment:

    • You aren't going to have one tool to protect them all, so you'll have to configure and test them all independently, and then system test them all
    • A "full farm" backup is nice, but don't count on it to capture all of the configuration details about your farm. To me, a DR plan using SharePoint's farm backup tools must understand and rely on thorough and effective change control and monitoring to succeed. You have to know what configuration changes have been made to your farm so that you can recreate them in the event of a full farm recovery.
    • Your content is the most important thing to protect. Its what your users care about, its the stuff that they need that they're putting into SharePoint to access. Protect it effectively and thoroughly at all costs.

    Individual item protection is tricky. The good news is that you're in a much better situation with SharePoint 2010 than 2007. The new Granular Backup/Restore tools are nice, but the ability to use Unattached Content Databases is really the thing to pay attention to. It allows you to grab items out of a content database from within SharePoint without having to completely bring it into your farm (and therefore avoids issues with duplicate GUIDs in your farm).

    John


    MCTS: WSS v3, MOSS 2007, and SCOM 2007
    MCITP: Enterprise Project Management with Project Server 2007

    Now Available on Amazon - The SharePoint 2010 Disaster Recovery Guide. Also available - The SharePoint 2007 Disaster Recovery Guide.
    My blog: My Central Admin.
    Thursday, December 02, 2010 1:03 PM