When creating a disaster recovery (DR) plan, you need to determine what you are trying to recover from. In other...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
words, think of your disaster recovery plan as "taking out insurance" for your SharePoint environment. There are various levels of protection you might wish to set in place. You may be using a DR plan to create a replica of your portal to recover specific content, or you may wish to develop a plan to create a new environment from scratch (in the event of an actual disaster) that will quickly and effectively replicate the current environment.
For example, on one end of the spectrum, you could make things easy on your operational team and back up your data once every six months or so, but then you run the risk of losing a lot of data if something were to happen (a hard drive crashes, you lose power, and so on). On the other end of the spectrum, you can do a full backup of everything daily to ensure that you always have the latest of everything—but does that make sense for your environment?
To properly capture these types of decisions, we recommend creating a DR operations document.
The following is a framework for a SharePoint disaster recovery document. It is important to note that a DR plan is only effective if it is both complete and accurate.
An effective SharePoint DR plan should contain full documentation on how to recreate an entire SharePoint environment from scratch. This requires a process (and discipline) that is accurate and well-maintained. Every time a SharePoint element (for example, a Web part, xml file, and so on) is altered or added, the "disaster recovery inventory document" must be updated.
Here's an example of information that should be captured:
a. Explanation of when to use this plan
b. History of any updates
c. Permissions required to execute the plan
II. SharePoint Backup/Restore
a. Step-by-step execution plan for your environment
III. Adding Web Parts
a. Location of all Web part CAB or install files
b. Instructions for installation
c. Location of latest Web.config file
IV. Adding Additional Components (Features, Event Handlers, Workflows, and so on)
a. Location of all files
b. Instructions for file movement and/or installation
a. Instructions on how to test a new portal environment
i. Smoke test (a quick examination of the environment to inspect stability)
ii. Validation of Web part execution
iii. Validation of security model
a. Comments collected from previous restorations
After you've got a document underway, you'll want to start filling in your company-specific recovery steps, including your SharePoint backup and restore steps. To determine your specific steps, you need to decide which SharePoint backup/restore options best suit your needs. Let's take a look at the various SharePoint options.
TABLE OF CONTENTS
- Part 1:Creating a SharePoint disaster recovery operations document
- Part 2: Understanding Microsoft SharePoint Server backup and restore options
- Part 3: Using the Microsoft SharePoint Server 2007 backup tool
- Part 4: Managing Microsoft SharePoint Server 2007 backup files
- Part 5: Using the Microsoft SharePoint Server 2007 restore utility
- Part 6: Scheduling a Microsoft SharePoint Server 2007 backup
- Part 7: What's not covered by a Microsoft SharePoint Server 2007 backup
|This chapter excerpt from Essential SharePoint 2007, by Scott Jamison, Mauro Cardarelli, and Susan Hanley, is printed with permission from Addison-Wesley Professional, Copyright 2007.|