Skip to main content

Über dieses Buch

Few IT professionals take the time to learn what needs to be known to do disaster recovery well. Most labor under the pretense that good administration equals close to five-nines uptime. Most technical people do not see the value of planning for disasters until the unexpected has already happened, and the effects of a disaster involving a SharePoint farm—which today houses business information, line-of-business applications, sensitive information, extranets, and other highly important assets—can be staggering.

Pro SharePoint Disaster Recovery and High Availability, Second Edition will take you through a step-by-step process to show how to build an awareness and reaction plan for the inevitable. With a focus on real-world experiences and war stories, author Stephen Cummins weaves an expert tale of woe response and offers you:

Ways to see the warning signs of disaster, and ways to avoid it Ways to respond to a disaster while it is happening Perhaps most importantly, how to develop a plan to deal with disaster when it inevitably does happen



Chapter 1. Steering Away from Disaster

On my very first SharePoint job back in 2001, I spent hours backing up, copying, and restoring the SharePoint installation from an internal domain to the one accessible to users from the Internet. This was not a backup strategy; it was a crude way to get content to the Internet while keeping the intranet secure. But it made the system very vulnerable to failure. Every time content was updated, I had to manually overwrite the production SPS 2001 with the updated staging SPS 2001 out of hours so users could see the changes the next day. This started to become a nightly occurrence. I still remember the feeling of fear every time I had to run the commands to overwrite the production farm and bring it up to date. I would stare at that cursor while it made up its mind (far too casually, I thought) to bring everything in line. I would sigh with relief when it worked and I was able to see the changes there. I still feel the sense of mild panic when it didn’t work and I had to troubleshoot what went wrong. It was usually an easy fix—some step I missed—but sometimes it was a change to the network or the Exchange server where the data was stored or a Windows security issue.

Stephen Cummins

Chapter 2. Planning Your Plan

This chapter describes the dependencies you will have to address before you can begin to create a disaster recovery plan. The plan itself will consist of what to do when disaster happens, but there are a number of important steps before it can even be created. Firstly, there has to be a will to create it and the funding to do so, plus the input of stakeholders in the business itself and not just IT. There will be barriers to your desire to create a plan and you will have to approach removing them in different ways. I will describe each one and give an example of how you can remove it.

Stephen Cummins

Chapter 3. Activating Your Plan

This chapter focuses on the process leading up to the activation of the procedures of your disaster recovery plan. It’s important to define the process that says, “Yes, it is time to active our disaster plan.” I’ve touched on concepts like recovery tiers, which will help you define your plan, but I haven’t gone into any real technical detail yet and that is deliberate—that will be done in later chapters. There is a more pressing point I need to get across first: too many plans rely on one person to be in the right place at the right time, to know that a disaster has happened, and to know how to fix it. There are far too many assumptions in that sentence.

Stephen Cummins

Chapter 4. High Availability

I’ve been in the SharePoint administrator role a few times and it is very like being a lifeguard or fireman. When nothing is going wrong, it looks like you’re not fully utilized. Managers want you do be busy doing something, working on specific projects. (This is to make them look busy, too.) Only when things go wrong is your real value to the organization fully appreciated—in a short and intense time you get to prove your worth to your manager and others. But I have actually seen administrators who generate a constant state of fake crises so they can look like they are constantly saving the day and putting out fires. This is done to make them look important.

Stephen Cummins

Chapter 5. Quality of Service

In my experience, the main causes of SharePoint performance and response issues noticed by users are not a result of SharePoint being at fault at all. They are a result of network or SQL Server issues. In my early years, I would often be frustrated when trying to troubleshoot the vague message from the help desk that “SharePoint was slow.” All of the SharePoint and Windows event logs were fine. Eventually, some network or SQL Server guy would casually mention that they were having some performance issues that day. That SharePoint is so dependent on these two other tiers is now something I am well aware of, so it’s one of the first places I go if I think the quality of service problem is being caused by something outside of the application itself.

Stephen Cummins

Chapter 6. Back Up a Step

Backups are your next line of defense after high availability options like resilience and redundancy. As described in Chapter 4, you can protect against failure to a degree. While hardware failure does happen and disasters, like sheep, do happen, the main cause of unavailability of a system is maintenance that has gone wrong. Backups are always necessary no matter how comprehensive your resilience and redundancy planning because data on a disk is fragile and any number of things can destroy it. However, one of the principal advantages of digital data over physical data is that it is relatively easy to create an exact copy. Content that is simply zeros and ones can be copied with almost perfect fidelity whereas copying a physical document is a process far more prone to error. You’ll rarely regret making copies of data.

Stephen Cummins

Chapter 7. Monitoring

Well, enough to get out of the way.

Stephen Cummins

Chapter 8. DIY DR

Until now, this book has focused on disaster recovery and backup from the point of view of the business stakeholders and the infrastructure owners. A full farm backup will recover content databases, farm settings, solutions, and service applications. These solutions are only useful if the entire farm is lost; they don’t address recovery from a user’s perspective. Users sometimes only need to recover smaller parts of the farm, as their focus is just on their content. SharePoint provides options for recovering the following elements of interest to users:

Stephen Cummins

Chapter 9. Change Management and DR

“The one unchangeable certainty is that nothing is unchangeable or certain”

Stephen Cummins

Chapter 10. DR and the Cloud

Cloud computing has finally matured enough that the time has come to properly understand what benefit it could provide to SharePoint owners. The SharePoint owner in your organization will still ultimately have responsibility for users’ content despite the fact that the infrastructure is owned by an external third party. There will also be the responsibility for credential federation and single sign-on. SharePoint in the cloud is available on dedicated hardware as well as in multi-tenancy environments. In either case, the administrator has to adapt or replace existing plans and procedures for HA and DR. These concepts have to be thought about differently now because some aspects of the HA and DR are in the hands of a third party and a whole new raft of servers will have to be managed if you want single sign-on.

Stephen Cummins

Chapter 11. Best and Worst Practices

A principle is the expression of perfection, and as imperfect beings like us cannot practice perfection, we devise every moment limits of its compromise in practice.

Stephen Cummins

Chapter 12. Final Conclusions

My basic principle is that you don’t make decisions because they are easy; you don’t make them because they are cheap; you don’t make them because they’re popular; you make them because they’re right.

Stephen Cummins


Weitere Informationen

Premium Partner

Neuer Inhalt

BranchenIndex Online

Die B2B-Firmensuche für Industrie und Wirtschaft: Kostenfrei in Firmenprofilen nach Lieferanten, Herstellern, Dienstleistern und Händlern recherchieren.



Product Lifecycle Management im Konzernumfeld – Herausforderungen, Lösungsansätze und Handlungsempfehlungen

Für produzierende Unternehmen hat sich Product Lifecycle Management in den letzten Jahrzehnten in wachsendem Maße zu einem strategisch wichtigen Ansatz entwickelt. Forciert durch steigende Effektivitäts- und Effizienzanforderungen stellen viele Unternehmen ihre Product Lifecycle Management-Prozesse und -Informationssysteme auf den Prüfstand. Der vorliegende Beitrag beschreibt entlang eines etablierten Analyseframeworks Herausforderungen und Lösungsansätze im Product Lifecycle Management im Konzernumfeld.
Jetzt gratis downloaden!