Businesses have little tolerance for downtime, especially if you consider that the average cost of IT downtime is $5,600 per minute. This translates to thousands of dollars lost in revenue in a matter of minutes. Moreover, if you add costs from loss of productivity, customer churn, and non-compliance fines and penalties, you may even be staring at permanent shutdown.
The irony is that disasters are bound to happen to any business. However, the way an organization deals with disruption determines the true cost of downtime. To mitigate downtime risks, businesses and IT teams need to be prepared by having a solid business continuity and disaster recovery (BCDR) plan in place.
The two most important parameters of a good (or bad) BCDR plan are the recovery point objective (RPO) and recovery time objective (RTO). They quantify the losses that potentially ensue if critical systems fail, and set protocols for rebooting services to resume operations and to meet service level agreements (SLAs). In essence, they provide a realistic backdrop against which IT leaders can plan and execute a successful BCDR plan.
Unitrends purpose-built backup appliances offer dedicated backup storage isolated from production. Replicate backups to the Unitrends Cloud for secure and immutable offsite safekeeping.
In this article, we break down RPO and RTO, their role in a BCDR plan, and why it’s essential for businesses to define and understand their RPO and RTO.
Let’s start by defining RPO and RTO.
A recovery point objective or RPO is the maximum acceptable amount of data loss measured in time. It marks the time during the disruption when the quantity of data lost exceeds the BCDR plan’s maximum allowable threshold.
The purpose of RPO is to determine:
An example of RPO:
When disruption occurs, if the most recent backup copy of data is from 10 hours ago, and the standard RPO for the business is 15 hours, then we are still within the bounds of the RPO as specified in the BCDR plan. Essentially, RPO answers the big question, “Up to what point in time can the recovery process move tolerably given the volume of data lost during that interval?”
Recovery time objective or RTO is the timeframe within which applications and systems must be restored after an outage. It determines the quantity of time that an application or system is allowed to be inoperational without causing significant damage to the business. To put it simply, RTO measures the amount of downtime “tolerated” as per the BCDR plan.
The purpose of RTO is to determine:
An example of RTO:
Due to issues with the Microsoft Exchange Server, applications that include emails, calendar and collaboration services (such as Teams) go down. If your RTO is set at six hours, this means the maximum tolerable downtime your business can survive is six hours, and your RTO for the Exchange Server must be less than six hours to avoid serious damage to the business.
If you think your business can do without RPO and RTO, think again.
Here are a few reasons why you need to invest in understanding and establishing RPO and RTO:
Should a disruption occur, no business can endure data and reputational loss without RPO and RTO. You will be clueless with regards to how much and for how long your business can afford a data loss. An effective RPO and RTO give your BCDR plan a more pragmatic layer, making the policies more effective.
Critical applications are applications without which a business cannot operate under any circumstance. One of the tenants of RPO and RTO is application priority. This leads to a reliable IT infrastructure where critical applications are spun up first, bolstering your disaster recovery efforts.
RPO and RTO help you define your SLA during disruption. It also includes prioritizing SLA to ensure the end user isn’t affected by the disruption of business operation. If you can lower your RPO/RTO, you can guarantee tighter deliverables.
Based on the RPO/RTO, businesses divert relevant personnel to data recovery during a disruption, allowing the rest of the staff to work on more productive tasks that impact the bottom line.
Different businesses have different and unique RPOs and RTOs. However, the methodology to calculate RPO and RTO are somewhat similar. Start with understanding the cost of downtime for your organization.
Secondly, as part of your BCDR plan, build an inventory of every system and application used by your organization. Don’t forget to consider internal teams and end users that may be affected by systems rendered inaccessible. These systems are categorized into tiers.
To define these tiers and come up with an appropriate RPO and RTO, ask yourself these questions:
RPO:Unitrends offers the perfect tech stack to shape RPO and RTO that perfectly fits your business needs.
Learn more about why Unitrends is the right fit for your organization. Get in touch with us today!
MARKET-LEADING BACKUP AND RECOVERY SOLUTIONS
