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.

Copyright © 2020 IDG Communications, Inc.

Source link