Developing Recovery Service Objectives (2 of 2)

30. Jul, 2010 0 Comments

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

The next service objective is the RPV (Recovery Production Volume). The relative volume capability projected following a disaster event. Many organizations do not address this critical component of recovery. How much data will be processed during the period after recovery? Will it be business as usual, or business as usual plus an extra day’s entry from lost data. Perhaps the nature of the business will result in a serious drop off in transaction volume. The nature of the business might equally result in a sudden increase in transactions immediately following a disaster. Again the business community is the appropriate body to weigh the factors and make this decision, and in making this decision they are determining just how much hardware is going to be needed for recovery based on these projected volumes; another decision having a significant impact on costs. RPV is typically expressed as a percentage. e.g. 80% indicates an expectation that business volumes in the post disaster period will approximate 80% of the business as usual figure. 120% would indicate an expectation of an increase of 20% in volume over business as usual.

Closely tied to RPV is, the recovered production efficiency or RPE. This service objective identifies the relative performance capability that will be provided in the period following a disaster. Many organizations identify development and test infrastructure to be repurposed for use in production following a disaster. Many organizations do not have the budget to provide 100% infrastructure equivalence in a lights out “just in case” recovery center. Under these circumstances it is critical to ensure the business user community is aware of any change in the performance they can expect in a post disaster period where recovery compute platforms might be initially recovered at a lower level of GHz availability. This is done by setting and publishing an RPE for each period after a disaster until capabilities return top pre disaster.

In a virtualized server environment, it is possible to bring back virtual servers on a limited physical infrastructure, albeit at reduced performance. In the days and weeks following a disaster, additional hardware can be added to the physical environment improving the performance of virtual servers to the point that they now equate with pre disaster capabilities. In this scenario we might find a post disaster RPE of 50% with 75% within 30 days and 90% within 60 days and 100% within 90 days of the disaster event.

Finally, RPL or recovered production life defines, or sets as a policy, the expected life of operation at the DR site. Thus if RPL is set at 6 months, then everyone involved is aware that a plan to transfer back to newly built or refurbished permanent production facilities must be developed and executed in the RPL time frame. This is particularly important where the DR site is provided by a 3 rd party under contract. The absence of an officially acknowledged RPL can result in lack of restoration planning and consequent punitive costs as expensive facilities intended for short term use are retained beyond contractual commitments.

For your DR Plan to be successful, your Recovery Service Objectives must be set with the business community, set using an empirical basis, and last but not least, the RSOs must be made visible and published to the business community so everyone :knows” the rules of the game..