Remember the days when the Office Manager would take the daily backup tapes home for “safe keeping?” This Flintstone-esk business system was at one time considered by some a best practice for disaster recovery planning.
Today, you may be using a Cloud solution or hybrid on-premise solution for your backup and disaster recovery planning. But without knowing your Recovery Time Objective (RTO) and Recovery Point Objective (RPO), your business may not be as disaster ready as you need it to be.
And what you don’t know can cost you time, money, and your reputation.
Recovery Time Objective (RTO) is the tolerable length of time an application, system, network, or computer can be unavailable after an incident or failure.
For example, financial services have a low to zero RTO because services involving money are extremely time sensitive. In contrast, printer services failing can be inconvenient but shouldn't lead to revenue loss for a while, so RTO should be set to several hours.
RTO is calculated using a multistep process. The main goal is to determine how long before normal business can resume after an incident.
The first step is to inventory all systems, critical applications, virtual environments, and data.
Most SMB and SMEs make the mistake of not taking the time to conduct a proper inventory of the environment. This crucial step helps to determine where you should invest your time and money, because not all systems and applications require the same effort to backup and restore.
For example, your ERP system is more important to restore immediately than an application that is used once a quarter. So, the frequency of backing up the ERP system would be higher than the less used application. But more on that in the section on RPO.
Each piece of the company puzzle can have its own RTO, so identifying every part is vital.
Next, an evaluation is made of each element's value, represented by a duration of time, to the operation of the business. This step is detail oriented.
The value can also be associated with existing service-level agreements, as some include penalties if certain services are unavailable for specific amounts of time.
With an RTO in place, organizations can finalize data backup and failover policies and plan for additional assistance in the event of an incident. Once the RTO is paired with a recovery point objective, an accurate restoration rate can be determined.
Recovery Point Objective (RPO) differs from RTO in that it measures the age of files that must be recovered from backups when a disaster occurs.
RPO is also measured in time and is expressed backward into the past from the instant a failure happens.
For example, if the RPO is set for 12 hours, then the backup for that data must be set for 12 hours or less. This information lets admins determine the technology they need to create the company's backup procedures. At Consilien, we can backup critical systems every 5 minutes if needed without any efficiency loss.
Calculating an RPO requires determining what data a company possesses, where it resides, how frequently the data changes, and what value that data holds.
Admins can then calculate how much data their business can lose and still be able to recover.
Often data is separated into different tiers based on its importance. For example, critical data, like banking transactions, may have a loss tolerance of less than an hour; therefore, the RPO would be set for a continuous backup.
On the other hand, data that isn't often changed can have a much longer RPO, like archived employee handbooks.
When combined, an RPO and RTO work together to ensure data is sufficiently backed up and a plan is in place when an event occurs to get that data restored.
Know your RTO and RPO using our online calculator. It’s free and easy to use. Learn more here.