In part 1 of this review we’ve backed up our data and ensured that it is restoreable. Now let’s continue our review of the Vembu BDR suite by having some fun and actually start restoring some data! That said, before we jump right into performing a restore I want to talk a little bit about a nifty technology that BDR uses for most of its’ restores– the Vembu Virtual Drive.
What’s the Vembu Virtual Drive
The Virtual Drive is a technology that is installed when we initially install the BDR suite and is essentially a second hard drive on our BDR server. This drive is used by Vembu to hold metadata, or pointers if you will to mounted backups on our BDR server, therefore it requires very little extra space, only 512MB to be exact as it just points to already created backup files. As we can see below, when a backup is mounted Vembu actually makes your backups available in many different formats. For instance, the backup shown below is for a physical windows server, however Vembu presents us with this data in both VMware and Hyper-V formats (vmdk, vhd) as well as IMG formats (ISO). Although displaying the backups in these various formats is in itself not magic, the fact that BDR does this within seconds is truly incredible – and not just for full backups either. Incremental backups can be displayed and restored to the various formats in seconds as well! The secret sauce to all of this lies in the Vembu Hive file system – which provides the means for BDR to efficiently expose it’s incremental backups a virtual full backups without having migrate or merge any data at all – meaning you can get at your data almost immediately and restore to almost any platform with ease!
Vembu uses these various formats presented by the Virtual Drive technology to power most all of it’s restores, and this is how BDR can take a physical server and convert it to a virtual machine – or a VMware VM and convert it to a Hyper-V VM. This is a functionality I’ve not seen in many other backup products and is very useful in my opinion! Thankfully, this functionality is exposed within the UI as well, so if we wanted to manually mount a backup without doing a restore we could do so by simply clicking the ‘folder’ icon within the mount section of the Recovery screen (as shown below).
Although we could use this manual mount to pretty much restore any source to any target platform it would certainly take some manual configurations and probably a little time on our end to do so. For this reason, Vembu has some built in restore workflows that we can use by clicking the ‘Restore’ icon showed above. Depending on the source of of our production data, whether it was Hyper-V, VMware, or a physical server we will get some different options as it pertains to restoring our data.
As we can see, Instant VM Recovery, File-Level Recovery, and Download are available no matter what the source platform was – with Live recovery options added to our VM based backups, and a disk/partition level recovery included with our physical machine backups. To go through all the recovery options within all of the supported source types would be a very time consuming, and quite honestly, duplication of work as the wizards and steps used to perform each type of recovery are very similar – which is a good thing! Instead, let’s take a look at some of the most popular recovery options and go through the motions.
Instant VM Recovery
Let’s first take a look at Instant VM Recovery within Vembu BDR, and for this we will do so inside of our Hyper-V environment. Instant VM Recovery really lives up to it’s name as it provides us with a ready state VM which is a duplicate of our production in almost an instant fashion. To do this Vembu uses a couple of different technologies depending on the platform the BDR server is running on. For Windows based installs, Hyper-V is leveraged – For Linux, KVM is the technology of choice. Basically Instant VM Recovery takes our deduplicated and compressed backup files and directly boots them on the selected hypervisor, essentially transporting our backup files into a VM. Certainly performance of our VM will be impacted when running from these backup files, but this is more than made up for by the fact that we can instantly provide access to production resources, while we leverage something like Live Migrate or vMotion to move our newly recovered VM back to production storage!
To get started with this type of recovery simply select ‘Instant VM Recovery’ from within the ‘Recovery’ section of Vembu and we are brought into the ‘Restore Version’ settings. Here, we simply select the restore point, or restore version of which we would like to instantly recover to.
From the ‘Restore Data’ section, we are prompted to select the data (or in this case, the VM) that we wish to restore.
The ‘Restore Options’ step gives us a little flexibility on how we would like to recover our VM, and the options presented greatly depend on the ‘Instant VM Recovery’ mode we select and the platform our BDR server is installed on. For instance on a Windows based BDR deployment, Hyper-V VMs can be instantly recovered in Hyper-V mode, whereas VMware VMs can be instantly recovered to either Hyper-V or VMware mode. Depending on which Instant Recovery Mode we select, different options will present themselves.
- Hyper-V – Instantly recovers VM on the Vembu appliance configured with the Hyper-V role
- Startup RAM – the amount of memory granted to start the newly created virtual machine
- Configure Network Details – Allows us to specify an IP Address and Subnet mask for our new VM
- VMware – Instantly recovers VM on a specified VMware host.
- Target VMware Server/Datastore – specifies where we want to run our new virtual machine
- VM Name – name of our new VM.
Since we are using our Hyper-V environment, I’ve selected Hyper-V here and provided the necessary information…
Once clicking through the review and progress screens our VM will actually be created within the Hyper-V environment directly on our Vembu Appliance, utilizing no extra space as the data is coming from the already existing backup files. As you can see below, I have a couple of Instant Recoveries which I’ve initiated. What we are left with is a VM booted completely from our backup files, instantly recovered. So in turn, we could instantly provide our end users access to the VM, and take our time migrating this VM back to a production environment.
File-Level Restore
The file level restore wizard (Recovery->Restore->File-Level Recovery) within Vembu works in a similar way to that of Instant VM Recovery, where we select our VM to recover, its associated restore point and finalize the wizard. However unlike Instant VM Recovery, File-level restore doesn’t create a new VM within our environment – instead it takes the contents of the virtual or physical machine backup and mounts them to a local drive within our Vembu BDR server. Shown below is file system on my Vembu BDR server – as you can see with a few extra drives. G:, being the drive belonging to the machine from our physical server, and Y: being a drive belonging to our backed up virtual machine, as I’ve initiated File-Level recovery for both those servers.
Once these drives have been mounted we can simply access the backed up data and do as we please with it, whether it be copying back to our production workloads or to another spot of our choosing. When we are done, we simply just need to go back into the BDR UI ‘Recovery’ section ‘Unmount’ our backups using the folder icon as shown below…
Once we have unmounted our backups we can see that the folder icon flips back to being closed.
Disk Level Recovery
Disk level recovery within Vembu BDR does just that – recovers individual disks, or partitions in the case of a physical server back to their original locations. That means individual vmdks can be restored to a VM, or individual partitions back to a physical server or workstation. Again, the wizard to perform a disk level recovery is much the same as all of the other recovery types, selecting a restore point and source, however differs only when selecting a target. As shown below we can see the disk level recovery options for restoring a single VMware disk back to the original VM by specifying the target ESXi/vCenter, along with an associated VM and datastore.
After completing a Disk Level Restore a new VMware VMDK disk is created and attached to the VM you have chosen.
Download
Finally we make our way to the last recovery option within Vembu BDR – the download option. Download uses the Vembu Virtual Disk technology explained earlier to mount the backed up VM and allow us to pull down various images of the backup, including VMDK’s, VHDX, and Raw ISO. That said, simply mounting our backup manually always selects the latest restore point whereas the download option allows us to specify any restore point on disk. Again, this is a really cool feature that I don’t see in a lot of backup software – being able to essentially convert your VM from platform to platform by means of the backup is a neat idea. Although there would certainly be some work to get everything working, it’s definitely a great starting point.
Failing over a replica
Now that we have got through all of our options as it pertains to restoring backups it’s time to look at one last restore technique that BDR provides – replication failover. If you can remember back to part 1 of this review we went through the process of setting up a replication job within our vSphere environment, and replicated one of our VMs (MSDC) – now we will take a look at the process of failing over to that replica. Replica failover within BDR is different than restoring a backup as we do not need to transfer any files or data – our backup is essentially a replica of the VM, sitting on a host in the native VMware format. Now we could if we wish just simply power on this VM from within our vCenter environment, but by initiating the process through Vembu we gain a bit more in terms of functionality and option.
To begin failing over of a replica we need to navigate to VM Replication->Manage Replica’s. The process can be kicked off by clicking on the ‘Restore’ button as shown below.
As shown below we have a few options as it pertains to managing our replicas; Failover, Finalize Failover and Finalize Failback. Let’s first take a look at the at the Failover option.
The next few options in the wizard after selecting Failover are similar to what we have seen in almost all of the BDR wizards, selecting a restore point and selecting our restore source. After we have done that and clicked the ‘Failover Now’ button the review section our failover process will initiate…
As we can see above our failover request has completed – which means we have successfully completed the failover to our replicated VM. This means operations are essentially switched from our production VM to our replicated VM, with any network mapping or re-ip rules being applied to it. This failover state however is not permanent and needs to be finalized in some sort of way. By default, BDR performs a snapshot on the replicated VM before it becomes active in order to allow us to revert back to various pre-failover states – which means simply failing over becomes a temporary step that needs to be further finalized. By clicking the same restore button on the Manage Replica’s screen, and this time selecting the ‘Finalize Failover’ option we are presented with the following options on the Finalize Type section of the wizard; Undo Failover, Permanent Failover, and Failback.
The ‘Undo Failover’ option will essentially undo any changes that we have made to the environment – meaning the production VM will once again become the active VM, and the replicated VM discards any changes that were made to it while it was in the temporary failover stage and reverts back to its original state. This option is normally used if the source VM gets restored or becomes successfully active again.
The Permanent Failover option is basically the opposite of the Undo Failover – it commits our changes to the replicated VM and in essence makes the replicated VM the new source VM, permanently. This option would be used if we are absolutely sure that our source VM is no longer recoverable and want to permanently run from our replicated VM.
Finally the Failback option gives us the ability to failback to our production site. This process will recover our replicated VM, along with any changed data while it was in a failover state, back to our production site, either on the original host or another host we prefer. Again, just selecting Failback doesn’t commit the failback, it leaves us in another temporary state that needs to be finalized. The options for finalizing a failback are…
- Permanent Failback – If we have failed back to production and we are happy with how things are working, this option commits our actions – our newly created production VM becomes our production VM and is automatically excluded from any current replication jobs
- Undo Failback – just as with failover we have the option to undo our failback – if something happens during the failback or we find that the failed back VM is not performing as expected this option will revert our production workloads back to the replicated VM.
vSphere replication within BDR has many options available and I like how each step can essentially be reverted. If you have engaged in failing over production VMs then you are most likely already in a disaster state – having the ability to undo both your failover and failback processes is certainly a nice thing to have during these times if something goes awry.
Conclusion
Wow – I think this is probably one of the longest reviews I’ve ever tackled, but the fact of the matter is I’ve only covered the core technologies which are included in the Vembu BDR Suite. In addition to everything we have covered here Vembu provides backup and recovery for individual application objects such as SQL databases or Exchange emails, along with SaaS based protection for services like Office365 and Google Apps. Vembu also provides integration into their cloud services, or even Amazon if you so please. The point is, the Vembu BDR Suite is an all-encompassing product that can provide complete protection across your environment, be it on premises or off premises!
There is lots to like about Vembu BDR – First off I think of commonality – Although BDR requires multiple different applications to make up the suite, all of the those combinations provide a similar UI – same colors, same look and feel, and same types of functionality. Even within single applications I see commonality – With the exception of maybe one step, the screens you go through in order to complete a restore are pretty much the same, whether it be file-level, VM-level, disk-level, or even failing over a replica – all the processes have a similar feel to them.
Also, the BDR console, or the main UI is nice in the fact that it pulls in the information from all of the other applications – I can see the status of the backups and restores that I’ve made to my physical machines inside of the BDR interface, even though they were essentially setup from the ImageBackup application. In all honesty I would love to see Vembu somehow port the process of deploying the ImageBackup application and it’s associated backup configuration directly into the BDR server – as then you would get a true one stop shop for managing those backup jobs, whether they be physical or virtual. That said, at the very least we are able to report on all of our backup jobs from one UI – maybe we will see something like this in a future release.
Aside from commonality and overall management probably the most exciting piece of technology I found within the BDR suite is the HIVE file system and the associated Virtual Drive technology. Being able to display the backup files out in formats such as vmdk, vhdx and ISO is a pretty nifty feature – but doing so in a matter of seconds, no matter what the source of the backup was is very impressive indeed!
With all that said I would most certainly recommend Vembu BDR suite, especially to those companies looking for a common interface to protect their VM backups, physical backups and SaaS backups all with one application. From my experience the product has performed very well, completing backups and replications all within a decent time frame with some impressive performance results. All this said, you don’t have to simply take my word for it – you can download the product yourself, and by default, all downloads come with a 1 month free trial so you can begin testing it out on your own terms. Aside from the BDR Suite, Vembu offers a wide variety of products such as a monitoring solution to centralize the monitoring of all of your backups as well as some which are absolutely free such as Desktop Image Backup and the Vembu Universal Explorer for discovering application items within Microsoft apps. I mentioned before that I’ve not heard of Vembu before starting this review – and if you haven’t, you certainly should check them out.
