Recovery Point Objective (RPO) and Recovery Time Objective (RTO) are lingo that Disaster Recovery market uses everywhere. These terms are good measure for DR solution.

But if you are customer who has never really understood them and don’t want to know too much about them other than understand how they impact your DR investment, here it is. Thx to my colleague, Scott who explained from customer perspective.

Ultimately, every DR investment is tied to network to recovery site (or backup site).

RPO is how wide  the network pipe you desire to have aka how much bandwidth cost you can bear to get all your data in time.   If you want fast recovery, then you pay more for Bandwidth. RPO is data recovery time  and if you have lot of data to recover in short time, you just need more bandwidth.

RTO is how long the network pipe you desire to your recovery location aka where can you locate your colocation site for recovery.  This is latency sensitive parameter. Long distance recovery site  have higher latency (it is just physics!!) and longer RTO. Think of RTO as unprotected time for your data. Ideally I like to have that zero, but do I have investment to collocate the recovery site within synchronous distances of 60miles(100miles) for 5ms RTT. If I don’t, then I will have to tolerate the unprotected time(RTO) for my data.

There is lot of technology out there that can provide whatever you want, but the underlying decision points are tied to DR investment vs   tolerance towards Data protection and Data recovery.   Every business is different and the tolerance is what customer can choose and of course technology should follow that. . That is it, I m sure there are RTO/RPO calculators available and lots of vendors pitch they solutions.

Now, would it be nice if we have a solution that can allow to choose RPO/RTO for given application. Ultimately Business runs on IT applications and infrastructure is medium.  Business decides what IT apps are important and apps should choose RTO/RPO. Well that may be possible sometime in future.