These two acronyms along with their cousins, RPA & RTA are essential elements when planning your Backup and DR strategy. Yet, when we challenge business owners and IT people about these, more often than not we get shrugged shoulders.
The most frustrating time to learn about those is during a disaster. They're NEVER what people expect.
So what are they? Let's drop the last letter and look at "RP" versus "RT".
RP for Recovery Point
This is the point in time which you have to travel back to in order to get valid data. If you're backing up every 15 minutes, then it's hopefully just 15 minutes before you lost data or had a disaster. If that data set is not valid, then you start to jump back in 15 minute increments retrieving what you can. That doesn't seem unreasonable. For critical databases, that increment might be five minutes. For slow moving data, it might be an hour, or half a day.
However, if you only back up at night, overnight, then your increments are in 24 hour jumps. That can be painful.
You also need to think about your exposure if a backup fails and you immediately have to skip back two time periods. If it's 30 minutes rather than 15, most people can recall what work they did recently. If it's 48 hours, that's a much greater exposure to your business and a much bigger effort for your staff to recover from.
RT for Recovery Time
This is the point in time you need to wait for (after your disaster) to be operational again. If you have the ability to rapidly restore files or spin up alternate/recovery hardware to run servers, then that can be a matter of minutes or at worst maybe an hour or two.
If you have to do a lengthy file restore of all data, copying it from your backup medium to alternate/recovery hardware, or you have to reinstall a fresh operating system then applications plus their configuration, you can be looking at timescales measured in days. These become very painful recovery exercises and can be of sufficient magnitude to potentially make your business extinct.
Finally, the difference between the two sets - "O" and "A".
O for Objective
This is the business side. It has objectives for getting itself back up and running after a disaster. These objectives are set by management, not by IT. Management has to go through each of its key business applications, plus general technologies (e.g. email) and infrastructure (servers, networks, Internet connections) and decide how long it can withstand these being unavailable. It also has to decide priority. In the event of a total loss (or large scale loss), not everything can necessarily be brought back in one single swoop. That order may also be different depending on where the business is in its transaction cycle (be that weekly, monthly, quarterly or yearly). You really do not want to be having these discussions (or, more likely, arguments) during a disaster.
A for Actual
This is the IT side. It has actual metrics for how quickly systems can be recovered. Worst case, these actuals will be educated guesses and at best, based on real-world testing.
O versus A
What about the discrepancy between the two figures (because there always is)? Well, that's your discussion topic or negotiation. If you have the money to invest, then IT should be able to deliver the business objectives. If not, then it's a case of figuring out where in the middle you can meet. The business might need to lower their expectations, or perhaps prioritise some systems over others. IT might need to do some actual DR tests to firm up on their numbers and see if there's scope to optimise the process. Sometimes even documenting and practicing it is sufficient to improve the speed, but they'll need time and resource. With a great, modern day Backup & DR system that's getting easier.
