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
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
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.