3 myths of disaster recovery and cloud computing

DR (disaster recovery) is one of those topics that is addressed each time applications or a data set is placed into production, but often it’s just a checkmark. Deploying applications to public clouds should be no different. However, some confusion has arisen. I’ve looked into this and found three cloud-based disaster recovery myths that seem to be derailing enterprises as they move to the cloud.

Myth 1: DR is not needed because it’s already built in to public clouds.

The confusion here is that some basic DR features are systemic to public cloud providers; they have backup systems in case of hardware failure or actual disasters. But their systems don’t consider the specific DR needs of tenant-owned workloads.

This is typically not discovered until data is accidentally deleted or executables become corrupt. The public cloud providers can take care of big issues, such as racks of hardware cooking due to a power surge, but they can’t typically deal with smaller issues, such as you losing data from a database or files.

Public cloud providers promote a “shared responsibility” model, where they provide DR for their cloud services so they can keep running through outages and disasters. You, however, are responsible for backing up your own data and applications, as if you actually own the virtual cloud servers you’re running on.

Myth 2: Separate DR planning and processes must occur around each cloud service.

You can certainly back up a cloud-based database using export and import tools native to that database. However, it becomes a complex mess when you multiply those services 20 times and add different DR requirements for AI services, IoT services, or analytics services.

Most public cloud providers offer backup and recovery managers that are built in to the public clouds. You can use these tools to pick resources that you need to back up, to automate that backup (when, how, what, etc.), and finally, to fulfill any security, governance, or logging requirements. The advantage of leveraging these tools is that in a single place you’re able to manage most backup and recovery operations which span many different public cloud services. You remove the complexity by placing volatility into a configurable domain.

Myth 3: Compliance processes around data protection and security extend to data that’s backed up for DR.

This is a good way to pay some heavy fines. Some data, such as personally identifiable information or some financial data, is regulated no matter if it sits on a production server, a backup server, or even on magnetic tape (blast from the past).

This relates to cloud computing because virtual backups that move data from a primary to a secondary storage device on public clouds, in support of DR operations, may neglect to follow the same policies and security as the data sitting on the primary cloud-based storage device.

In some cases, even backing up data to different geographic regions of the world, such as copying data to out-of-country cloud servers in different regions, is illegal. Most of the time this isn’t understood until you fail a compliance audit.

DR really needs to change when moving to public clouds. Although the tools and backup resources are available on demand, enterprises still need to do some careful planning for how to use them. With all these myths out there, and lacking best practices, most enterprises moving to cloud computing are confused about what DR means.