BUILDING A DISASTER RECOVERY PROGRAM for your data warehouse is a huge task. Think about it: You are charged with creating a contingency plan that, if necessary, must be capable of restoring as much as 100% of the data and systems you rely on every day. That means this job requires nearly as much attention to detail as the data warehouse did in the first place, and it is no less important.

Even under the best of circumstances, it's tough to devote enough resources to the task at hand, to convince management to give you the necessary funding and to keep up with the constant growth of the data warehouse itself.

Very few businesses today have the financial luxury of developing a fully redundant, completely mirrored disaster recovery program all within one budget cycle, so when you ask for full funding, management balks at the price. Yet the need for such a system is growing, along with its importance to the business. You know it, the users know it and management knows it. It's a quandary, to be sure, but what can you do?

The answer, of course, is to build it one step at a time. But which step is first? How do you decide where to start? The answer is a Business Impact Analysis (BIA).

What's it worth to you?
BIA is a term used by disaster recovery professionals to describe the process of determining which applications are most valuable to your business. By identifying mission-critical applications, you get a clear picture of where you should begin your disaster recovery process. But again, you face uncertainty because every user is going to tell you that all of his or her data or applications are mission critical.

Is there an independent, unemotional way to measure value? In the business world, that measurement tool is financial value. A BIA-whether completed through a formal program using external consultants or handled internally-calculates the revenue loss or other costs to the business if each application is unavailable for some period of time.

You can begin with a 24-hour window and ask what would happen to the business if the warehouse were unavailable for 24 hours. What are the revenue losses (or other costs) that would occur? Capture those results with help from your end users. Then move on to 48 hours, 72 hours, a week, a month and so on.

When the BIA is complete, you can group the revenue-generating, business-critical applications into various windows of time, where a priority classification is assigned based on the financial impact the application has on the business-not on which users scream the loudest.

Figure 1 shows one way to categorize the BIA results. In this example, the BIA results populate the top four rows-Recovery Timeframe, Financial Impact, Customers/Users and Applications. Once this is completed, you should consider Support Requirements, which include items like networking needs and ETL requirements, as well as Other Dependencies, such as source data and vendor support. While these last two rows might not have a direct financial impact to the business, they are essential to ensuring that critical applications and users in each priority class are operational during a disaster.

Not every application has the same financial impact for every business. Let's use inventory management as an example. For a retailer, company revenues could be impacted in as little as 24 hours if the loss of an inventory management application causes store shelves to be left unstocked each evening. Yet for a manufacturing company, a similar inventory management application might only result in lost productivity, not lost revenue associated with the sale of the goods. As a result, this application could be categorized in Class 2, rather than Class 1.

Once you understand your business's recovery priorities, you can develop disaster recovery programs around mission-critical applications-those with greatest financial impact in the shortest period of time. As new applications are added to the warehouse, or as existing applications take on greater priority, you can add them to the disaster recovery program. This multi-step approach gives management the opportunity to fund a portion of the disaster recovery program within each budget cycle.

Know your recovery options
So now that you know which application(s) are most important, how can you determine which disaster recovery solution is right for your business? There are three distinct recovery options (Figure 2), categorized by how quickly they recover the system and critical applications.Starting on the right is Recovery Post-Disaster, which means you purchase all the necessary capabilities after a disaster occurs. With this approach, the only "pre-disaster" funds that are spent are used to develop a disaster recovery plan. When a disaster occurs, you locate an alternate facility, purchase the necessary hardware, install it and then restore your applications from backup tapes, which are by now 60 to 90 days old. While this solution serves a valuable role in your entire disaster recovery plan, it is only viable for low-priority applications.

The next option is using a Recovery Center, which offers an affordable solution for applications that can be out of service for several days before the business is impacted financially. Teradata offers three Recovery Centers-in Dayton, Ohio; San Diego, Calif.; and London, United Kingdom. With a Recovery Center agreement, you have access to Teradata-owned equipment and resources when a disaster occurs. Your investment is limited to only the equipment and services you need and contract for.

With a Recovery Center agreement, which typically spans three years, you have the ability to test your disaster recovery plan once a year, something you can't do with a "Recovery Post-Disaster" approach. Teradata Certified professionals build your recovery configuration-including the right versions of the operating system and Teradata software. For both testing and disaster recovery, your responsibilities typically begin with restoring data from backup tapes.

If you purchase Teradata consulting services to perform many of the recovery activities, such as upgrading your recovery configuration or performing tape restores, you might find that you can reduce the recovery timeframe even further and/or reduce the overall disaster recovery costs. Depending on the amount of data to restore, your system could be operational in two to four days-a significant improvement over Recovery-Post Disaster-at a fraction of the cost of a fully redundant system.

Finally, there is the Dual Systems approach. This solution gets your systems up and running within a few hours or less. With Dual Systems, you own and operate a second Teradata system in a separate facility. This second facility could be at a Teradata Recovery Center, if your company does not have multiple data centers at its disposal. The two Teradata systems are synchronized at the application and data level for the highest-priority applications. Because Teradata's data synchronization techniques do not require you to have a completely mirrored system, the alternate system can be a single node or a massively parallel processing configuration, depending on your BIA results.

With the addition of Teradata Query Director software (available with Teradata Warehouse 7.1) or a commercial load balancer, you can enhance the business value of the second system by using it for productive work. If properly designed, the Dual Systems approach can also help you address other availability issues, such as performance constraints during peak usage periods, shrinking backup windows and/or shrinking planned downtime windows. By solving multiple business problems with one solution, you increase business value, which increases the likelihood that management will be willing to invest in disaster recovery.