Backup & Recovery Strategies
Data should be restorable
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:
- remote vaulting, or, taking the data offsite
- continuous access
- data replication
Why do most DR strategies fail? What should be done to
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
- 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
- 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
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 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
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
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
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 duplicationin other words backup to restore.
Brian Pereira can be reached at firstname.lastname@example.org