VMware disaster recovery best practices for enhanced security

An explanation of VMware DR

Historically, DR was a messy process and required many manual interactions to start up a DR service. VMware DR benefits in the same way as VMs do from physical machines and enables for quicker, more dynamic DR failover.

VMware DR provides greater flexibility over DR processes because almost all VMware-based DR is done by block-level replication, such as with Zerto and Veeam. Most VMware-based DR products also enable you to pick a point in time to restore from because they retain point-in-time snapshots (PIT snapshots) taken every few seconds.

VMware DR can be thought of as working at several levels. Most of the upper level VMware products come with a host of technologies to help ensure VM availability. This includes cluster-level VMware DRS.

VMware DRS detects and restarts any failed VMs on alternate hosts. This means a small amount of downtime while the failed VMs -- or group of VMs -- restart on an alternate host. This isn't a perfect fix, however, for application-level failures. One very useful feature of VMware DRS is you can apply rules to VMs to separate them and ensure they never reside on the same host, which is ideal for clustered applications.

VMware DRS helps you protect applications and enable DR at the VM level. VMware-based DR products ensure application integrity and availability against hardware failure, data corruption and ransomware. There is also the case of not having one-to-one physical server setup that must be kept in a warm state inside the DR data center.

Most forward-thinking organizations use the major cloud providers to virtually fail over their applications to, which eliminates the need for expensive hardware. Cloud backups also come with reduced prices compared to secondary physical sites. Most VMware-based cloud providers don't support physical machines for end customer use because they're inefficient.

The only potential issue in the panacea of cloud backups is the scenario of many organizations wanting to virtually fail over their applications to the cloud. A large influx of failovers can lead to resource shortage.

Become familiar with common disasters in VMware environments

You can break down most common types of disasters in VMware deployments into three main categories:

Failed application upgrades. If there isn't a previous PIT snapshot, the answer is to fail over to DR.

Ransomware. If a system becomes infected, multiple PIT snapshots to fail back to are extremely useful. These PIT snapshots can reduce information loss because the restoration points are so frequent.

Human error. If you accidentally delete a file or group of files that you can't restore, it then becomes a straightforward process to fail over to DR. Some advanced VMware DR products enable recovery of those files and quicker service restorations.

Because VMware servers carry a wide collection of VMs, there isn't one specific set of VMs affected more than others. But certain types of VM loss can have an outsized effect on service availability, such as middleware databases.

The loss of a database server can affect several applications dependent on that server. There should always be a tier associated with application groups. This means critical applications should receive priority in the event of a failure.

VMware DR best practices to ensure workload availability

Nothing can make up for a lack of a proper backup scenario as a last resort. Best practice states you should follow the 3-2-1 backup strategy, which dictates you should keep three copies of your data on two different types of media with one copy off site. Most modern backup products let you place one copy off site with replication to the cloud, as well as offers immutability to protect the data from nefarious actors.

The integrity of these backups is also crucial. Best practice dictates periodic testing of backups to ensure they work. This is where VMware makes testing much easier. Most VMware-based backup services enable easy restoration of a VM without issues, such as restoring a VM to the cloud in a disaster scenario.

What's even more useful is you can restore a VM to an isolated network so it doesn't impact production while you test the restored VM. These features help ease potentially difficult and fiddly testing scenarios and enables you to test on demand in isolated environments without affecting production.

The easier it is to restore, test and delete a VM means you are more likely to test those VMs and increase confidence that, should the worst happen, the VMs won't fail.