Replication using vembu

As promised here is the post which covers replication feature of Vembu. If you have gone through host based replication feature of VMware you may not find some difference. Considering the fact that both tool does the same but Vembu is product which is backup plus DR and hence is referred Vembu Backup Disaster Recovery Suite (BDR).  Why do you replication? Isn’t backup data sufficient to recover. In most cases this is old school. In today’s cloud world SMB and enterprises are looking forward to storing their data in DR site, public cloud or offsite which is more appropriate word.

Replication for any Virtual machines can be configured in five easy steps. You must configure replication job. My experience in configuration this job is shared in various screen below which I captured. Let’s start


Under VM Replication Tab (shown below) select VMware vSphere

VM Replication in Vembu

You will be redirect to Manager VMware vSphere Server screen where I selected Replicate Now option. It is repetition but it is high important that application aware processing has a list of prerequisites which has to be met.

Step:01 Replicating VM using Vembu


I decided to select couple of VMs which I wanted them to be part of replication job. I noticed that backup and replication job configuration are almost similar as disk exclusion was part of backup job as well.

Step:02 Select the VMs which needs to be Replicated


Select the replication frequency. You can replicate VMs starting from every 15 minutes till 24 hours, daily or weekly.  Again this is similar configuration step I came across while setting backup job.

Step:03 Configuration Replication Frequency


This is very unique step in replication job. Please watch closely various options. Here you need to configure remote ESXi/vCenter. You do not need a vCenter which is unique with Vembu as with other vendors you need a vCenter in the destination site. As a first step, add VMware Server. In my case I choose to replicate VM to same vCenter. Then in second step choose a ESXi host where you want to host the VM which is mandatory as if you are replicating using vCenter. Second steps selection will influence the datastore available in the drop down. It may happen that you wish to replicate to local datastore in scenarios where destination site has only one ESXi host. Finally select the name you wish to propose of VM at destination, followed by number of retention copies you wish to retain any point in time.

Step:04 Configure DR server for VM Replication


IN DR strategy the most critical element you need to decide whether the IP Address will remain same in DR site or it has to be different when DR occurs. This decision will drive the selection of the options in the following screen. Since I’m replicating in same vCenter I have skipped this step by de-selecting Configure Networks checkbox

Step:05 Optional in case you wish to change IP Address in Destination VM


Depending upon what was the decision made in earlier step, following step can be either skipped or should be duly filled. If you wish to skip this screen deselect Configure Network Re-IP Mapping

Step:06 Re-ip Mapping in Vembu

If you have decided to re-ip, you have to add a rule. A rule chiefly states the source and destination IPs you wish to configure along with DNS servers

Add Re-IP Rule


Review the configuration screen. Enter the name for replication job. Now run the replication job.  Since I have selected Replication every 15 minutes I do not get the option to save the job but to run the job

Step:07 Review the Replication job in Vembu

Monitoring Replication Job

Full Replication job of 40 GB took 10 minutes to complete and subsequent replication jobs are completed in minutes

Replication Job completion time

Recovery of Replicated VM

To recover VM you have to go Manage Replica which is in Recovery Tab.

Now that I have explored the replication option let me walk through the recovery option.


Go to manage replica and initiate restore process using the Icon shown below



Typical DR scenarios are mentioned. When you move services from Production to DR it is referred as Failover and when you move service back to original production site, it is referred as Failback. Please note failover can be planned or unplanned but failback is always planned.



For the purpose of this demo I restricted my options to Failover.  Now from here onward it is restore job wizard which is common across VM, file and replica restore. In below two screens I selected to which point I should restore and what I should restore from that restore point.

image     image


Review the restore job and start failover.


Over all I can say VM based replication is added bonus to the clients who wish to protect data as well ship it offsite. It is very beneficial when a product has a capability to serve multiple purpose.