Article

Exchange design choices and issues

Paul Robichaux Realtimepublishers

As you prepare to start assessing your Exchange environment to see how to improve its availability, you face some design choices that will strongly influence what your disaster recovery capabilities will look like.

Onsite vs. offsite

    Requires Free Membership to View

You are reading tip #9 from "10 tips in 10 minutes: Fundamentals of Exchange Server disaster recovery," excerpted from Chapter 2 of the book The Definitive Guide to Exchange Disaster Recovery and Availability, published by Realtimepublishers.
Where you keep your backups will influence how quickly you can perform restores, but there are other implications too. Let's start with the obvious tradeoff -- it's convenient to store your backups near your servers so that you can get to them quickly when needed. In contrast, if something bad happens to your servers, it's quite possible that your backups will be affected too. Offsite storage offers the possibility that your backup data will remain available to you even if your building burns to the ground or all your
servers are blown away by a tornado.

The best strategy for most organizations is probably a mix of the two: keep some backups onsite and others at a secure offsite location. For example, if you keep backups older than 1 week offsite, you can still do intra-week restores without having to wait for your backup tapes to be retrieved from the offsite location. Depending on your backup strategy, and the difficulty of moving media to and from your offsite location, you might even choose to take an extra intra-week full backup just for offsite storage.

Whichever storage method you choose, there is another risk to be aware of. Two large companies (Time Warner and Wells Fargo) have recently been forced to deal with a firestorm of negative press (and potential liability issues) because backup tapes containing confidential customer information were stolen in transit between their data centers and their offsite storage location. Remember, anyone who can get access to your backup tapes can use them to restore your Exchange data and then read it (unless, of course, you encrypt it), so whether you use onsite or offsite storage, you should protect your backup media to the same degree you protect the data on your servers.

Recovery vs. redundancy and resiliency

Let's assume you have a finite budget (I know, it's a stretch, but play along!). You can spend money on improving your ability to recover from failures or on adding redundancy and resiliency to reduce the odds that you'll need to recover from a failure. What should you do?

Generally, I advocate spending your money to improve your recovery capability first. Why? Because you'll always need the ability to do complete recoveries, no matter what kind of resiliency and redundancy you add with technologies such as clustering. No single technology gives you 100 percent protection, so you're always going to need to be prepared to do a full restore. Being able to do it right is a key requirement that should be met before you spend money on anything else.

The one case in which this recommendation may not apply is when you can sharply reduce the odds of needing to perform a recovery. For example, let's say that your servers are using ordinary disks, with no RAID. Adding RAID will greatly reduce the risk of a disk failure that might necessitate recovery, so it might make sense to put your budget to work by adding redundancy to lower the odds that you will need to perform a recovery.

Service providers vs. do-it-yourself

A number of companies specialize in business disaster recovery, offering services ranging from canned disaster recovery plans to hosted offsite operations centers that provide equipment and bandwidth. The basic idea behind these services is that the service company will do a better job planning and executing a disaster recovery than you will because they have more experience and expertise. In many cases, this claim is probably true. However, outsourcing this type of business-critical operation is always dangerous because you are essentially betting your business that the service provider will deliver when the chips are down.

For most organizations, it's better to spend money on improving your own internal disaster recovery capability and competence than to pay someone else to do it for you. It might make sense to supplement your own planning and execution capabilities by using a service provider to review your plans or to provide services (like an offsite data center) that you can't afford to maintain on your own.

Besides the full-service companies, a growing number of outfits offer Exchange-specific disaster recovery services that claim to be able to recover data from damaged or corrupt databases. Many of them are using commercial tools such as Quest Recovery Manager for Exchange that you could just as easily buy and use yourself; others rely on their own tools, which work with varying degrees of success. If you've carefully designed and implemented your disaster recovery processes, you won't need these kinds of services; if you do, that's probably a sign that your disaster recovery processes aren't quite perfected yet.

Planned vs. unplanned

The technologies described in this chapter can help you in two ways: they can reduce the risk of unplanned downtime, and they can make it easier to implement sensible planned downtime measures. As you might expect, though, in a chapter on disaster recovery, most of the benefits fall into the first category: replication, VSS, and even the humble conventional backup process can all be used to meet your RTO and RPO.

However, don't neglect the potential impact of these disaster recovery building blocks on your planned downtime. One key aspect of planning for maintenance downtime is that you must be prepared in case your planned downtime turns into unplanned downtime, and these technologies can be used to effect a quick recovery if that happens. From a broader perspective, disaster recovery planning (and the technology deployment that goes with it) should embrace the idea that you will sometimes need to make time for planned maintenance, and that such maintenance should be carried out without disrupting normal business operations.


10 tips in 10 minutes: Fundamentals of Exchange Server disaster recovery

 Home: Introduction
 Tip 1: Defining Exchange disaster recovery
 Tip 2: How Exchange backs up data
 Tip 3: Choosing a backup type for Exchange
 Tip 4: Online vs. offline Exchange Server backups
 Tip 5: Basic Exchange backup and restore
 Tip 6: Exchange vendor snapshots and point-in-time copies
 Tip 7: VSS for Exchange
 Tip 8: Exchange Server replication
 Tip 9: Exchange design choices and issues
 Tip 10: Exchange disaster recovery planning

This chapter excerpt from the free e-book The Definitive Guide to Exchange Disaster Recovery and Availability, by Paul Robichaux, is printed with permission from Realtimepublishers, Copyright 2005. Click here for the chapter download or download all available chapters here.


There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to: