kentoh - Fotolia
One of the major benefits of virtual disaster recovery is its speed and high availability. Unfortunately, bandwidth constraints can affect these data transfer speeds and may become a virtual DR plan's Achilles' heel.
In virtual disaster recovery, one or more virtual machines (VMs) fail over to the cloud or to a remote data center. The VMs are able to remain online and functional during a disaster, even in a large-scale incident. While slow data transfer speeds don't necessarily mean that a VM disaster recovery plan is doomed to fail, there are several ways in which they can completely undermine an organization's disaster recovery initiatives.
One of the most obvious ways in which low transfer speeds can impact an organization's disaster recovery initiatives is in the replication process. In order for VM disaster recovery to work properly, a VM's contents must be replicated to the remote site. Once the initial replication process completes, the VM must be kept in sync with its replica. If a storage block on the VM is modified, then that modified storage block must be copied to the off-site replica VM.
This ongoing synchronization process usually works well. However, if the VM's contents change frequently, it can be a problem. If a VM consistently has a change rate that exceeds the transfer rate, then the replication engine will be unable to keep pace with the changes, and replication will eventually fail. This tends to happen if an organization tries to maintain a synchronized replica of a high-performance database server.
Another way in which data transfer speeds can affect VM disaster recovery efforts is in a situation in which only a partial failover occurs.
DR planning is often designed as a contingency against a data center-level failure, with all of an organization's mission-critical workloads failing over to the remote site. However, a less severe disaster could conceivably cause some workloads to fail over to the remote site, while other workloads continue to run in their original location.
With this in mind, imagine a situation in which an application server fails over to a remote site, but the database server that the application depends on continues to run in its original location. In that situation, all database transactions would have to pass across a WAN link. Depending on the transaction rate, the application could become much slower, or it may stop working altogether. The key to avoiding this type of situation is to create failover groups of resources that should always fail over together.
5 common VM backup mistakes
Dig Deeper on Disaster recovery planning and management
Related Q&A from Brien Posey
When backing up SAP HANA databases, having the right tools for the organization is critical. Data snapshots are one option, but not the only one ... Continue Reading
Public bucket access is a prevalent and discussed S3 security issue. However, there are several other important security measures to take, including ... Continue Reading
Tape still plays a key role in backup, including offline protection from ransomware. What are some key improvements that will keep tape backup ... Continue Reading