RPO and RTO: The Conceptual Vise-Grips of BDR Sales
How MSPs can break it down for their clients and turn a pared-down presentation into a business continuity sale.
In terms of your client’s applications and data, they want you to protect everything, keep them operational 24×7, never incur an outage, and guarantee that they won’t have to think about it. That is, until they understand the cost to make all that happen. And that’s when you have a strategic conversation about the trade-offs of never having an outage and their budget.
Getting clients to focus on a rational Recovery Point Objective (RPO) and Recovery Time Objective (RTO) can be an effective tool to really and truly force them to consider the true cost of emergency downtime and the rational case for a complete, or more complete, business continuity solution for their business.
The concepts are best presented at the beginning of assisting an organization to develop or revamp a disaster recovery plan. Here are some keep-it-simple suggestions for a boiled down presentation of RPO and RTO:
Recovery Point Objective (RPO): The maximum period of time allowed in a disaster recovery plan in which data might be lost and unrecoverable.
Explain that backups can be set at different intervals. Set the backup at a once-a-day interval, and a business can lose a whole day’s data. Set the interval at 15 minutes, and it can lose only 15 minutes of data. Create an active – active high availability virtualized environment and they will rarely encounter an outage providing for true business availability. Different RPOs are possible for different types of data.
Recovery Time Objective (RTO): The maximum period of time allowed in a disaster recovery plan between when critical network functions cease and when they are restored.
Point out that one business might decide to back up file and folder data only (that is, without the applications and associated configurations, settings, drivers, etc.) This might seem relatively inexpensive, but in an emergency, the DR plan would need to allow time for the physical replacement of a destroyed server and critical applications followed by restoration of the file and folder data. That is could mean a very long and costly recovery. Better might be to opt for creating a backed-up image of all critical applications and their configurations. The result would be bootable images of all critical servers and a much shorter but still significant RTO in some cases. The ultimate in disaster recovery is when RTO approaches zero by immediate failover to an alternative virtual server in the cloud.
As a suggestion, one might explain that as RPOs and RTOs lengthen, the cost of ensuring business continuity decrease, but the losses from the disaster, while the business deals with downtime and lost data, will increase. As RPOs and RTOs shorten, the cost of business continuity goes up somewhat, but the recovery in any disaster becomes faster, even near-instantaneous in some cases, with less lost revenue and fewer wasted resources.
By positioning the business continuity market as a spectrum and helping your client determine where they fall on it, that is, what degree of risk and DR cost they are able to accept, many MSPs have successfully leveraged the concepts of RPO and RTO to target and close business.
Axcient can help you find and position the right solutions for your clients. Our x360 Platform guarantees RPO of 15-minutes and RTO of less than 1-hour, and creates the right mix of solutions to ensure you meet your customers’ RTO and RTO requirements.
More Great Stuff From Our Blog:
Check out some other interesting pieces from our blog: Learn more about how Axcient supports partners with No-cost Onboarding and Ongoing Training, we dove into how chain-based backup works and why chain-free is the way to be, we talked with Jason Phelps from Huntress Labs about planning for the next ransomware attack, our CEO David Bennett explains why the current cybersecurity landscape means traditional backup is dead, or learn how you can ditch pricey on-site appliances with Local Cache for Direct-to-Cloud BCDR.