Recovery objectives allow you to evaluate your disaster recovery strategy, and your recovery time and recovery point objectives are usually the most important metrics. Once you have set recovery time and recovery point objectives for your business, you can tune your backup and recovery strategy to avoid disruption when disaster strikes.
This post looks at recovery point objective (RPO) and recovery time objective (RTO) in the data-protection context of data backup and recovery. You can use it to assign values to your organization’s risk tolerance and risk aversion, as part of your business continuity plan. You can then factor RPO and RTO into the service-level agreements your IT team can realistically support.
What are RTO and RPO? What is the difference between them?
While both “recovery time objective” and “recovery point objective” contain the word “recovery,” one is driven by a backup policy rather than a disaster recovery plan.
Recovery point objective – How do you calculate RPO?
Think of your recovery point objective as the point in time back to which you want to be able to recover your data. A recovery point is essentially the time at which a data backup was completed successfully. That sounds fairly straightforward, but there is more to it. It’s true that the more often you can take a backup, the fewer data changes you risk losing in a disaster. But how often are you willing to back up (and pay to store) your data? That’s why recovery point objective is usually described as the time interval between backup operations.
For example, your recovery point objective could be once per day, once per hour, every thirty minutes or even as low as every few minutes. That means your data protection solution would create a backup at those intervals, depending on your settings and available technology. The gap following each backup would define your recovery point objective; any changes made to data between backups would likely be unrecoverable after a disaster.
So, how do you determine your ideal recovery point objective? Mostly, it depends on how critical the data is. In other words, how many changes to it (how much data change) could you lose without crippling your business? For a high-churn, business-critical database, you would want a backup interval measured in minutes; for data that changes less often, you could back up the changes daily.
How do you balance criticality and cost?
But then there is the question of how much you are willing to spend on protecting your data. The closer you get to zero RPO, the more you’ll spend on backup software, hardware and resources.
Most of your costs are at the primary storage layer or in secondary, identical storage. This is the risk-versus-cost conundrum: When you reduce your spending on data protection, you increase your risk of losing changed data, and vice versa.
Recovery time objective – How do you calculate RTO?
Of course, you back up your data so that you can recover it when needed, and that’s why recovery time objective matters. RTO is the amount of time it takes to recover data for use again in production. Note that it’s not the amount of time to recover, say, a database from cloud storage or tape backup onto a network file share. You have to measure recovery time objective as the amount of time before you can use the data again, as it was intended to be used.
Calculating your RTO is necessary to determine the features you need in your backup systems and products. For example, for high RTO (say, more than four hours), you will probably have time to back up from tape. But for low RTO (such as just a few minutes), you’ll need host-based replication or disk-based backup with continuous data protection (see below).
Think about recovery time objective in the context of a business-critical database. A tight recovery point objective will reduce the risk of lost transactions, but even if you have that, how long of an outage can your business tolerate? It’s important to know that because a business outage can mean lost revenue and damaged reputation. When you know the capabilities of your backup solution, you can begin to set service-level agreements supported by your recovery time objective.
Tips for achieving recovery time and recovery point objectives
Once you have a grasp of your desired recovery time objective and recovery point objective, you’ll start evaluating your technology options for delivering on them.
Backup
Backup is the staple of data protection. Many organizations, especially small and medium-sized ones, rely on daily backup to meet the recovery time and recovery point objectives of their basic applications. Although backup is not cutting-edge technology, it is an established one that is generally affordable and easy to implement.
Backup hardware and software are not ideal, however, for high-churn applications in which data changes frequently. If your organization is averse to risking the loss of that changed data, then it should not rely exclusively on traditional backup.
Snapshots
To fill in the performance gaps and reduce the risks inherent to backup, snapshots have evolved as a viable supplement. Snapshots are designed for quickly making a production copy of data at a given moment with little impact on systems; it’s common to take multiple snapshots per day.
Snapshot technology depends on an application programming interface (API) in the operating system or virtual machine that holds the data. Many backup solutions use snapshot APIs to back up and recover applications and data. The advantage of snapshots in data protection is that they allow you to set tighter recovery time and recovery point objectives with less risk of data loss.
Continuous data protection (CDP)
CDP solutions achieve near-zero recovery point objective — you could almost call it replication — and give you the option of recovering back to different points in time. CDP is not iterative, date-based backup; it is designed to be continuous within the measure of one day, such as every hour or every 30 minutes. Some implementations of CDP leave no data protection gap, scheduling snapshots as frequently as every few minutes.
Immutable backup
An immutable backup is a set of backup data that, once written, cannot be changed in any way. That means you can’t change it, the manufacturer of the backup system can’t change it, nobody can change it. Not even ransomware can change it, which is a big advantage in data protection.
Data immutability is a lock or hold on backed-up data. Once the data is written, backup software configures a setting that prevents the data from being modified or deleted. In effect, it changes the status of the data to read-only. That prevents anyone from accidentally changing, deleting or encrypting backups. What’s more, it prevents an attacker’s malware from altering or deleting the data.
Protect all your systems, applications and data.
What do RTO and RPO mean in disaster recovery solutions?
You should avoid setting recovery time and recovery point objectives in a vacuum. Instead, work with business managers and application owners to determine how quickly data needs to be restored and how much loss of changed data is acceptable to them. Naturally, the initial response will likely be that they require zero downtime and zero data loss. Your role, then, is to show the prohibitive cost involved in attaining that goal and work out reasonable, balanced expectations for your data recovery plan.
In some cases, you may go to the extent of setting additional objectives. To establish a version recovery objective (VRO), ask how recent a version of the data you need to be able to restore. To set a geographical recovery objective (GRO), consider where backups will be stored and how that affects your ability to recover from a disaster. For example, if your disaster recovery site is in another region of the world, RTO will likely be greater than if you could recover from a local backup.
Why are recovery time and recovery point objectives important?
The process of establishing both your RPO and RTO is an important exercise in setting expectations around data loss and recovery. Not only does it uncover novel areas of data recovery, but it also allows you to recalibrate existing expectations. It’s a way of revealing the impact of an outage to the business and of bringing budget into alignment with risk aversion.
Finally, it’s important to document all of your information, RPOs, RTOs, reasons, decisions taken and business expectations, and add it to your recovery planning. That way, should you ever have to recover data, you’ll have an agreed measure by which you can show whether you were successful or not. If the recovery process falls short of the needs of the business, you’ll see how and where to boost spending for a better outcome next time around.
