RTO & RPO are two non-functional requirements that affect the business continuity management. While RTO has much broader impact, both of these factors should be determined objectively based on the need and cost factor in mind.
I am currently reviewing non-functional requirements for a project I am working on and the topic of Recovery Time Objective (RTO) and Recovery Point Objective (RPO) came up. While both RTO and RPO talks about business continuity, there are subtle differences.
RTO determines how quickly a system can recover in case of a disaster. The shorter the time span, the more investment is necessary to recover from an incident. For instance, if the RTO is 60 minutes, backup systems should be ready for a seamless switch over. System configurations should be transparent & decoupled to enable this – meaning, no hard-coding of servers in configuration files etc. Systems should also be replicated at memory and database level to achieve this. Compare this with an RTO of 1 day which provides enough time for switch over manually and the investment is very low. Ofcourse, for today’s production systems an RTO of one day is unacceptable. The point is, if your client is bent on reducing the RTO, they should also be ready to loosen up their purse strings.
RPO on the other hand indicates how much work can you affort to lose. For instance, if your system writes to a data store, is it tolerable to lose one hour of work, or four hours of work? The number of hours here is the RPO and helps formulate a strategy for backup. If your RPO is four hours, then you need to perform backup atleast every four hours, but if your RPO is one hour then your backup strategy should match. Ofcourse, this will increase the infrastructure cost.
Obviously, RTO has a much broader boundary as it impacts business continuity management, while RPO is focused on backup frequency. Regardless, these number should be determined objectively based on the need and cost factor.