Why We should Set Recovery Objectives before Recovery Strategies?

In this article we discuss the need for setting recovery objectives before we formulate our backup and recovery strategy.

Before defining the backup and recovery process for SQL databases in your organization, you need to first formulate your recovery objectives. Key component in Database recovery solutions is the Redundancy of Data. All the transactions taking place in your SQL Server instance are applied to the secondary storage synchronously or asynchronously. During an outage, an online transaction may become unavailable or get lost in one of the secondary instances. This happens mainly because of delays in the process of data application. You can not only measure the impact, but also set recovery goals, by defining how much time should it take to begin operations, and the time latency between recovered transactions. Here are a few components you should keep in mind during Recovery Operations.

1. Recovery Time Objective – Shortened to RTO, this refers to duration of outage. The primary objective is to get the system online. Even if in a read – only capacity, this is done to understand the causes of failure. The main objective is to restore full services, so that new transactions can be made.

2. Recovery Point Objective – Shortened to RPO, this is the acceptable limit of data loss. It can be defined as the time gap or the period of latency between the last saved data transaction initiated before the failure and the current data point recovered after the failure. The amount of data lost usually varies on the amount of workload the system is operating under, at the time of failure. What also needs to be noticed is the type of failure, and the high-availability solutions attempted.

Both RTO and RPO can be used as goals defining a business’ tolerance for downtime and what is the limit for acceptable data loss. They are appropriate metrics for monitoring health of Availability.

Downtime will always cost you, either in monetary terms or in terms of customer goodwill. The cost might have to be paid all at once, or at different points in time in outage window.

The following should be included in the planning process:

1. Avoiding Downtime – The recovery cost of an outage can be saved if there is no outage at all. Investment covers cost of redundant hardware, distributing the workload across different points of failure and planned downtime for the purpose of maintenance.

2. Automating recovery – In-case of a system failure the effect of downtime on the service experience can be reduced through automatic and transparent recovery.

3. Resource utilization – It is alright for Secondary infrastructure to sit idle and await an outage. The user might also choose to use it for read-only workloads, or to distribute workload to the available hardware, leading to an improved system performance.

For the above mentioned RTO and RPO goals, the required availability and recovery investments, along with estimated costs of downtime, can be explained as a function of time. At the time of an outage this will enable administrators to make cost based decisions depending on the downtime duration.

Your Recovery Strategy should Factor in Situations where a Restoration Process may Fail

At times incidents of restoration failure occurs due to a corrupted backed up file. In such a situation you would have to run a powerful sql recovery tool like DataNumen SQL Recovery to extract the contents from the messed up file. Designed to handle even the most intricate logical errors, this remarkable tool can effortlessly recover all stored records within a short span of time. Moreover it can even attempt a recovery from a backed up SQL file present on a virtual disk or removable media drive.

Author Introduction:

Alan Chen is President & Chairman of DataNumen, Inc., which is the world leader in data recovery technologies, including access recovery and sql recovery software products. For more information visit www.datanumen.com