What is the difference between RTO and RPO?
I am often asked “What is the difference between RTO and RPO?”
The one who answers is not as mysterious as if it appeared for the first time. But let’s back up a bit and understand first what the terms RTO and RPO actually mean.
RTO, or Recovery Time Objective, is essentially the maximum amount of time a business can allow for a system or application to be unavailable.
In the early days of Disaster Recovery, before business continuity was really considered in much detail (see my article on Disaster Recovery or Business Continuity), RTO was largely determined by budget. You basically decided which computer system or systems you wanted covered by a “Disaster Recovery” service and subscribed normally to what was described as a “Hot Recovery” (again, see my article on Disaster Recovery or Continuity commercial).
When service was required (or invoked) after an outage, computer systems would be made available for use, typically within four hours. Then you had to add the time to get to the site where the computer systems were located (or wait if they were being shipped to a site of your choice) and restore using a backup of some kind, usually on tape; assuming they weren’t lost in the disaster (not as uncommon as you might think!). This would generally be followed by a User Acceptance Test (UAT) and finally delivered as a live system.
If all went well, which generally depended on how well the recovery plan had been tested, the required systems would be available within 24 hours after the incident (or T + 24). This would be defined as having a 24 hour RTO for the chosen systems and applications.
Obviously, systems and applications not covered by the disaster recovery contract could have a significantly longer RTO; This is where a robust Threat Assessment and Business Impact Analysis (along with the budget) would help determine which systems and applications would be covered (see my other articles for details on Threat Assessment and Business Impact Analysis for more information).
RTOs can range from zero to weeks (or even months) depending on the size and budget of the business in question. It is quite acceptable to have different RTOs for individual systems or applications based on criticality and risk appetite. I’ll cover risk appetite in more detail in my BS 25999 articles.
Okay, now that we know what RTO is, we can look at it in more detail in RPO.
RPO, or recovery point objective, is essentially the state or point at which a business believes it needs to recover to continue business after an unplanned outage. RPO really shows how much data loss you can afford. Your initial reaction might be that I can’t afford to lose any data, but remember that the shorter the RTO and RPO, the more money you’ll have to spend. For example, many financial institutions have split site operations, or data replication, where a dedicated infrastructure will provide very short or no RPOs and RTOs. Let’s look in a little more detail at what defines RPO.
Most backups are still done daily or twice a day. For example, if you perform a single daily backup at 6:00 PM and your system catches fire at 5:00 AM the next day, everything that has changed since the last backup will be lost! If you have a daily backup regimen, you’re essentially accepting an RPO of up to 24 hours (assuming everything is backed up and you can restore in the event of an outage).
When developing your Business Continuity Plan, you will define what is the maximum RPO that you can (or will accept) for each defined area. Remember, the shorter the RPO, the more money you will have to spend. Not everyone can afford data replication, along with the associated infrastructure costs, such as network, IT systems, facilities, personnel, administration, etc., etc., that are associated with such a solution.
I’ll cover split site, data replication, and hot recovery in another article.
So simply put, RTO is the amount of time that a system or application is unavailable after an outage, and RPO is the amount of data it would lose.
For more information visit EMA continuity