As we roll into another hurricane season, many local information technology professionals turn their concern to disaster recovery. What are we going to do in case a big hurricane hits? How are we going to keep our systems running? Where do we start?

Actually, for many, that last question is often the most daunting. Where to start? This initial paralysis often prevents many from developing, implementing and testing a disaster recovery plan.

The fact of the matter is that a good disaster recovery plan takes into account the business needs of the organization first. Toward that end, all of the critical and important systems of the organization need to be defined. This must include representatives of business units; it cannot be a task done by IT folks alone.

Then for each system, two factors need to be defined. The first is the amount of time the organization can tolerate before the system needs to be up and running. The fancy name for this is the recovery time objective (abbreviated as RTO, because we love our acronyms). For example, how long can our accounting system be down? How long can we go without access to email?

The second factor is called recovery point objective. In plain English, RPO is that point in time to which you can effectively restore your system. Typically, this will be the date and time of your last good backup (or set of backups).

One can see how these two factors go together. If our RTO is 24 hours and our RPO is 48 hours, that means that we’ll be OK if the system comes up in one day, with data that are 2 days old.

Simple, right? Well, of course, there is that nagging issue that must be taken into account: cost. The desired RTO and RPO almost always come with a cost. That is, to achieve the objectives, you have to invest in your infrastructure, such as upgrading or buying new servers, tape drives, cloud-based services and the like.

In our example above, we want RTO of 24 hours and RPO of 48 hours, but what is that going to cost? This can be a very difficult decision, especially when planning for events that are as unpredictable as natural disasters. It is almost a chicken-and-egg scenario: Do we define costs first and then RTO and RPO, or do we define the objectives and then the costs?

The truth is that there is no right answer. This needs to be an iterative process, which can be frustrating at times.

John Agsalud is an IT expert with more than 25 years of information technology experience in Hawaii and around the world. He can be reached at johnagsalud@yahoo.com.