A recovery point objective (RPO) is a useful tool for disaster recovery planning, especially when it comes to planning and executing backups. At its most basic, an RPO is a measurement of your tolerance for data loss and it can help you decide how often you need to be backing up, as well as what sort of infrastructure you need in place in order to support those backups.
Keep in mind that, despite its name, an RPO has less to do with the actual execution of a recovery as it does with helping you lay the groundwork, so when you do have to recover, you’ll recover everything you need. Nor is RPO a tool for measuring or combating downtime. A better tool for those things is a recovery time objective (RTO).
So let’s take a more detailed look at how to use an RPO.
Just What Is RPO Anyway?
Unless your systems are protected by some kind of mirroring or high availability system, you’re probably going to lose some data when a disaster strikes. The question is, how much data can you afford to lose?
Unfortunately, that’s a complicated question. Your gut reaction is probably, “I don’t want any data loss. I need all of my data.” But do you?
Sure, data loss can be expensive, but so is the infrastructure you need to be constantly backing up all your systems. Every backup you take on every system in your environment takes up space, and if you’re taking backups every fifteen minutes, it can really add up. That’s not to mention the bandwidth each backup takes across your network or the time and energy it takes to maintain such a rigorous backup schedule. (There’s a reason continuous data protection is generally only accessible to large enterprise businesses.)
Enter RPO. Calculating RPO allows you to set up your backups in way that accounts for both your data and your budget. By realistically assessing the amount of data you can afford to lose, you put yourself in a position to balance those data needs with the current state of your infrastructure.
For example, if you determine that you can really only afford to lose an hour’s worth of data, you can sit down and do the math and figure out how many servers and what amount of bandwidth you need to make that happen.
Keep in mind too that different systems will have different RPOs. Critical systems, like those in development or accounting (or your CEO’s laptop), should probably have more rigorous RPOs because data loss in those areas is more dangerous to the company.
How Much Data Can You Lose?
So what do I mean by how much data you can “afford to lose”?
The answer probably varies. Only you understand the value of data in your business, but an example of the kind of question you can ask as you’re determining your RPOs is “what’s going to happen after a specific loss of data?” Is someone going to have to painstakingly re-create it or is that data more or less expendable? What if it’s not expendable, but is also not re-creatable? Obviously, if someone’s going to have to re-create some or all of it, that data is important and you should consider setting your RPO and corresponding backup schedule accordingly. If you won’t be able to re-create it at all, you’ll probably want to be even more aggressive with how you protect that data.
RPOs aren’t as glamorous as their younger RTO siblings (what with all their fancy “cost of downtime” popularity), but determining an RPO for each of your systems is an essential part of a disaster recovery plan. In fact, according to a recent study by the Aberdeen Group, one of the factors that determines a business’s fitness when facing disaster is whether or not they establish RPOs.
Being prepared for a disaster is really all about understanding and adapting to the needs of your IT environment and RPO is a great tool to help you do that.