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.
Article Source: http://EzineArticles.com/?expert=Paul_E_Moore
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.
Article Source: http://EzineArticles.com/?expert=Paul_E_Moore
No comments:
Post a Comment