Skip to main content
Blog

Integrating RTO and RPO in Your Data Recovery Plan

By October 29, 2018No Comments5 min read
disaster-recovery-backup

93% of companies without Disaster Recovery who suffer a major data disaster get shut out of business within one year.

The database is the backbone of any business. It contains all the reports, customer data, events, financial transactions and other priceless information that drives an organization. But a hardware or software failure can render an entire database and other application services unusable. Yet, 75% of small organizations have no business continuity plan in place. Data loss is just one of many reasons why businesses should integrate a contingency plan in their working practices. For instance, whenever your systems experience any downtime, there is a cost associated with recovering from it. Last minute recovery attempts can become extremely expensive. Moreover, security breaches and ransomware attacks can halt down your entire production. Eventually, without strategic planning in advance, you will not only suffer revenue losses but also lose your business reputation.

Which strategy will yield the best result?

Every business should have an Information Technology Service Continuity (ITSC) plan. It outlines two fundamental parameters of a disaster recovery which are the Recovery Point Objective (RPO) and Recovery Time Objective (RTO). They define a business continuity plan and backup infrastructure of your organization. Though RPO and RTO may sound similar, but they are very different in terms of how they help organizations plan and manage risks.

RPO: Recovery Point Objective

Recovery Point Objective (RPO) is the maximum targeted time of a recovery plan i.e. how far to roll back in time if a disaster occurs. It describes your tolerance in time units, that might pass during a disaster before the data is unrecoverable. For instance, an RPO of 10 hours means that you can afford data loss of up to 10 hours. In particular context, RPO defines the time and frequency of your backups. For e-commerce companies handling payments data, RPO could be in seconds and for a manufacturing company, it could be in hours.

RTO: Recovery Time Objective

RTO defines the time required to recover your data and ensure business continuity from the point of disaster. It is the amount of time a business can sustain without its services and without incurring significant losses. It answers the question- “How much time do we need to overcome a disaster?”. Companies generally want to keep their RTO as short as possible. But minimizing the recovery time maximizes the efforts and cost needed for a quick solution. Ideally, your IT administrator would devise a strategy that will balance your business requirements and the money invested in backup and recovery.

How to calculate your RPO and RTO?

RPO and RTO enable an organization to know how much data it can lose and how long it can be down. Some business applications can afford weeks delay while others cannot tolerate any downtime. As you have discovered earlier that RPO and RTO are not just random time units that you can be set and kept going. Therefore, it is important to keep in mind that there are many mission-critical, business-critical and non-critical applications deployed in an organization. There is no one-size-fits-all solution in a business continuity plan. The following factors should be considered while calculating your RTO and RPO-:

  • Different services have different requirements: Each application in an organization handle different type of data. Email and VoIP services can afford downtime of a few hours but financial transactions which are highly critical, cannot afford a single minute of delay. Therefore, it is important to evaluate RPO and RTO for each application independently.
  • Cost: Recovery comes at a certain cost. The money you are willing to spend in disaster recovery will affect your RPO and RTO. This includes the overhead cost per hour of the affected employees, hired third party services and revenue losses. As stated earlier, smaller the RTO, higher the cost required in full disaster recovery.
  • The time duration for initiation of the recovery process: Often neglected, an RTO must consider the time spent in analyzing the disaster and initiating the recovery procedure. If you have set your RTO to 15 minutes but the initiation itself takes 30 minutes, then you will lack behind the schedule and eventually suffer greater downtimes than expected in case of any disruption.
  • The location of backup: A cloud-based backup will require very little effort but an on-premise backup system will take more time because you have to synchronize the backup with the current work timeline manually. Cloud, minimizes the efforts by automating the data synchronization for you.

Backups are a more like an insurance. The efforts seem unnecessary and excessive until something bad happens. You will regret the loss when it is too late. Therefore, an efficient backup and recovery plan is required to mitigate any risk associated with system failure and downtime. You should consider how often should you take backups, how quickly can you recover, analyze the critical applications and decide a budget for the recovery operation. Following best practices for hardware maintenance and disciplined system management, can reduce risk but the potential for failures can never be eliminated completely. Disasters will happen, and you must be prepared to respond quickly.