In January of 2017, Sander did a review of Vembu BDR. Albeit a short one, he does state that Vembu is on the right track and if you’re looking for a quick and easy backup toolkit, Vembu is one you should take a look it. Recently Vembu contacted us to ask if we would take another look at their latest edition of BDR. This time I was the lucky one.

When you are interested in Vembu’s solution and you go look for the software on their website, you get offered the Windows version of their suite only. This is fine, but in the VMware ecosystem we’re a bit spoiled. We like appliances. Why, you ask? Because appliances are easy. The vendor can dictate what resources they want their appliance to have, install their solution according to their own best practices and make sure I as a user get a functioning environment without having to go through an install-and-configure motions where I can do all sorts of things wrong and get a bad experience with the software.

Vembu does have an appliance version, but you have to request it. It’s not easily downloadable from their site. Then again, once you request it, their support is quick in responding with an URL where you can download the appliance versions. They have one for VMware and one for HyperV.

Installation

Deploying the OVA is easy and follows the normal steps. I will not go into that as it is more or less a standard excercise to follow and we’ve probably all done it. But there is one exception here: the network settings. The appliance is set to DHCP and has no VMware tools installed, so you do not see its IP address in vCenter. You have to go into the appliance via the console to get the network address from the command line to know where to log on to. No real problem but something that could have been avoided quite easily.

What does strike me is the amount of resources the appliance is demanding: 8 vCPU’s and 16 gigs of RAM for a backup appliance is quite a firm resource occupation in comparison to the functionality. With that, it does give you a snappy interface and quick responses to requests but it feels a bit oversized. Because the appliance is build with Ubuntu and I’m quite familiar with that, I decided to modify the appliance slightly and add the Open-VM-Tools to it to have it support my scenario a bit better. Now I see the DHCP address that it got assigned in my lab environment in vCenter.

The Interface

Once logged on, the interface seems quite minimalistic and a bit confusing. I do have to admit it’s the first time I have social media buttons for the vendor’s social media channels in the main dashboard screen of the software. A bit misplaced if you ask me. And there appear to be 2 notification spots. One bottom left and one top right. A bit confusing. The dashboard feels minimal. Looking for status information is more of a journey. It can use a bit of work to be more intuitive and interactive.

The First Backup

Obviously I was curious to see how it performs. I used the onboard storage for a first backup, which has about 450 gigs of capacity. My first backup was a dump of 2 small VM’s that run on my colocated VMware host that is connected to my home via a VPN tunnel that has about 100Mbit of network bandwidth capacity. The 2 VM’s in question are 2 Linux VM’s that together have around 70 gigs of data to transfer from the colo to my home lab.

Configuring a backup is quite easy. You enter the IP address or hostname of your ESXi host and the login credentials. That’s a one time thing. Next you can select any VM on that host for backup. No addional software required. You can decide to use the application or open file aware option but this only works for VM’s with Windows installed and since the 2 VM’s I backup are Linux VM’s, I skip this step. Next you can decide to have your backup scheduled, encrypted and compressed. I decide I would like this to be a weekly backup, encrypted and compressed. The final step is to give the job a name. I had a small irritation here: you cannot use spaces, so it has to be something with either dashes or underscores if you want it to consist of multiple words. And then we’re off!

So, apparently the job is running but I can’t find a status window anywhere. It took me some time to figure out I have to go into the backup option again, select list, then click on the green arrow indicating the job is running and I am presented with a status screen that kind of looks like a JAVA screen from the late nineties. It also states in that screen that it is just to glance upon and you best leave it closed for best performance. A bit unsatisfying, I must admit.

The First Crash

Then, suddenly, the interface stops responding and I am logged out. When I try to relogin, the main page says the VembuDR service is not running. That’s odd. So I log into the appliance and indeed it has crashed. So I restart the service and I am able to login again. The backupjob had crashed but was resumed after the service restarted, so kudo’s for Vembu for that. But it really shouldn’t have crashed in the first place. So that too was a bit unsatisfying.

What was even more unsatisfying was the speed with which the backup proceeded. As it were two small VM’s I picked to backup, I was under the impression it would be quite speedy, but that was not the case. In the end, it took a whopping 21 hours to transfer a bit short of 70 gigs through a 100Mbit VPN tunnel. I’m not sure what was the cause of that. I’ve seen quite OK speeds using vSphere Replication like 60 to 80 Megabits. This does not even come near those values. It hangs around 10Mbits. But in defense of Vembu, there are quite a lot of components involved and any one of them could be a critical factor. After 21 hours it did finish the backup successfully.

Backup Part Two

