The Recovery Time Objective (RTO) for an application is the goal for how quickly you need to have that application’s information back available after an "event" has occurred that stops the application.
The Recovery Point Objective (RPO) for an application describes the point in time to which data must be restored to successfully resume processing (often thought of as time between last backup and when an “event” occurred).
The RTO and RPO metrics are useful in discussing what technologies, products, processes and procedures are required to meet those objectives. Setting the objectives should come from looking at the business impact of applications being unavailable, and the business impact of loss of data.
The time to recovery from any failure cannot be fixed as a specific time. Recovery time has a probability density distribution. The definition of RTO for a particular installation needs to include an assumption about what % of the time that the RTO is achieved.
RTO Example: The email application has a RTO of four hours (90% confidence) means that recovery from a failures can be achieved within four hours for 90% of all failures.
Similarly, RPO is also not a fixed amount time that data is lost.
RPO Example: The email application has a RPO of 12 hours (90% confidence) means that recovery from a failures will be able to go back to a recovery source that is less that 12 hours old for 90% of all failures.
Calculations of the cost benefit analysis of setting Recovery Time and Recovery Point Objectives need to take into account their probability density distributions, and make clear the assumptions used.
--DavidFloyer 14:22, 12 October 2006 (CDT)