What Is the Difference Between RTO and RPO?
I often get asked the question "What's the difference between RTO and RPO?"
The answerer is never as mysterious as if would first appear. But let's step back only a little and know what the terms RTO and RPO actually mean first.
RTO, or Recovery Time Objective, is basically the most amount of time a company are able for something 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 wished to be covered by a "Disaster Recovery" service and subscribed to usually that which was called 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) could be made available for use, typically within four hours. After this you had to incorporate the time to get at your website where the computer system(s) were located (or wait if they were being sent to a website of your choice) and restore using a backup of some sort, usually tape; assuming they had not been lost in the disaster (not as uncommon as you might think!). This will usually be accompanied by user acceptance testing (UAT), and finally handed over as a live system.
If all went well, which will depended on how well the recovery plan had been tested, the necessary system(s) could be available within 24 hours of the incident (or T+24). This will 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 may have a notably longer RTO; this is in which a sound Threat Assessment and Business Impact Analysis (along with budget) would assist in determining which systems and applications could be covered (please see my other articles for information on Threat Assessment and Business Impact Analysis for more information).
RTOs can range from zero to weeks, learn about compliant resources (or even months) with regards to the criticality and budget of the business concerned. It's quite acceptable to own different RTOs for individual systems or applications according to criticality and risk appetite. I will soon be covering risk appetite in increased detail within my BS 25999 articles.
Right, now we know what RTO is we can look in increased detail at RPO.
RPO, or Recovery Point Objective, is basically the state or point a company believes it takes to recuperate to to be able to keep on business following an unplanned interruption. RPO really shows just 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 cash you should spend. For instance, many financial institutions have split site operations, or data replication, in which a dedicated infrastructure will give very short, or even zero RPOs and RTOs. Let's look in a tad bit more detail what defines the RPO.
The majority of backups are still carried out daily, or twice daily. For example, should you a single daily backup at 18:00 and one's body increases in flames at 05:00 the following day, everything that's changed as your last backup is lost! When you yourself have a regime of daily backups you are essentially accepting a RPO as high as 24 hours (assuming everything is copied and you have the ability to restore in the event of a disruption).
When developing your Business Continuity Plan you will define what the most RPO you can (or will) accept for every single defined area. Remember, the shorter RPO, the more cash you should spend. Not everyone are able data replication, combined with associated infrastructure costs, such as for example network, computer systems, facilities, staff, management, etc, etc, which can be connected with this kind of solution.