BACKGROUND IMAGE: iSTOCK/GETTY IMAGES
While virtual machine disaster recovery is a game-changer compared to physical DR practices that tend to be slow and inflexible, there is a potential downside. Good DR doesn't just happen; it has to be planned, managed effectively and tested appropriately. While manually capturing the data and details required to set up, configure and manage virtual DR may be straightforward for small environments, this approach doesn't scale well.
Servers get provisioned without proper authorization or cost allocation, which leads to virtual machine (VM) sprawl. What makes VM sprawl particularly insidious is that these sprawl production machines frequently tend to slip through the provisioning cracks. As they say, the rules are there for a reason, for example, to catch deployments that require special handling such as virtual machine disaster recovery and the VM's dependencies.
During normal provisioning, capturing the requirements and ownership data is not an issue. When performed outside the provisioning process, a lot of the critical information that will be needed in a virtual machine disaster recovery situation or even day-to-day support has not been collected and stored properly, which makes both tasks more difficult.
Properly protect production
Even worse is the fact that the VM or service may not have a DR test plan or owner. Frequently, administrators find production machines that are not DR-enabled. Documentation and DR setup may not have occurred.
If the DR manager is not aware of these machines, it may not become apparent until a real DR scenario occurs. Should the business group or owner believe that virtual machine disaster recovery has been enabled and it hasn't, it can cause not only loss of faith in the provider, but a significant financial hit.
Bigger companies are notoriously bad at communication, which is why every production VM should go through a full production deployment. User acceptance testing and development VMs should never be repurposed into production virtual machines for exactly this reason.
Going through the proper deployment process should catch these issues before they become critical. Doing this correctly also means that the owners are properly noted, the costs are apportioned and there is a chain of command and decision-making for the VM.
These are all things that no one wants to be doing should virtual machine disaster recovery actually be needed. It is in the interest of the business to check and cross-reference the VMs against the DR plans at the predetermined interval. Not every machine will have a DR plan, but doing this exercise will allow those rogue machines to be identified and remediated as needed.
Take advantage of benefits of virtualization to improve DR strategy
Does virtualization really make business continuity easier to implement?
VM disaster recovery: Third-party or native replication tools?