Recovery Time Objective: From Fantasy to Reality

Let me tell you something that most IT professionals won’t admit: they can’t meet their recovery time objective. Not even close. And you know what? It’s not because they’re incompetent. It’s because they’ve never actually tested whether they can do what they’ve promised.

This blog post summarizes the main points of my latest podcast episode. If you’d like, you can listen to it or watch it at https://www.backupwrapup.com/

I’ve been in this industry for decades, and I’ve seen the same pattern repeat itself over and over. Organizations document an RTO, they present it to leadership, everyone nods and feels good about it, and then when disaster actually strikes, they discover they’re nowhere close to meeting that target. The problem isn’t the technology. The problem is that nobody’s being honest about what’s actually achievable.

Who Really Sets Your Recovery Time Objective?

Here’s the first thing you need to understand: you don’t determine the recovery time objective. I don’t care if you’re the backup admin, the systems administrator, or the person in charge of the entire backup infrastructure. The RTO isn’t your call to make.

The business unit determines the recovery time objective. Period. And they should be basing it on finances – on how much money the organization loses while systems are down. For government entities or NGOs, it’s about reputational damage and the difficulty of redoing work manually. These are business calculations, not technical ones.

Your job isn’t to set the RTO. Your job is to tell business leadership what it will cost to meet their desired RTO, and to be brutally honest about whether you can actually achieve it with your current setup.

The Gap Between Objective and Actual Recovery Time

Most organizations that have an RTO documented – even if it’s poorly documented – are completely unable to meet it. Why? Because they haven’t tested. They don’t know what their Recovery Time Actual is.

RTA (Recovery Time Actual) is nowhere near as widely used a term as RTO, but it should be. Some people call it Recovery Time Reality. I don’t care what you call it, just don’t confuse it with your objective. Your RTO is what you’re aiming for. Your RTA is where you actually are right now.

The difference between your recovery time actual and your recovery time objective is the gap you need to address. And you can’t address that gap if you’re lying to yourself about where you stand.

Why Testing Your Recovery Time Objective Is Non-Negotiable

The biggest reason organizations can’t meet their RTO? They probably haven’t tested. And when I say testing, I don’t mean you restored one file one time and called it good.

Real testing means understanding all the dependencies. It means knowing whether you can procure the servers you need. It means making sure Active Directory is backed up. It means checking whether your network team can reconfigure everything in time. It means verifying that your deduplication system doesn’t have a 90% dedup tax that makes restores crawl at 10% of backup speed.

I remember working at a bank where we did testing with someone who wasn’t me (i.e. someone who hadn’t written the backup procedures). That’s when you discover what’s really in your runbooks and what’s just inside one person’s head. If you’re relying on one person to pull off your recovery, you’re setting yourself up for failure.

How to Close Your Recovery Time Objective Gap

So how do you actually get from fantasy to reality? Here’s what works:

Start with regular DR drills. Don’t make them these massive, stressful events right before performance review time. Make them frequent and small. Keep recovery on everyone’s mind. If something changes in your environment, you’ll catch it quickly rather than discovering it during an actual disaster.

Consider chaos engineering. Break things intentionally. See what happens. You might discover you forgot to back up Active Directory and now you can’t recover anything because you don’t have the authentication infrastructure. Better to learn that during a drill than during a real ransomware attack.

Run tabletop exercises at lunch. Make them frequent and fun. Use them to improve your runbooks and decision trees. Cross-train your teams so you’re not dependent on one person who might be on vacation when disaster strikes.

And here’s the most critical part: measure and report reality. Not what you wish were true. Not what you promised last year. Report where you actually are. Show the gaps. Let business leadership decide what to do about it.

I’ve been there. I remember when I was running backups with a shell script for about 50 servers, and then we bought a server that didn’t fit on a tape. Actually, it needed 50 tapes! My whole system broke. I felt like a complete failure because I couldn’t fix it with scripting.

But you know what? I went to my boss and told her the truth. She asked if there were commercial products we could spend money on. Problem solved. But it only got solved because I was honest about where we were.

Stop Living in Recovery Time Objective Fantasy Land

Here’s the bottom line: everyone wants zero downtime and zero data loss. That would be amazing. It’s also not going to happen for most organizations.

Your recovery time objective should be based on real testing, honest assessment, and business requirements – not wishful thinking. And if you can’t meet your current RTO, that’s not necessarily a failure. It’s information. It’s a gap that needs to be addressed through process improvements, better documentation, or upgrades to your backup infrastructure.

Don’t try to be magic. Make recommendations. Test regularly. Measure reality. Report honestly. And stop feeling like you’re failing when you can’t achieve the impossible. The only real failure is pretending everything’s fine when it’s not.

Written by W. Curtis Preston (@wcpreston), four-time O'Reilly author, and host of The Backup Wrap-up podcast. I am now the Technology Evangelist at S2|DATA, which helps companies manage their legacy data