Virtualized disaster recovery has taken some of the complexity out of DR, but many administrators either misconstrue...
or misunderstand the benefits of this paradigm shift in the virtual world. Critically, virtual DR must still remain true to the end result of DR.
The three key pillars of good DR are:
- Recovery time objective: How long before systems are available again.
- Recovery point objective: The point in time from which the data should be available.
- Functionality: Ensures the DR instance functions as expected, and that servers come up as planned and work as intended.
Benefits include functionality, ease of use
Any DR test has to successfully tick all three boxes to be considered a success. What makes virtualized disaster recovery easier is that it can use functionality that is not available in the physical world.
For example, virtual machines can be grouped together for crash consistency, which means, if there is a failure, all the machines are in lockstep with each other and will revert to the same point in time. That functionality isn't available in the physical world.
Properly used, crash-consistent protection groups can put all the layers of your application together and treat them as one logical, consistent unit or protection group. Your organization can instantly fail over the group of machines and test them. This ease of use doesn't exist within the physical world.
In another win for virtualized DR, all the settings for the real world and isolated network during a test are populated at crash-consistent group creation time. All the hard work is done upfront, and it typically takes three or four mouse clicks to fail over entire groups of servers or applications. In a real-world scenario, such ease of use and planning means there is a vastly reduced possibility of clicking the wrong buttons.
In a virtual world, there is also some form of protection against crypto-ransomware. Virtualized disaster recovery vendors such as Zerto and Veeam enable the administrator to revert to a single point in time from tens of checkpoints that are automatically taken every few seconds; it's like snapshots on steroids. With these products, it is possible to roll back to seconds before an attack. But note that this is not a substitute for good security practices and backups.
Testing, testing: Be careful with networks
With virtualized disaster recovery, the virtual infrastructure can be leveraged for the win, so use it. Unlike physical environments, there is no limit to the number of networks that can be used.
A server can be failed over to an isolated network and tested while production is still up and running -- with some care and attention. A separate network can be used for real DR failovers. Having separate virtual networks for both real DR and testing is a must. Not doing so will end in tears.
Try to have only one functional test network per site. This makes it easier to manage the environment, and any machine that comes up on that network can be easily identified as a DR functional test. It is critical that the test network be physically isolated from the production environment. If the servers being functionally tested can communicate with other networks, there are risks of corruption, for example, with Active Directory, due to having two machines with the same host name trying to register with the AD server.
Virtualized disaster recovery makes DR much easier, quicker and less error-prone. The downside is that, to use the technologies mentioned, the whole stack and all the dependencies need to be virtualized. If ever there was a reason to migrate those few lingering physicals, this is it.
How virtualization can speed up and simplify DR
Be prepared for virtual backup and recovery
Avoid common virtual server backup mistakes