Skip to main content
Disciplines
Automotive Business IT + Informatics Construction + Real Estate Electrical Engineering + Electronics Energy + Sustainability Insurance + Risk Finance + Banking Management + Leadership Marketing + Sales Mechanical Engineering + Materials
Events
DE
EN
Books
Journals
Topic Page
Marketing
Start single access now
Access for companies
EXTENDED SEARCH
Log in
Top

2013 | Book

Steering Away from Disaster Read chapter Read first chapter

Pro SharePoint Disaster Recovery and High Availability

Author: Stephen Cummins

Publisher: Apress

Part of: Springer Professional "Wirtschaft+Technik" , Springer Professional "Technik" , Springer Professional "Wirtschaft"

Login to get access
insite
SEARCH

About this book

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

Table of Contents

Frontmatter
Chapter 1. Steering Away from Disaster
Abstract
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
Abstract
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
Abstract
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
Abstract
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
Abstract
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
Abstract
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
Abstract
Well, enough to get out of the way.
Stephen Cummins
Chapter 8. DIY DR
Abstract
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
Abstract
“The one unchangeable certainty is that nothing is unchangeable or certain”
Stephen Cummins
Chapter 10. DR and the Cloud
Abstract
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
Abstract
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
Abstract
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
Backmatter
Metadata
Title
Pro SharePoint Disaster Recovery and High Availability
Author
Stephen Cummins
Copyright Year
2013
Publisher
Apress
Electronic ISBN
978-1-4302-6329-6
Print ISBN
978-1-4302-6328-9
DOI
https://doi.org/10.1007/978-1-4302-6329-6

Premium Partner

    Image Credits