Developing Recovery Service Objectives (1 of 2)

23. Jul, 2010 0 Comments

Developing Recovery Service Objectives

Recovery Service Objectives (RSO) are the publicly visible service commitments that dictate the infrastructure needed to deliver the DR Service Offerings.

In previous blogs we covered the empirically based Business Impact Analysis or BIA. The BIA process provides us with the tangible cost to the organization should a business unit be unable to operate. Now we need to develop recovery service objectives (RSO) that are based on our knowledge of the financial impact of disaster. RSOs spell out the attributes that govern disaster recovery operations; e.g. how quickly recovery will be executed, how much data will be recovered, and the volume and performance expectations of the recovered applications. RSOs are a key driver of the costs of disaster recovery protection.

RSOs consist of five key components; RPO (Recovery Point Objective), RTO (Recovery Time Objective), RPV (Recovered Production Volume), RPE (Recovered Production Efficiency) and RPL (Recovered Production Life)

RPO is the attribute that calls out the maximum data loss that can be tolerated without unacceptable impact. This is typically measured in hours or days. An RPO of one hour means that the data must be protected such that any loss of data is constrained to the last hour before the disaster. RPOs can also be subjective judgments made by the business unit manager or the business unit liaison staff based on their knowledge of the Business Impact Analysis and a good feel for the operational nature of the business function. A more scientific basis for RPO development is to specifically link data loss to dollars. For example, if $523,000 in orders arrive over the web every hour, it is easy to understand the impact of data loss from one minute to one day. This may already have been accounted for in a typical BIA. It is always best to set the RPO in a formal team workshop that includes the business unit users, application development, and the data base design team.. Typically this team will know how data arrives and is processed as well as being close enough to the business to understand the impact of one day’s data loss compared to one hour.

RTO (Recovery Time Objective) is the maximum tolerable time that a business unit can be without its applications, or, to frame it another way, the maximum amount of time permitted to recover an application after a disaster event. RTO is also typically expressed in hours or days. Now this RSO too can be subjective. We should know from the BIA the loss of dollars that may occur from permanently lost new customers, a percentage estimate loss of major accounts, and a percentage loss of formally loyal smaller customers. Consider too the business volumes. In some organizations, the business volumes are so significant that catching up after an outage can be not only difficult but very expensive. If additional staff needs to be brought in and trained to handle the backlog a significant recovery cost can be anticipated and calculated accurately on a per hour basis. Again it is critical to involve your business user community in the decisions that determine the RTO, and it is critical that the cost of this decision is made apparent during the discussions. Not only should solid information from the BIA be available, but you will also need the mitigating data on cost per GB of storage and cost per CPU of the processing infrastructure needed to support the RTO decision. A subjective choice of RTO without the cold water effect of the cost of that decision can lead to recovery costs out of alignment with real business impact.

By Dick Benton, Principal Consultant