When disaster strikes naturally or due to a man-made error, the time to recover can make all the difference between continuity and closure for small and medium businesses. Businesses that have not taken note of this factor at the point of designing a data backup and recovery system are bound to experience the pain of failure. A good backup storage design pays a lot of attention to time to recover. This is especially important if the backup and recovery system makes use of online resources for backup and storage of mission critical data.

All time to recover definitions relating to backup and recovery of data, must begin with an articulation of Recovery Point Objectives (RPO) and Recovery Time Objectives (RTO).

The recovery point objective describes the amount of acceptable data loss that can be measured in time. For instance, if the Recovery Point Objective (RPO) of a company facing disaster is two hours, then the data must be recovered in two hours. Any overflow of time to recover is an unacceptable data loss. Any data loss that occurs within the two hour RPO is an acceptable data loss. Sadly, most organizations are unable to state clearly their satisfaction level around the recovery point objective.

Fortunately, it is possible to calculate the RPO for a specific replication element using tools that have been designed for this purpose.

Normally, RPO of a backup and recovery system is measured in time (typically in seconds) or dirty tracks (tracks that were changed in the master copy, but not in the replica). The RPO for an entire backed up data set is measured using the lowest common denominator of all physical elements protecting the logical data set. For instance, if there are 10 volumes of backed up data in disks, there is a need to understand which volume contains the database and to send out a request for information about the RPO in each volume and then use the highest number returned to calculate the RPO. The process can be rendered more complex if all physical volumes have not been replicated at the same time.

Once the RPO has been defined, the Recovery Time Objective (RTO) can be calculated to optimize the design of the data backup and recovery strategy. This parameter is often established during the business impact analysis by process owners and accepted by the management.

RTO is the duration of time and the service level required for business recovery. The recovery time objective will include time that is used up for fixing the problem without recovery, the recovery itself, tests and communication between users of the system. However, decision time is not included in this calculation. This time line often runs in parallel to the incident management timeline and may start simultaneously or somewhere along the incident management time line. The unfortunate reality is that RTO strategies that are selected, often, do not match the RTO that is defined at design time.

Organizations can, at best, hope to approximate to the strategy and retain the objective for future strategy revision.

It is evident that RTO and RPO have a significant role to play in the design of the backup and recovery system. These parameters define the kind of redundancy and backup infrastructure that needs to be put in place to ensure that the time to recover is ideally suited for the business. It is also apparent that the tighter the RTO and the RPO, the more expensive the backup and recovery system that will be designed to suit your requirements.

SecurStore provides a bespoke offsite backup solution catered for customers who have both mission critical data and non-critical data i.e., it provides customers with a secure & efficient backup and recovery solution which is sustainable over time. This coupled with agentless technology and advanced support for all environments and applications makes it suitable for any type of business, data centre provider or reseller.