You’ve finished the book, and hopefully you’ve preserved your sanity by reading chapters and sections here and there as needed. We packed an awful lot of information into this book, and it’s hard to pull it all in at once and process it without coming up for air.
If you didn’t pace yourself and you’re one of those die-hard troopers who read the book from cover to cover, we salute you! You are indeed a rare breed—the type that probably winds down at night reading patent applications, instruction manuals, and a randomly selected book from the encyclopedia set on the shelf.
Regardless of how you identify yourself as a reader, we hope that you found each of the chapters between the covers to be helpful, informative, and referential. We spent many long hours writing and refining the content in this book. Our goal was to provide you, the administrator, with the material you would need to understand and carry out disaster recovery planning for your SharePoint environment in an informed and educated manner.
If we did our jobs properly, the structural integrity of your cranium is probably somewhat compromised from the constant drumming we have been doing throughout many of the chapters. Regardless of who you are or why you picked up this book, we made the reasonable assumption that you have at least some interest in SharePoint disaster recovery. With that in mind, we tried to drive home a handful of universal concepts whenever and wherever we could.
The most important concept we tried to drive home bears repeating one more time as a parting shot: there is no such thing as a one-size-fits-all SharePoint disaster recovery strategy. Although there are some patterns that do arise in SharePoint disaster recovery planning and implementation, your environment is unique. You may have some luck in starting with a template that was designed by someone else with disaster recovery needs that were similar to yours, but by now you should fully understand why any such template or prepackaged strategy is merely a starting point—not the end of the conversation.
You should also realize that disaster recovery is an awful lot more than just backup and restore. Some administrators fall into the habit of using “disaster recovery” and “backup/restore” interchangeably, but they are not synonymous. The latter is often a major facet of the former, but disaster recovery activities are driven primarily by business concerns—not technical concerns as in the case of backup/restore. If any of this sounds a little fuzzy, go back and reread the first few chapters of the book. It’s okay, and we understand. The material was covered quite some time ago if you’re one of the aforementioned die-hard, cover-to-cover readers.
Microsoft has packed some great new disaster recovery features and capabilities into the SharePoint 2010 platform, and we’ve attempted to cover as many of them as possible in this book. Much as there is no one-size-fits-all approach to disaster recovery in general, there is no magic bullet feature that is going to address your disaster recovery needs in every scenario. Every technology supporting disaster recovery comes with its own benefits and disadvantages, and we have tried to provide you with the information needed to compare the platform features and understand where each of them excels and comes up short.
After all the disaster recovery strategies have been plotted, the technologies have been selected, and the plans have been built, you still have to deal with the day-to-day operational concerns that remain in the disaster recovery bucket. Backups, restores, recoveries, and rebuilds are some of the activities that tend to get tossed into that bucket. We covered many of these concerns and operating scenarios in several of the chapters, and we tried to address the challenges and questions that we ourselves have seen in our SharePoint travels. We hope that you found the material to be useful in your role as an administrator.
Even though we managed to go on about SharePoint disaster recovery for more than 400 pages, we would be lying if we said that we were able to cover all the technologies, concerns, scenarios, and watch-outs that we would have liked. We had to make some compromises on coverage, and where we did, we attempted to call those out. If you found something particularly helpful, we would love to hear about it. At the same time, we want to hear about troubles you’ve had, technologies we should have covered, situations that have frustrated you, and anything else you want to share that is disaster recovery related.
We closed our 2007 version of this book with the following quote, and it remains just as applicable now as it did before. The following is attributed to Alan Lakein, an acknowledged expert on personal time management:
“Planning is bringing the future into the present so that you can do something about it now.”
These words summarize the essence of disaster recovery planning in a nutshell. Disasters don’t happen when it’s organizationally convenient, and they strike without warning. The only reasonable course of action is to assume that a disaster will happen to your SharePoint environment at some point in the future and work to prepare for that disaster now. After all, hope and ignorance are not recognized as acceptable risk mitigation strategies in any technical group or organization.