How to partner for disaster recovery. (Tape/Disk/Optical Storage).

As IT budgets become more constrained, yet the need for disaster recovery solutions continues, systems integrators are finding it harder to. engage in these mission critical projects. In this article, we will look at a few ideas to help in this worthwhile cause.

* First, every project begins and ends with ROL and a sponsor.

* Somewhat related to that, "being a partner" should .be mutual.

* And last, there are alternative technologies that you may be less aware of, but will meet your clients' goals better and more cost effectively than the normal tool set.

As a disclaimer, everybody has his own opinions on these matters--so always test these ideas against your own experience.

Sponsors and ROI 

One of the ironies of business continuity projects is the difficulty in properly identifying the executive sponsor and justifying the Return on Investment (ROI) of the project. Disaster preparedness is something that most employees would agree "the company should do." This is analogous to a few people standing around the water cooler and saying, "They should do something about that." The challenge is figuring out who "they" are.

With most IT decisions, one rarely has to reach higher than a technology professional, except for high budget items. In fact, even the disaster recovery of one's IT infrastructure may only have to be approved at this level. But for real business continuity plans, it is as much about process, procedure and people as it is about technology. The result is that senior IT staff recognize that they cannot own the entire scope of the project--and yet no one seems sure who should. Consequently, many business continuity plans die in their infancy from a lack of executive support.

As a suggestion, find the executive who has the highest authority over IT decisions. Then, identify his peers who are responsible for the business units that generate profits. Those individuals are the ones who can most easily visualize a loss of productivity and profitability during any kind of crisis. The other individual to identify is the person responsible for the company's bottom line. Either of these types of individuals is a good choice for your "sponsor," because they understand the implications of an outage.

At this point, you have at least one individual who is concerned or anxious about the possible losses during a crisis. And since data, or technology in general, is a key to preparedness, you've also already identified the IT person who will either be the hero or the scapegoat. One way or the other, you now have a sponsor.

Start With the Business Impact

The other part of the burden is determining the ROI for a business continuity effort. This again comes back to everyone knowing that they need protection, but not understanding how badly or to what extent. ROI is effectively how quickly you can recoup your project costs. To understand that, we must first understand how much the problem costs before we can compare that to a solution cost. There are a few easy metrics to help with this.

For any given server, you need to measure the productivity impact if the server were turned off. If 60 people across one department would be unable to work, then the math is easy. If this were a call center or other type of hourly wage mass workforce, then 60 times the average worker rate is the "downtime per hour." For salaried environments, it may be easier to. ask accounting what the monthly payroll number is for the department and divide that by the number of working hours. For environments that could do other tasks and therefore would be impacted only "X" percent, use that as a multiplier. If none of these figures is available, get the industry standard hourly rate. One recent figure that I use quoted "the average white-collar American costs $36/hour to their company." So now you have a quantifiable business impact for lost productivity.

* If a given server or department is profit generating, then divide the average monthly gross revenue by the number or working hours for the business impact for lost profitability.

* If a given server or department is not profit generating, and they are a support organization, this data cost may be harder to assess. So look at how they support the profit model. As an example, a shipping department does not generate revenue; but if a company cannot ship what it has sold in a timely manner, it will soon stop selling.

With not much effort, it is very easy to quantify the business impact of any outage. Then, looking at the frequency of outages over a given time period will help a company understand its level of risk.

From there, if the company executives can decide on the tolerable levels of impact (e.g., four hours of downtime with less than one hour of lost data), then you have the parameters of what a solution must deliver. Dividing the annual business impact by the projected solution cost will give you the ROI on your proposed solution. As an example, if a company's financiers are focused on each quarter, then any solution with an ROT of up to three months is an easy sell. An ROL of two quarters might be reasonable. And an ROT of three quarters starts looking foreboding--until you remember that these types of solutions typically have a multi-year life. So the solution costs might be recouped over 9 to 12 months, with the guarantee of no impact for the next two years. Now we have a very attractive ROT proposal again.

So, find the person who will feel the weight of a potential crisis (the sponsor). Then, help him understand how great that weight is (the business impact) and show him how easy it is to avoid that weight (the ROI).

Being a Partner

