Introduction
During the design of your backup strategy, RPO and RTO are the most important parameters to define for a successful data protection plan.
Although RTO and RPO are always mentioned during the design of the disaster recovery plan, not always their scope, usage and difference are so clear.
- What do RTO and RPO mean?
- What is the difference?
- Why are they so important in a backup strategy design?
Before starting any design backup strategy, it is fundamental to fully understand what RTO and RPO parameters are and the difference between the two in a backup design.
RPO
RPO stands for Recovery Point Objective and defines the “age” of your data from the last backup.
To make the concept easily understood by non-IT personnel as well, in simple words the RPO can be defined as “how much data a company can tolerate losing if a failure occurs”.
The RPO is typically measured in units of time: seconds, minutes, hours, days, or weeks. If you experience a failure now and your last backup was taken two hours ago, it means your RPO is two hours and your business has lost the last two hours of data.
In a typical design, the backup configuration provides different RPOs based on the levels of the criticality of your applications and systems defined by the business leaders. Although databases or ERP systems should have a near-zero RPO set, perhaps static websites won’t require frequent backups.
If you want to implement near-zero RPO protection for your data, you must consider some key points of the backup that perhaps are not so obvious:
- The backup operation is a resource-demanding process that consumes CPU, RAM, and bandwidth from your infrastructure and slows down applications
- Low RPOs (frequent restore points) with quite long retention means more space consumption. You must calculate in advance the amount of data to transfer to your backup repository to be sure you have room enough to store all the processed backups. For example, if you have an RPO set to one hour with a retention of seven days, you backup 10 GB of data every hour and after one day the backup will consume 240 GB of space, about 1.7 TB in a week.
Bear in mind that configured specific retention, as the RPO value is set lower and lower, more space is required to store your backups.
How to define the correct RPO?
Defining the correct RPO is the key to a successful backup strategy design.
First, you must know what data you have and classify them according to their criticality. Next, you must figure out how often your data changes and the impact on your business in case of a data loss scenario.
Once you have established what are the mission-critical and less critical data, you can start defining the most appropriate RPOs. As a guideline you can consider the following time frames:
- Business-critical data – 0 to 1 hour
- Semi-critical applications – 0 to four hours
- Less critical applications or services – four to twelve hours
- Important data but not critical – every 24 hours
- Noncritical, less important data – weekly
RTO
RTO stands for Recovery Time Objective and defines the amount of time required to restore the service after a disaster.
If a virtual machine fails and you must recover the machine from the backup, the RTO defines how much time is required to restore the VM.
To obtain low RTOs is generally quite expensive since you need fast storage devices, large bandwidth (10GB, better 25GB), and a good infrastructure.
What’s the difference?
While the RTO (Recovery Time Objective) is the period of time required to restore normal operation in the event of IT downtime, the RPO (Recovery Point Objective) defines how often you take a backup, thus how much data could be safely lost when a failure happens.
Better a low RPO or a low RTO?
Bear in mind that RPO and RTO work together and you must balance them carefully:
- A low RPO with a high RTO value = bad design, in this case, the recovery from a failure requires more time than a significant service downtime
- A high RPO with a low RTO value = bad design, although the restore can be fast the amount of lost data can be unacceptable for the business
- A good balance between RPO and RTO = good design, data loss, and services/applications downtime are very limited with a small impact on the business
Conclusion
Be aware that stringent RTO and RPO values increase the costs to achieve them because you need more resources (compute and bandwidth) and storage space. To keep costs under control, you must identify the appropriate RTO and RPO values based on your criticality and find the best balance making your backup strategy design as cost-effective as possible.
Follow our Twitter and Facebook feeds for new releases, updates, insightful posts and more.
