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.
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.
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.