Helpful Tips
Get to the information you want quicker by selecting a category name or a popular tag.

There are multiple ways to look at recovery time objectives (RTO – how much time we can be without) and recovery point objetives (RPO – how much we can afford to lose). If we look at it from a top (business level) down (IT level), there would be a similar concept to a simple criticality rating that may be indicated that eliminates portions of data (that support business functions) that are not “critical” and some that stays critical that would flow from the following elements:

  • Business Impact Analysis (BIA) that identifies business risk
  • Business Continuity Plan (BCP) that outlines recovery of business function (including IT as a business unit – mangement structure, procurement, etc.)
    • Recovery Point and Time Objectives for BC (Business Continuity)
  • Disaster Recovery Plan (DRP) for the recovery of technology to support the deemed critical business functions outlined in the BCP
    • Recovery Point and Time Objectives for DR (Disaster Recovery)
  • Application Matrix for coorelation between physical infrastructure with application functionality
    • Single Points of Failure for application matrix
  • Synchronization requirements for multiple data stores to eliminate corruption (i.e. different time stamps or multiple access point for shared data)

This describes how any Backup (Operational Recovery as I like to call it) system supports the business in the event of disaster and are longer due to the massive effort to focus on recovery of entire business unit(s), business location(s), and/or data center(s). One important item to note: backup / operational recovery is _not_ disaster recovery; however, every good disaster recovery plan has backup / operational recovery in it. So, this is one perspective of RTO / RPO, and it is separate from what is needed from a day to day or operational perspective. This is why I like to call it operational recovery.

Generally, the requirements for operational recovery are more stringent for individual servers and/or data stores (i.e. databases). This dictates that the RTO / RPO be looked at from a perspective of the losing a single file, set of files, individual server, or small subset of servers. You need to understand the following:

  • how often is the data changed?
  • how is the data used daily?
  • how many people are affected by the unavailability of the data?
  • how often is the data “refreshed”?
  • Is it data that originates elsewhere?
  • what are the up-line dependencies?
  • what are the down-line dependencies?
  • what is the size of the data set?
  • what is the nature of the data (structured, unstructured, otherwise)?
  • when might recoveries be necessary (off-production or production hours)?

These things must be coupled with the criticality factor to set the Operational RTO & RPO. Now the argument could be made that RTO and RPO are dictated by the “owner” of the data. While this may be how things happen in the real world, it is irresponsible for anyone to indiscriminantly set RTO & RPO without taking into account the above factors. I say this because many solutions ( ) can meet almost any RTO or RPO; however, the cost and delivery of such varies greatly ( Secondarily, the levels of service provided by an operational recovery system must be “standard” to allow for agility, predictive cost, efficiency, simplicity, rigor, and results aligned with the outcomes set forth in the strategy for the organization. Multiple tiers of recovery can be offered but must be standard in order to provide a level of muturity greater than chaotic or reactive.

I know that it is complicated when considering a wide open question about how to set RTO and RPO; however, the manner in which you deliver upon these is determined by factors outside of an administrators control, some of which is pure physics (i.e the speed of light, hours in a day, etc.). 

 Another side of the coin focuses on information security, information classification, and cybersecurity (  Whether the information to be recovered is confidential, proprietary, intellectual property, or never to be altered plays a part on recovery point and time objectives as well.  Much of what has gone awry with “backup” in the industry over the years has been the result of people overlooking some of the aforementioned basics (

Leave a Reply

You must be logged in to post a comment.