Chapter 1: Basics of Exchange Protection

Understanding Exchange disaster recovery can take a while. The first step, naturally enough, is to gain an understanding of the fundamentals of Exchange protection. Later chapters will describe the specific technologies you can use to improve the availability and recoverability of your messaging system and its related business services. First, we must explore the causes of downtime, the general classes of availability and protection technology, and ways to assess your Exchange environment to determine the most effective methods for you to better protect your Exchange infrastructure.

Chapter 2: Availability Building Blocks: Disaster Recovery

Chapter 1, which focused on the causes and potential solutions for downtime, gave you a highlevel overview of what to look for and think about as you begin to consider how to improve the availability of your Exchange infrastructure and servers. There are several technologies that can be used to provide disaster recovery and business continuance capability. This chapter will explore the fundamental principles behind disaster recovery and look at technical solutions that purport to improve disaster recovery. It will then examine some of the design choices and tradeoffs you face in trying to design an effective disaster recovery plan.

Chapter 3: Availability Building Blocks: High Availability and Business Continuance

In Chapter 2, you learned about some fundamental technologies that can be used for disaster recovery. Most businesses are more interested in preventing disasters than in recovering from them. There are several technologies that can potentially raise the availability and service quality of your messaging systems, and the infrastructure on which they depend. This chapter will examine some of these technologies and see how you might apply them in your Exchange infrastructure.

Chapter 4: Availability Building Blocks: Validation, Testing, and Deployment

The preceding chapters have all focused on technologies that you can use to improve the recoverability, availability, and resilience of your Exchange infrastructure. However, technology alone won’t give you a lasting improvement. This chapter describes how you can validate, test, and deploy your disaster recovery, high-availability, and business continuity solutions so that you’ll reap more than just temporary benefits.

Chapter 5: Designing for Disaster Recovery and High Availability with Exchange

The preceding four chapters have talked about the fundamental technologies and processes that you have to apply when designing an Exchange system to improve its recoverability and availability. This chapter describes Exchange’s infrastructure requirements as well as the business requirements for messaging availability and resiliency that have design consequences for Exchange. Rather than focus on the actual configuration steps, this chapter will describe your design options, how they work, and how to evaluate them to determine which settings are most suitable for your environment. Along the way, this chapter will draw on the introductory material from the previous chapters.

So far, you’ve learned a great deal about the underlying technologies that you can use to help improve the availability, resiliency, and service quality of your Exchange servers. It’s time to move on to the next milestone—applying these tools and technologies to developing a serviceable Exchange design. We’ve already discussed some aspects of each technology that make it well- or ill-suited for Exchange; this is the appropriate point to widen the scope a little and look at the many other systems and services upon which Exchange depends so that you can broadly apply high availability, disaster recovery, and business continuity design principles to them.

Chapter 6: Implementing Disaster Recovery with Exchange

At this point, you should have a good theoretical understanding of disaster recovery technologies and practices. It’s time to turn that theoretical knowledge into practical knowledge. To do so, this chapter focuses on how to implement the design changes and procedures that earlier chapters have discussed. This chapter relates to disaster recovery, and the next chapter will cover high availability solutions.

Chapter 7: Building an HA–Ready Infrastructure

The preceding chapters of this book have described how high-availability and disaster recovery technologies work, and Chapter 6 described how to use disaster recovery tools and procedures. This chapter is the counterpart to Chapter 6; it explains what you need to know to build an infrastructure that’s ready to provide high-availability messaging services to your users. Some aspects of this infrastructure are easy and quick to implement; others may require you to carefully examine what is currently in your environment and make some tough decisions about whether the expected gain in capability is worth the additional cost and risk of changing the infrastructure.

Earlier, this guide talked about how hard it can be to pin down the exact definition of “high availability.” The definition that works for your organization may be quite different from what another company in the same business expects—much less what may be appropriate in another market sector. Rather than attempt to specify a given level of availability as high (or medium or low), it’s more appropriate to talk about enhancing your systems’ availability so that the infrastructure is better than what you’ve got right now. The degree of enhancement will depend on how much uptime you need, how much money you’re willing to spend, and specific features of your environment.

Any discussion of high-availability will involve counting 9s at some point. This chapter’s discussion will assume that your organization requires a maximum of 99.9 percent uptime; although it’s certainly possible to go beyond that level of uptime, doing so can be very expensive, and it’s rarely justifiable from a business standpoint. Many organizations that want 24 × 7 × 365 uptime find that they actually need something closer to 6 × 18 × 365, or even less, and the cost savings gained by finding the correct level of required uptime can be very significant.