By Mike Talon
Before you develop a disaster recovery plan, and before you begin talking to your company's business continuity and human resources departments and vendors, you must take one very important step. You must first determine just what it is you're trying to protect—and how you'll define protection.
Aside from determining the differing levels of DR (such as data vaulting, high availability, etc.), you need to find out basic facts, such as service-level agreements, before you can begin proper DR planning. To begin this phase of your planning process, you need to talk to the owners of the individual data systems to determine two important factors for each system.
The first factor is the recovery point objective (RPO), which is the measurement of how much data the company can conceivably lose to a disaster of any level that won't significantly impact business. RPO is a tricky factor to judge; nearly everyone in charge of a data system will first insist the RPO is zero bytes of data loss.
However, once people find out the prospective cost of the type of protection systems required for zero bytes of data loss, most managers quickly come up with more realistic RPO estimates. For example, since any Windows-based application must be able to withstand the loss of everything in the page writer cache, the RPO of a Windows-based system could be surprisingly large.
This isn't to say the company won't have applications that do require an RPO of zero bytes lost. For example, Linux and UNIX-based systems—especially financial applications—may require this level of protection.
Hardware-based solutions can offer this level of recovery, but they're exceptionally expensive. Therefore, for budgetary reasons, you must thoroughly justify the cost before deciding to implement them.
The second factor you must define is the recovery time objective (RTO), which is the amount of time any system can remain offline without significantly impacting business. Once again, budgetary concerns will primarily determine your decisions. While you can have instantaneous failover for many systems, managers must make a very good case to cover the cost.
Most applications can easily withstand larger RTOs than you might imagine, mainly due to the complexities of end users. Except for lower-level emergencies, your end users will most likely be unable to access the data systems from their original terminals. This means you'll have quite a bit of time to failover the systems while end users restore connectivity or move to a new location.
After determining the RTO and RPO of individual data systems, you can begin the process of determining which tools you'll need to implement to meet these needs. You'll probably need to use more than one type of DR solution, both hardware-based and software-based in addition to traditional tape backup resources.
Performing an analysis beforehand allows you to determine which systems require which solutions so you don't waste budget funds on systems that don't require more expensive solutions.
Mike Talon is an IT consultant and freelance journalist who has worked for both traditional businesses and dot-com startups.