Requires Free Membership to View
Backing up a bit, the main idea of business continuity and disaster recovery is: What must the organization do before, during and after a disruptive incident to ensure the business can continue to operate? What the organization will do and how it will consist of assorted processes and technologies that are outside the scope of this response.
Regardless, before you can determine your processes and select appropriate technologies, you need to perform a business impact analysis. This analysis will help you determine how long the business can afford to be without whatever service you are considering, as well as how much data the organization can afford to lose. This is precisely what RTO and RPO are.
An RTO is an assessment of how long a business feels it can be without certain services or systems before seeing negative effects. This can be a matter of minutes, hours or even days. It just depends on what the needs of the business are.
The flip side of this is an RPO. That is, in less fancy terms, how much data can be acceptably lost, which is also measured in time. Realistically, this translates into how many minutes, hours, days, etc., have elapsed since the last backup. This will depend heavily on what the data is and how critical it is to the business, just like RTO. This doesn't necessarily imply backup to tape, but can also be some sort of synchronization or asynchronies copy to another facility.
As mentioned previously, these decisions are driven by how much data and time the business thinks it can lose. This is generally done as a basic cost benefit analysis of how much can be lost versus how much will it cost to prevent that loss. Case in point, if your RTO and RPO needs to be under an hour, costs can easily go into the millions of dollars to architect a useable solution, whereas an RTO/RPO of 12-24 hours might hit the low hundreds of thousands of dollars. Again, this will depend heavily on the volume of data, how often it changes and how it is being handled.
For more information:
This was first published in August 2009
Security Management Strategies for the CIO
Join the conversationComment
Share
Comments
Results
Contribute to the conversation