An extremely important facet of data protection when it comes to VMware vSphere environments is configuring virtual machine replication. Replicating VMware vSphere virtual machines allows for protecting business critical workloads by ensuring organizations that are resilient against a total site failure. By utilizing a data protection solution that offers replication, virtual machines can be replicated from the production site to a separate DR site. The virtual machines that are created in the DR or secondary site are exact copies of the production virtual machine workloads. With each new replication iteration, the available recovery point objective gets updated to the current replication point. Replication is a crucial component of a VMware vSphere disaster recovery plan. However, what are VMware vSphere Virtual Machine Replication Best Practices that should be followed?

VMware vSphere Virtual Machine Replication Best Practices

There are several VMware vSphere Virtual Machine Replication Best Practices, those practices that need to be considered to ensure the VMware vSphere replication is effective, efficient, and meets Recovery Point Objectives and Recovery Time Objectives. Let’s take a look at the following:

  • Use Changed Block Tracking
  • Utilize Application Consistent Replication
  • Keep Multiple Restore Points on VM Replicas
  • Size a DR environment properly (Computer, Memory, Storage)
  • Seed Large Virtual Machine Replicas

Let’s take a look at each of the above best practices one by one and see why each is important.

Use Changed Block Tracking

Download Banner

Back in vSphere 4.X, VMware introduced a technology that has since drastically improved the efficiency of backup processes in vSphere. It is called Changed Block Tracking or CBT. Changed Block Tracking allows much more efficient backup AND replication iterations since it keeps track of the changes since the last backup or replication interval. This is extremely important because it means the backup or replication job knows the exact changes that have been made at the VMDK block level and only copies those changes to either backup storage or to the replica virtual machine in the case of replication. Be sure to utilizing a data protection solution that allows making use of CBT in both the backup and replication jobs.

Utilize Application Consistent Replication

It is extremely important to make sure that business-critical application virtual machines are backed up and replicated using “application aware” backups and replication. Application aware backups properly quiesce the operating system and also interact with special VSS writers for specific applications such as Microsoft SQL Server to make sure the transactions that may be in memory are flushed from memory and written to disk properly before the backup or replication interval. Many may remember to turn on application consistent options for production backups but not for replication. However, if replicating from live, production virtual machines that are running, make sure to use application consistent replication so as to make sure the “warm-standby” VM at the DR site, is in an application consistent state. This minimizes downtime and can drastically improve recovery time objectives (RTOs).

Keep Multiple Restore Points on VM Replicas

A great feature of a solid data protection solution that allows proper replication of VMware vSphere virtual machines is the ability to keep multiple restore points on VM replicas. Keeping multiple restore points allows different points in time to be utilized for a replicated virtual machine. An example might be a user introduced data loss on a server that was replicated. The latest replication restore point may contain the data loss. However, the recovery point the hour before has the complete data set. Replication restore points are generally represented by VMware snapshots on the replica virtual machine that exists in the DR environment. With Vembu BDR Suite the number of recovery points is configurable for the replicated virtual machines.

Size a DR environment Properly for Failover

A mistake that can be made with DR sites and replicated VMs is not sizing the DR site to meet the demands of a potential failover event. Businesses may undersize the DR site environment for fiscal reasons. Granted the number of absolutely mission critical virtual machines that need to be failed over may be much smaller than the number of actual running virtual machines in production. This may allow for a bit less compute, memory, and storage resources to be present at the DR site. However, there is a balance between saving on resources and creating a situation where a failover event may totally overwhelm the provisioned resources at the DR site. Additionally, to simply replicate the same number of production virtual machines to a secondary or DR site requires no resources other than the network resources needed to copy the virtual machine across. Powering on all the virtual machines however, is a much different story. Organizations need to verify provisioned resources at the DR environment very carefully to ensure all mission critical virtual machines are covered from a capacity standpoint.

Seed Large Virtual Machine Replicas

Comparatively speaking, WAN connections are still very expensive connections. Replication traffic is generally going to traverse a WAN connection to reach a different geographic location where the DR facility is located. If you have several large virtual machines that need to be replicated, make use of a “seed” drive to avoid unnecessary network traffic. A seed drive allows performing the initial copy of the virtual machine from the seed drive, thus bypassing the network. Then subsequent replication copies are able to utilize changed block tracking to copy on the changes reflected from the base copy compared to the new replication interval. This alleviates any strain on the WAN connection to perform the initial replication of the virtual machine across from a production site to a DR location.


VMware vSphere virtual machine replication allows organizations to withstand a complete site level failure where a production site is completely down. By having replica virtual machines located in a secondary site, network and data traffic can be failed over to the warm standby virtual machine replicas. This allows organizations to formulate a robust contingency plan in case business services or communications are disrupted at the main production facility. Business want to utilize a data protection solution that allows them to meet VMware vSphere virtual machine replication best practices as mentioned. Vembu BDR Suite is a powerful solution that allows businesses to effectively meet RPOs and RTOs by performing image-level backups, virtual machine replication, and backup copies stored offsite, in the cloud, and to tape. By leveraging Vembu’s BDR Suite solution, organizations are able to follow the data protection best practice 3-2-1 strategy of (3) copies of backup on (2) different kinds of media, with at least (1) copy offsite.

Experience modern data protection with this latest Vembu BDR Suite v.3.9.0 FREE edition. Try the 30 days free trial here:

Follow our Twitter and Facebook feeds for new releases, updates, insightful posts and more

Like what you read? Rate us