RTO and RPO are two important measures used in disaster recovery and business continuity planning. They help businesses understand how quickly their systems need to be restored after an outage and how much data they can afford to lose.
Having clear RTO and RPO targets means you can build a recovery strategy around the actual needs of your business, rather than discovering your requirements when a serious incident occurs.
Recovery Time Objective (RTO) is the maximum acceptable amount of time that a system, application or business service can be unavailable following a disruption.
For example, if your RTO is four hours, your disaster recovery plan should be designed to restore the affected service within four hours of an outage.
The appropriate RTO will depend on the service and its importance to your business. An e-commerce website that processes orders throughout the day may need to be restored much faster than an internal system that employees can work around temporarily.
A useful way to think about RTO is:
RTO = How quickly do we need to be operational again?
The longer a critical system remains unavailable, the greater the potential impact on revenue, productivity, customer service and reputation.
Recovery Point Objective (RPO) is the maximum amount of data that a business can afford to lose following a disruption.
For example, an RPO of one hour means that, in the event of a failure, the business needs to be able to recover data to a point no more than one hour before the incident.
RPO is closely connected to your backup and data-replication strategy. If important data is backed up only once every 24 hours, for example, recovering with an RPO of 15 minutes may not be possible without additional technology or processes.
A useful way to think about RPO is:
RPO = How much recent data can we afford to lose?
Although RTO and RPO are related, they address two different parts of disaster recovery.
| RTO | RPO | |
|---|---|---|
| Stands for | Recovery Time Objective | Recovery Point Objective |
| Measures | Recovery time | Acceptable data loss |
| Key question | How quickly must we recover? | How much data can we afford to lose? |
| Example | 4 hours | 30 minutes |
| Influenced by | Recovery processes and infrastructure | Backup and replication frequency |
For example, a business might have an RTO of four hours and an RPO of 30 minutes. This means its systems should be restored within four hours, while recovered data should be no more than 30 minutes behind the point at which the incident occurred.
Different systems within the same organisation can have different RTO and RPO requirements.
There isn’t a single formula that produces the correct RTO for every business. Instead, you need to consider the operational and financial impact of an outage and determine how long each service can realistically remain unavailable.
Start by identifying your critical systems and asking:
You can then establish an appropriate recovery target for each critical service.
For example, an online retailer might determine that its website and payment systems need to be operational within two hours, while an internal reporting system could potentially remain unavailable for longer.
The important point is that RTO should be based on the business impact of downtime, not simply on what is technically convenient.
Calculating RPO involves determining how much recent data your business could lose before the consequences become unacceptable.
Consider:
For example, if losing an hour of customer orders would create a significant operational problem, you may need an RPO of less than one hour.
Once you have established the target, your backup and replication strategy needs to support it.
An RPO of 15 minutes, for example, requires a recovery approach capable of protecting data frequently enough to meet that objective. Simply performing one backup each night would not be sufficient.
Imagine a business relies on a cloud-based system to process customer orders.
After reviewing the potential impact of an outage, the business determines that:
Its targets would therefore be:
RTO: 2 hours
RPO: 15 minutes
These targets can then be used to design the disaster recovery strategy.
The business may need appropriate backup or replication technology, recovery infrastructure and documented procedures to ensure the targets are achievable.
It’s also important to test the recovery process. A documented RTO of two hours doesn’t necessarily mean the business can actually restore its systems within two hours.
Once you’ve established your targets, there are several ways to improve your disaster recovery capabilities.
Keep multiple copies of important data and consider storing at least one copy separately from your primary environment. Backups should also be monitored and tested rather than simply assumed to be usable.
Where a low RPO is required, more frequent replication can reduce the amount of data that could be lost during an incident.
Not every application needs the same recovery target. Identify the systems that are essential to your operations and allocate recovery resources accordingly.
A disaster recovery plan needs to work in practice, not just on paper. Regular testing can identify problems with backups, dependencies, access permissions, recovery procedures and infrastructure before an actual incident occurs.
Keeping software, hardware and security controls up to date can reduce the likelihood of certain failures and help ensure that recovery systems remain usable when they are needed.
Your RTO and RPO requirements can change as your business grows. New systems, additional employees, increased online sales or changes to the way you handle data can all affect your recovery requirements.
Backups are an important part of disaster recovery, but they are not the same thing.
A backup gives you a copy of your data. Disaster recovery encompasses the wider processes, technologies and resources required to restore systems and resume business operations following an incident.
For example, having a daily backup may protect your data while still leaving you with a lengthy recovery time. If your business requires a two-hour RTO, you need to consider how systems, applications, infrastructure and data will actually be restored within that timeframe.
This is why RTO and RPO should be considered when designing your overall recovery strategy rather than added as an afterthought.
There is no universal RTO or RPO that suits every organisation.
A useful starting point is to carry out a business impact assessment and involve the people responsible for different areas of the business. IT teams can explain the technical recovery options, while finance, operations, sales and other departments can help establish the potential impact of downtime and data loss.
The result should be a set of realistic recovery objectives for each critical system.
These objectives can then inform your choice of backup, disaster recovery, infrastructure and support services.
Reliable communications and IT infrastructure can play an important role in keeping your business operational and supporting your disaster recovery strategy.
At DBFB, we provide telecommunications and business technology solutions designed around the needs of individual organisations. By understanding your infrastructure and business requirements, we can help you identify potential points of failure and reduce the disruption caused by outages.
If you’re reviewing your business continuity or disaster recovery arrangements and need help assessing your requirements, contact DBFB on 01604 673320 or email discover@dbfb.co.uk.