After having tried the remote ESXi server, I decided I wanted to try a local backup to see if those speeds do convince. To do so I need more storage space than the standard on board. I run an HPE Microserver with FreeNAS, as you may remember. That NAS has an NFS share called “Backup” and it has 1.5Tb of free space. That should be a winner, as Vembu supports mapped drives and NAS connections. Or does it? Nowhere in the interface I can find the option to connect a remote folder, mapped drive or NFS share. In the manual it shows that in the Storage Configuration screen it should have a second window with NFS but my installation lacks that window. Maybe I’ve done something wrong?

As it turns out, I have not. To have an NFS share mapped to the Vembu appliance for VMware, you need to be a bit Linux savvy. You have to configure it by hand. Create a directory to mount it to, mount it to make sure it works, then add that mount to the /etc/fstab file to make sure it gets connected each time the appliance boots, otherwise you would loose the connection to your backups. Once entered in the fstab-file, it will appear in your storage configuration window.

After that excersise, it was easy to configure a second backup job saving 2 small VM’s to the newly created datastore. I was curious to see what the performance was on that. It took 55 minutes to dump about 35 Gigs to storage, which is on average 100Mbits of data throughput. On a Gigabit network with multiple links to the storage and an SSD cache of 256 Gigs, that is not the best I’ve seen. On disk it takes about 22 Gigs of storage space, which is quite good compression 30% on average. Bare in mind that these were thin provisioned disks with not much else but a Linux OS and some application files. So no good case for dedup and mainly executable files for compression.

The Restore Test

What good is a backup suite if you can’t restore? Exactly. So I also restored one of the previously backupped 2 Linux VM’s I used in the previous scenario. I decided to restore it to the remote host of first scenario. Going through the motions of restore is quite easy. If you’ve ever worked with backup software, the options will make sense to you. And now for the surprise. Whereas the backup of the VM took much longer than expected, restoring it went in a flash! In no time was the 15 Gigs of VM data tanked onto the remote host and the VM was booted. I was really impressed by that. But the funniest thing was, I cannot find a report or a log of the restore anywhere in the console. I’ve looked through all the screens but it never states it has done a full blown restore to a remote host. So where the performance this time is really impressive, not logging it at all is not. Having said that, I’m sure it’s logged somewhere but in the consoles I can’t retrieve it.

The Replication Test

Another thing Vembu can do is replicate a VM between 2 hosts. This is kind of like vSphere Replication but on steroids. You obviously need to or more ESXi hosts to make this work. Once access to the hosts is configured, you can then browse a host for a VM you want to replicate to the other host. I decided to go with the big boy in my remote site. I have an Exchange 2016 server running there with about 700 Gigs of storage. It handles the email traffic for my entire family. It’s not really busy but it does have something to do so I went for the Application aware option and entered the administrator credentials to make sure the data is snapshotted correctly. One good thing about the Vembu BDR is that you can configure the network portgroups it needs to adjust to make a failover so you can manage the failover from within the Vembu console.

For the replication from one ESXi to another I do not need any local storage. The replication engine transfers the data directly from the datastore from my remote ESXi host to my local ESXi host. The remote ESXi host uses local storage on either SAS or SATA2. The local ESXi host uses iSCSI storage to which it is attached via 4 network connections of each 1 Gbit. This should have plenty of performance to do a site to site replication. The VPN tunnel should be the bottleneck with 100Mbit of bandwidth.

So I took a closer look at the speed and performance. Both ESXi hosts are not idle but have plenty of bandwidth available. The VPN tunnel is practicully empty. Yet, the backup speed is between 13.5 and 17 Mbit/s. Faster would be better. I cannot see what is causing the speed to stay at that level. It may have something to do with the compression but that is pure speculation from my end. I do not see high CPU usage or any other contention on either host.

So, the failover test we will have to do another time. My current setup does not have enough resources to add the quite heavily configured Exchange server to it. I can confirm that the replication was finished succesfully and all VMDK’s can be opened and its contents looked at. For now that is good enough for me.

The Conclusion

In conclusion I can say I have mixed feelings about Vembu’s BDR. On one hand it does what it needs to do. Sometimes quite well, sometimes it leaves things to wish for. The remote backup job was a bit disappointing from a performance standpoint. The restore job, however was done in a flash and up and running in minutes. Something you would really want when you are in dire straits.

The interface is a bit inconsistent with the status screens as a low point. The whole experience has a bit of a learning curve that may not be for everyone. An interface designer would certainly have some tips and tricks here. Not being able to configure network mounts from the interface is really a lack of functionality.

All in all it does what it needs to do, it has some quirks  and it does leaves things to wish for. But it also does some stuff really great and if that is what you’re looking for, this might be a solution for you.