Disaster Recovery as a Service is a hot topic in cloud, and in business, right now. And, for good reason. The technology that powers disaster recovery has never been more efficient, affordable and capable than it is today.
With all the talk of business continuity, Disaster Recovery as a Service (DRaaS) in the planning and forecasts, it can be easy for the terms to blend together. If you’re responsible for planning your company’s disaster recovery, or involved at all in the buying process, the following are terms that you will hear often. This blog post will cover everything you need to know from top to bottom.
Before we get into the granular details of RTOs and RPOs, let’s start with a few high-level definitions.
Disaster vs. Disaster Recovery
IT Architect Jake Robinson describes the two with this story, “Imagine a delivery truck is driving down the road and it breaks down. The breakdown is the disaster.”
The disaster is the point in time at which service has stopped, been compromised or impeded.
“The Disaster Recovery (DR) plan for this delivery truck is the process of calling for help, using a spare tire, employing the repair process, the tow truck and whatever else needs to happen to get the truck back in action and on the road,” Robinson continues.
DR is the process of getting the service tools back up and running to provide service. In the IT world, that DR plan is how to get your applications recovered, up and running at 100% after a disaster impedes their function.
Disaster Recovery vs. Business Continuity
When researching disaster recovery solutions, you will often see hybrid acronyms to represent both disaster recovery (DR) and business continuity (BC). This DR/BC term might give you a false impression that DR and BC are the same thing, when in fact, they are different, though linked.
Continuing with the truck analogy, Robinson explains, “The business continuity in the truck breaking down story wasn’t explained yet. BC is the second truck that comes to get the packages so they are still delivered on time. BC keeps the business going.”
There are many, many businesses that fail after a disaster without a BC plan. DR will get your hardware, software and apps back up and running, but without a business continuity plan to keep your company going during the recovery process, you might not have a reason to recover those items. BC involves your finances, your personnel, your emergency plans and everything else that is a necessity to keep going and serving.
“The rise of virtualization,” explains Robinson, “has enabled BC and DR to merge in some ways because we aren’t tied to the physical IT equipment anymore.”
He continues, “Look at replication and DR. If you have a source and a target linked by replication and your source goes down, the source (where it runs) is only the commodity. While it may be down, your applications might not go down. DR is only for the source (the truck) and not necessarily the application or delivery of the application (packages) anymore.”
RTO vs. RPO
Once establishing agreed-upon high-level definitions, you’ll start to see a lot more acronyms as you compare backups versus DR solutions as well as Disaster Recovery as a Service (DRaaS) solutions.
DRaaS solutions, according to WhatIs.TechTarget.com, are, “a predetermined set of processes offered by a third-party vendor to help an enterprise develop and implement a disaster recovery plan.”
Each DRaaS offering you look at will define in their Service Level Agreement (SLA) what their promised RPO and RTO are.
Recovery Point Objective (RPO) refers to the point in time in the past to which you will recover.
Recovery Time Objective (RTO) refers to the point in time in the future at which you will be up and running again.
Think of the above diagram as a timeline of events during which a disaster happens. The RPO will be the point to which you will have all data up to that point recovered. The gap between the disaster and the RPO will likely be lost as a result of the disaster.
On the timeline, RTO is the point in the future at which you will be back up and running full speed ahead. The gap between the disaster and the RTO is the timeframe for which your app will be down and non-functioning.
While in a perfect world every application would have an RPO of milliseconds and an RTO of milliseconds, that’s not physically or financially feasible for the majority of the businesses in the world.
When comparing solutions, you’ll need to identify RPOs and RTOs you are most comfortable with for each application, and the price point slides based on the answers for each.
Robinson explains, “If you’re a Tier 1 banking high-transaction application, you will not be able to afford a very high RPO. You will need to have all transactions or real money will be lost as those transactions are lost.”
He continues, “If you are referring to a website, however, which is updated monthly, your RPO can be as much as weeks back in time since not much will have changed, if anything. You are more comfortable going farther back in time to recover, and likely you will end up paying less for that RPO.”
Pat yourself on the back; you’ve earned this day to relax!
What has been the most difficult step in your disaster recovery strategy?
See if all RTOs are the same from provider to provider and learn how to challenge your recovery provider to be the best.
Want more information about disaster recovery? Download the Ultimate Guide to DRaaS for a complete journey through all things DR-related.
