At many enterprises, backup and recovery are two elements of a single function. Anything backed up, after all, needs to be recovered at one time or another. For service providers like Bluelock, however, they represent two very different things. As the company’s CTO, Pat O’Day, tells IT Business Edge’s Arthur Cole, it’s a matter of simple data restoration or full data and application infrastructure. Both services are useful for certain data environments, so it’s important to know the right way and the wrong way to implement them.
Cole: Many enterprise executives assume that Backup as a Service and Recovery as a Service are one and the same. Is there a distinction to be made here?
O’Day: The biggest difference is how much time it takes to recover; the RPO and RTOs are very different, with Recovery-as-a-Service being much faster for each. Another main distinction is that with Backup-as-a-Service there is no infrastructure on which to recover. With Recovery-as-a-Service, however, the data and the infrastructure are available from which to recover.
Cole: Since Backup and Recovery are so intertwined, wouldn't it make more sense to package it as Continuity as a Service or something similar?
O’Day: Because there is no infrastructure on which to recover with backups, backups aren’t a true continuity plan. Recovery-as-a-Service recovers whole applications, whereas backups recover just the data.
The distinction is really about data vs. application recovery. Recovery-as-a-Service offerings are worried about the applications returning to service, not just recovering the data. While we understand there are limited use cases where recovering data without the application may be useful, in our experience we’ve seen the vast majority of those clients we support need to support running whole applications with Recovery-as-a-Service services as opposed to just recovering the data with backups.
Cole: There is also a temptation to 'set it and forget it' when it comes to B&R. What are some of the ways the enterprise can remain proactive once these functions have been converted to third-party services?
O’Day: There are two modes in which Recovery-as-a-Service exists. “Day 1” refers to implementation day, when everything gets set up. “Day 2” refers to everything after implementation day, meaning the rest of its operating life.
We believe “Day 2” operations for recovery are even more important than the implementation itself. Just like any skill, whether it’s riding a bike or playing the guitar, the more you use it, the better the skills get.
The best way to continually exercise your recovery plan is to proactively schedule and conduct testing. Tests can be done based on a particular time period, like biannually or, we’ve seen a lot of companies conduct testing based on seasonal risks. If companies are located in data centers vulnerable to hurricanes or tornadoes, they can test more aggressively around those risk patterns. We recommend you orient your test schedule around unique factors to your company’s risk.