As a related point, if you truly wish to be your client's partner in this endeavor, then expect to be treated as a partner (as opposed to a self-serving vendor). This kind of project is not about your client wanting to do you a favor by purchasing some of your wares. He needs this protection. You are providing him a way to ensure that his business survives, while he is providing you a livelihood. It is a symbiotic or mutual relationship.

One way to test whether a client views this as a partnership is by the level of information that he is willing to share. If he truly believes he needs this protection, then he will want to share it--and will need to justify it. Because your client may not have participated in this level of business impact analysis before, he can use your expertise in understanding where to look to find the metrics. If he is sharing, then you are partners. if he is not sharing, or the process appears more like a job interview, then in some ways you may still be looked upon as a vendor trying to sell.

To balance out this idea of partnership," you should recognize that no matter how good your intentions--their business continuity plan is theirs. In the event of a crisis and if the plan works, they are heroes and you may get some credit, if the plan fails, they failed and you may also share some grief. But it is admittedly the client's survival at stake--unless, of course, you have provided some financial guarantees to the project (which is probably outside of the scope of this article).

New Technology?

Let's discuss technology. It is not an accident that this article spends time discussing the client relationship and the analysis of his environment. Really and truly, until then, no solution is appropriate. But now that we understand our client's needs, we must consider that there are alternative technologies that may be better suited to your customer's needs.

In the disaster recovery space, and particularly for Microsoft Windows environments, host-based software replication seems to satisfy a wide variety of customer needs. The alternatives to this technology often fall to both edges of the recovery spectrum (i.e., tape backup and/or synchronous hardware).

Tape backup, although relatively inexpensive, often takes too long to restore and (at the end of the restoration window) the data is usually days old. As an example, consider if a primary server failed at 4 p.m. on Tuesday afternoon. Components could be expedited on Wednesday morning and if the restoration began in the afternoon, users would begin working by Thursday morning--with data as it existed on Monday night's backup. Tuesday's data would be lost. And Wednesday would have had limited productivity, at best.

If off-site tape couriers are used, Monday's tape might have been off-site, which adds an additional day before the restore could have begun. To imagine an even worse scenario, consider if the environment does a full backup only on weekends (and incrementals during the week). If something were wrong with that weekend's backup, the data loss and restore efforts would both reach back through the entire previous week.

Synchronous hardware (coupled with a clustered front end) can provide zero data loss and less than minutes of downtime--but at a significant cost. Proprietary storage costs would be doubled, along with additional fabric and mirroring software. The front end would require two new cluster-able servers and application licenses. And additional expertise is often required to maintain the solution.

Somewhere in between is where most companies need to be.

Software-based replication, such as NSI Software's Double-Take, captures byte-level changes to the files of a Windows server as they occur. Then, in as close to real-time as the network will allow, those delta changes are then sent to a target server.

Because the file changes are captured at the OS level:

* Software-based replication is application independent. Whether the application is Exchange, Oracle, or user-directories, a byte-level file change is the same. This means that an environment can have one data protection strategy, regardless of the applications involved, with just one management system, feature set and technology partner.

* Software-based replication is hardware independent. Regardless of the client's previous investment in servers and storage (e.g., IBM, HP, Dell, EMC, etc.)--if the source and target platforms are running the Windows server OS, then the data will be protected. This is unlike the requirement of proprietary hardware and fabric that was presented earlier.

* Software-based replication transmits less bytes than other technologies. This is obvious over whole-file strategies, but is also true for block-level approaches. if an application were to write 150 bytes, software replication would transmit 150 bytes. Hardware replication would transmit the block (4KB to 64KB) that those bytes are stored on. This directly impacts bandwidth requirements and therefore the continuing cost of the solution.

Being able to leverage existing hardware and infrastructure with a software solution, the cost is close to tape backup with most of the benefits of mirrored hardware. This brings us back to our earliest point in this article--ROI. One can already appreciate that a business impact analysis of almost any customer will show the calamity of a major crisis. By offering software-based replication, the solution cost may appear as only a small percentage increase over and above a tape backup strategy. But in simple math, a big number (impact) divided by a small number (solution) will show an ROI that often surprises clients. Combine that with the recognition of lower TCO, due to less expensive bandwidth requirements and no additional expertise requirement, and you now have a scalable and cost-effective solution.

Jason Buffington is the director of business continuity for NSI Software (Hoboken, N.J.)

www.nsisoftware.com