Backup & Recovery Strategies

‘Data should be restorable’

Why do DR strategies fail? Where do companies go wrong in backup/restore processes? Ashwini Bhatnagar, Product Marketing Manager, Network Storage Solutions, Asia Pacific, Hewlett-Packard, talks to Brian Pereira about the best approach to backup and recovery strategies

What makes an effective backup strategy?

The entire purpose of backup is that data should be restorable. In many instances one may still lose data even after a successful backup. The second element is that there should be an "acceptable" duration of interruption while data is restored. The third element is the entire disaster recovery process has to be cost-effective.

Progressively, the other critical element is to make sure that you have established external system connections. Suppose there is an Oracle database and it connects to an exchange application in some way, those links need to be established at the planning stage. So when recovery is performed, these links are restored to their intended state, in time. If applications lose this relative coherence, they may end up with inconsistent data.

To progress on the continuum a possible progression would be:

• archival
• remote vaulting, or, taking the data offsite
• continuous access
• data replication

Why do most DR strategies fail? What should be done to prevent this?

Generally, the weakest link in a DR strategy for a company is that sometimes, backup is an afterthought. As a result, we are required to do a lot of fixing to get things to work even after a full data set has been recovered.

On the other hand, backup is thought of as "bottoms-up"—in other words you are going from the end to the means. A good methodology for this would be:

• Assessing the entire infrastructure
• What kind of backup strategies do I need to put in place?
• What are my system linkages?
• Even if I put those linkages in, what kind of risks do I run?
• How do I mitigate those risks?

This leads to a methodical project plan in which:

• At project initiation we do business impact analysis. Identify what is important, what is not (both process and data), and what is the cost of downtime?
• Look at the current physical and IT environment that the system is in.
• Then if we put these systems in place, what is the risk that things will go wrong?
• Decide on what are the strategies to mitigate the risks.

Finally go to the valuation and decision stage that allows project implementations, commensurate with the cost analysis.

How does a CIO justify ROI or payback on DR?

From a project costing perspective for DR, in many cases it's difficult to put a dollar value to the project. In many cases, the IT manager faces the challenge when they ask for investment from the CFO. However, once you are able to quantify a clear rupee value for the cost of downtime to business (through business impact analysis), it can help in assigning correct priority to competing projects in the budget.

How long does it take for ROI on storage backup?

The ROI for backup does not happen until you encounter a disaster and recovery scenario. At a project justification stage, you are saying it's important. We are saying this is the model how you derive a finite dollar value that needs to be put up for a DR infrastructure.

For any business application there is definitely a tangible dollar value. And, when that application is down, that's the money you are losing. Then there are the intangibles such as loss of reputation and loss of customers. There are established models to compute the dollar value as well. So basically, you have a model where the first element of it is to do a valuation of each process. As you'd expect, the cost of downtime increases exponentially as time goes by.

For technology to mitigate this loss there is an associated cost. This depicts that the cost goes up exponentially if you'd like to reduce the time associated with recovery.

With reference to the graph (below), where these curves cross, the cost of losing business is just about coming to be the cost of maintaining continuity. It's probably the fine balance you are trying to achieve. This is the best possible investment cost.

Unfortunately, in some cases, the business loss is painfully discovered only after a disaster, when the data set is lost forever.

Can you differentiate between the various backup/restore processes?

If you look at the backup and restore processes, they may appear similar, but in reality they are not.

"Backup to Restore" is, by and large, operational backup. It is done with the intention of restoring immediate recovery points. Possible examples are login or security databases, testing databases etc. So once you have restored that specific set of data, from a specific tape, the data set can be discarded. It's a constantly transient set of data.

The second type is "Backup to Retrieve". This is where you consider the archival aspect. There is a lot of interest around archiving now, especially because of the legislation that has come into force due to increased awareness in corporate governance. For example a rule like SEC 17a, NASD rules 3110/3010. Such laws are mandated in the US and are relevant for Indian companies that are involved in BPO or call centers. These companies may be subject to audit trial requirements as per US regulations.

This requirement of recovery is quite different from a normal operation recovery. It's coming from two aspects. First it says a record should be authentic or non-modifiable. Second, the record should be accessible quickly, once it is required.

Then there is "Backup to Resume". It is a business continuity concept that goes beyond the IT operations. It goes into succession planning, people aspects and the process aspects. Nevertheless, Data recovery is the central element of business continuity. Here's where business is looking at putting a DR framework or a data recovery framework that can complement the entire BC effort of a company.

So if you look in terms of cost and complexity, the most elementary state would be data duplication—in other words backup to restore.

Brian Pereira can be reached at brianp@networkmagazineindia.com