Recovery Point Objective RPO: Stop Living in a Fantasy World

Let’s talk about something that drives me crazy in the backup world – the disconnect between what organizations say their recovery point objective RPO is and what their actual backup practices support. I see this all the time: companies claiming they can only afford to lose an hour of data when they’re backing up once a day. That’s 24 hours of potential data loss, not one hour. The math doesn’t work, and pretending it does is setting yourself up for a disaster.

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/

Your recovery point objective RPO is really simple at its core – it’s just how much data you agree you’re allowed to lose, measured by time. Not measured in gigabytes or terabytes, but in hours or days. It’s the answer to the question: “If we have a disaster right now, how far back in time will we need to recover from?” And more importantly, how much business data will we lose in that gap?

Why Your Recovery Point Objective RPO Doesn’t Match Reality

Here’s where most organizations go wrong. They set an aggressive RPO target – maybe 12 hours, maybe 24 hours, maybe just a few hours – and then they don’t align their backup frequency to match that target. Or worse, they set the target based on what sounds good to management rather than what their backup infrastructure can actually deliver.

Think about it this way. If your recovery point objective RPO is 24 hours, that means you need to be backing up at least once every 24 hours. If you’re backing up once a week? Your real RPO is seven days, not one day. You can claim whatever number makes you feel good, but when disaster strikes, reality is going to win that argument every single time.

And here’s another wrinkle – different disaster scenarios might force you to accept different RPO outcomes. A simple server failure where you’re recovering from last night’s backup? Great, you’re probably within your RPO window. But ransomware? That’s a whole different story. You might discover that your backups have been compromised for weeks. Suddenly you’re not recovering from yesterday’s backup – you’re going back two weeks or more, and your carefully planned RPO just went out the window.

How to Test Your Recovery Point Objective RPO

The good news is that testing your recovery point objective RPO is actually easier than testing your recovery time objective (RTO). You’re not running full recovery drills every time. What you’re really testing is backup compliance. Did the backup run when it was supposed to? Did it complete successfully? How often are you hitting your backup windows?

You should be monitoring this stuff religiously. Set up alerts. Build dashboards. Report on your compliance numbers. And here’s a rule that should be non-negotiable: if a backup fails more than once, that’s all hands on deck. Because if you’re supposed to lose only 24 hours of data but backups have failed twice, now you’re talking about 48 hours of data loss. Fail three times? That’s 72 hours. This is serious business data you’re putting at risk.

The monitoring piece is straightforward – most backup systems can tell you whether jobs completed successfully, how long they took, and whether they’re meeting your scheduled windows. Use that data. Don’t just assume everything’s working because nobody’s complaining.

Practical Ways to Meet Your Recovery Point Objective RPO

Okay, so you’ve done an honest assessment and realized your current backup frequency doesn’t support your stated recovery point objective RPO. What do you do about it? Here are some practical approaches:

First, rightsize your backup frequency. If you’re backing up once a day but need a 12-hour RPO, can you run backups twice a day? Maybe once before business hours and once after? With incremental backup systems, running four backups throughout the day often takes roughly the same total time as running one backup once a day. The individual backups are smaller, but you get better RPO coverage.

For databases, you don’t necessarily need to back up the entire database multiple times a day. Back up your transaction logs throughout the day and send them to immutable storage. You might have a slightly longer recovery process, but at least you won’t lose the data. That’s the whole point of transaction log backups – capturing the changes between full database backups so you can recover right up to the point of failure.

Consider upgrading your backup technology. Continuous data protection (CDP) and near-CDP solutions can get you down to very low RPO numbers – we’re talking minutes instead of hours. Most of these are storage-based, meaning you’ll probably need to invest in different storage systems that support snapshot-based backups. Products exist that can work with your current storage, but the typical approach is buying a new storage platform that includes snapshot and replication capabilities.

Don’t Forget Your SaaS Applications

Here’s something that trips up a lot of organizations – your SaaS applications need the same RPO attention as your on-premises systems. Microsoft 365, Salesforce, and other cloud apps where you’re generating data throughout the day – are you backing those up frequently enough to meet your RPO targets?

Microsoft finally admitted that backup is necessary by offering their own backup service for Microsoft 365, though it costs extra. To me, that’s them acknowledging you need protection. I’d still recommend using a third-party backup service rather than relying on Microsoft to back up Microsoft, but that’s a personal preference based on not wanting all your eggs in one basket.

The modern SaaS backup applications are built for this. They’re doing deduplication-based, incremental backups throughout the day, storing data in a way that lets you restore right up to the point of failure. Take advantage of that technology. Your recovery point objective RPO for SaaS should be just as aggressive as your RPO for on-premises systems.

The Bottom Line on Recovery Point Objective RPO

Stop lying to yourself about your RPO. Do an honest assessment of what your current backup practices actually support. Then either adjust your stated RPO to match reality, or adjust your backup frequency and technology to match your stated RPO. Living in the fantasy land where they don’t match is just setting yourself up for failure.

Monitor your backup compliance constantly. Report on it. Fix failures immediately. And make sure you’re covering all parts of your environment – on-premises systems, databases, SaaS applications, everything that matters to your business.

Your recovery point objective RPO is a commitment about how much data you’re willing to lose. Make sure your backup practices can actually deliver on that commitment, because when disaster strikes, nobody’s going to care what number you wrote down in a document. They’re going to care about how much business data you can actually recover.

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