I often get asked the question “What is the difference between RTO and RPO?”
The answerer is not as mysterious as if would first appear. But let’s step back a little and understand what the terms RTO and RPO actually mean first.
RTO, or Recovery Time Objective, is essentially the maximum amount of time a business can afford 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 dictated by budget. Basically you decided which computer system, or systems you wanted to be covered by a “Disaster Recovery” service and subscribed to usually what was described as a “Warm Recovery” (again, see my article on Disaster Recovery or Business Continuity).
When the service was required (or invoked) following a disruption the computer systems(s) would be made available for use, typically within four hours. You then had to add the time to get to the site where the computer system(s) were located (or wait if they were being delivered to a site of your choice) and restore via a backup of some sort, usually tape; assuming they had not been lost in the disaster (not as uncommon as you might think!). This would usually be followed by user acceptance testing (UAT), and finally handed over as a live system.
If all went well, which usually depended on how well the recovery plan had been tested, the required system(s) would be available within 24 hours of the incident (or T+24). This would be defined as having a RTO of 24 hours for the chosen system(s) and applications(s).
Obviously systems and applications not covered by the Disaster Recovery contract could have a significantly longer RTO; this is where a sound Threat Assessment and Business Impact Analysis (along with budget) would assist in determining which systems and applications would be covered (please 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 criticality and budget of the business concerned. It is quite acceptable to have different RTOs for individual systems or applications depending on criticality and risk appetite. I will be covering risk appetite in more detail in my BS 25999 articles.
Right, now we know what RTO is we can look in more detail at RPO.
RPO, or Recovery Point Objective, is essentially the state or point a business believes it needs to recover to in order to carry on business following an unplanned interruption. 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 the shorter the RTO and RPO, the more money you will need to spend. As an example, many financial institutions have split site operations, or data replication, where a dedicated infrastructure will give very short, or even zero RPOs and RTOs. Let’s look in a little more detail what defines the RPO.
The majority of backups are still carried out daily, or twice daily. For example, if you do a single daily backup at 18:00 and your system goes up in flames at 05:00 the following day, everything that has changed since your last backup is lost! If you have a regime of daily backups you are essentially accepting a RPO of up to 24 hours (assuming everything is backed up and you are able to restore in the event of a disruption).
When developing your Business Continuity Plan you will define what the maximum RPO you can (or will) accept for each defined area. Remember, the shorter RPO, the more money you will need to spend. Not everyone can afford data replication, along with the associated infrastructure costs, such as network, computer systems, facilities, staff, management, etc, etc, that are associated with such a solution.
I will cover Split Site, Data Replication and Hot Recovery in another article.
So, put simply, RTO is the amount of time that a system or application is unavailable following a disruption, and RPO is the amount of data you would lose.
For more information visit EMA Continuity
Source by Paul E Moore