I’ve done quite a few reviews over the past five years or so on this blog, and for the most part I always had somewhat of an idea who the company was that I’ve been writing about – however this time things are a bit different! I’ve never heard of Vembu before they gave me a shot to test out their flagship software, Vembu BDR Suite, which is why I was pleasantly surprised when I started doing a bit of research on the company! Vembu was founded a way back in 2002, and even though their first products to market were created around SQL migrations their main focus then was backup, and has been now for over a decade!. Being in the backup business for 10 years you would think I would’ve heard their name, however Vembu was a more “behind the scenes” product – firstly aimed at Managed Service Providers who at the time would white-label their software for resale – something I, or anyone within the community wouldn’t have noticed! It’s that 10+ years of experience that shines through in their new release of the Vembu BDR Suite. Now what surprised me the most was the shear number of products and supported platforms that Vembu BDR supports – Vembu can backup vSphere, Hyper-V, Physical Servers, Desktops, Exchange Items, SharePoint Items, SQL Items, Office365, Google Apps, etc. – and they can back that up on-site, off-site, or even to the cloud, be it a Vembu cloud or Amazon – not to mention that most of this is done within a single UI – Impressive! With all of this going on I was surprised about how little I’ve heard of them. Either way I’ve seen lots around the community as of late from Vembu and was excited to get them in the lab and try out some of their tech!
Now, due to the sheer amount of supported platforms and options I’ve decided to break this review up into a couple of parts. This part will focus solely on setting up our backups, be them physical, VMware and Hyper-V, along with explaining a little about Vembu’s Image Verification that ensures we have restoreable backups when the time comes that we need to use them. The next part will explore what really matters when it comes to backup – and that’s restoring! Vembu provides a lot of flexibility when it comes to restore, object-level, file-level, VM level, etc. – and really has a unique take on how they expose their backup files for restorations such as their HIVE file system and Virtual Drive mounts.
So with that all said let’s get on to the show….
Getting Vembu in the lab
We will quickly go over deployment and configuration as getting Vembu up and running is very, very simple. Vembu provides a number of options to get started with the BDR Suite – think Virtual Appliance for both Hyper-V and VMware, Windows, Linux, etc. Again, not only providing support for backing up multiple platform environments, but providing choice when it comes to what environment you want to run Vembu in. – I’ve chose to go the Windows route but either installation method provides you with the same, easy to follow wizard-driven install. Essentially, the Windows install simply prompts for a password for the MySQL server, a location for the mongoDB, the system/user account to run the Vembu BDR service under, a username and password for BDR itself, and a location to use for the default repository where BDR will store it’s backups. Not a lot of information to have to provide for the amount of configuration the installer actually performs.
As far as configuration goes there isn’t a lot we need to do after installing Vembu BDR. We could navigate to the Management menu and set some things up such as the time zone and SMTP settings for reports, however you can also just get into the nitty gritty – which is what I chose to do…
Backup Time
As mentioned above Vembu BDR supports both VMware and Hyper-V, along with physical servers, workstations, etc. As well, we can process restorations on object level items such as MS Exchange emails and SQL databases, along with backing up SaaS based applications like Office365 and Google Apps. It would be impossible to take a look at every one of these on one review, so for us we will focus on probably the three most popular platforms; VMware, Hyper-V, and Physical.
Backing up VMware vSphere VMs
In order to start backing up our VMware environment we will need to provide Vembu with some information in regards to either our standalone ESXi hosts or our vCenter Server. By selecting ‘Add VMware vSphere Server’ (after going to Backup->VMware vSphere) we are able to start processing virtual machines which live on either our vCenter Server or a standalone ESXi host. The process of adding our vSphere environment is quite simple and accomplished by simply entering in the hostname/ip of our vCenter Server/ESXi host and passing along some credentials – a pretty common process in any application which requires data from vCenter.
Once our server has been added we can immediately begin to back up our VMs. Creating a job within BDR is done through the Backup menu (shown above) and then selecting the ‘Backup Now’ option next to the vCenter/ESXi server you wish to process – doing so will begin our 5 step process in creating our first vSphere backup job within Vembu BDR.
The first step we need to complete is telling BDR exactly what we wish to backup. As you can see above, I simply selected the checkbox next to my desired VM and clicked ‘Next’. The release of BDR 3.6 added the support of backing up complete clusters as well and if you wish to exclude and VMs (if selecting to backup a complete host/cluster) or VM disks this can be done by simply click the ‘VMs/Disk Exclusion’ button. A pretty easy and self explanatory process….
As far as scheduling goes we have the option to select to run our backups hourly, daily, or weekly, and set our desired days/hours in which we would like to execute the job. With the smallest option of running our backup jobs every 15 minutes you can be sure to prevent as much data loss as you can. Here I’ve left the defaults as is, to run hourly on every day.
As we move into the retention configuration we start to see some more advanced functionality that BDR provides us with. Before explaining all of our options its best to describe a little bit about how BDR stores its backups on disk. During the first run of a backup job, BDR will take a full backup of our VM from the production storage – each subsequent run will leverage vSphere’s Changed Block Tracking and copy only the differences, or those blocks which have changed within the VM since the last backup and then store them in incremental files. When the retention period is hit, BDR copies the oldest incremental restore point and injects it into the full backup file, releasing that space to be used as free capacity. With all that said let’s take a look at the retention options available to us.
The default retention setting on this step, Basic Retention, essentially means we will keep 1 full backup and X amount of incremental backups on disk – so if we select 3 has our retention policy, we will be left with one full and two incremental backups, giving us a total of three points in time in which we can restore to. By selecting Advanced Retention we can apply a more robust Grandfather-Father-Son (GFS) backup solution to our VMs. GFS retentions within BDR allow us to merge our backups into additional full backups, ensuring we are covered when it comes to meeting compliance on restore points. Think of situations such as having hourly incremental backups take place, while merging daily into a daily full, in-turn merging our daily fulls into weekly fulls, and so on and so forth for monthly and even yearly. Essentially, GFS allows us to have the benefits of having small RPOs, while maintaining the assurance and compliance of having the number of daily/weekly/monthly restore points our business requires.
Aside from retention, we also see a couple of other settings on this step.
- Application-Aware Options – BDR can utilize VMware tools to invoke the VSS writers within a VM in order to ensure that the backups are application consistent – it’s here where we setup options such as how to proceed if application processing fails, as well as specify which credentials to use and how to handle transaction logs (truncate or leave alone)
- Additional Full Backups – BDR by nature creates one full backup along with many incremental backups following it. Having a long chain of incremental backups may be ok in some environments, but enterprise organizations may want to have additional full backups performed periodically to sit in between the incremental backups. Here we can setup full backups to be performed in addition to the incremental on an hourly, daily, or weekly schedule. We can also limit the number of full backups we want to keep on disk as well in order to preserve space and capacity on our repositories.
The Review Configuration step is just that – a step that allows us to specify a name for our backup job, as well as review the selected configuration we have made in the past three steps. From here, we can simply click ‘Run the backup’ to execute our newly created job.
After committing our backup job we are now brought directly to the ‘Progress Details’ section. No matter what schedule we provided, Vembu will always immediately begin the first full backup of the VMs specified. Here we can see the associated tasks and events, as well as transfers and progress rates of our newly created job as it runs. This progress screen isn’t cluttered with a bunch of statistics that we don’t necessarily need to see – It’s a clean and simple UI that simply shows you a percentage complete, along with the total backup size, and currently running transfer rate – everything we would want to know about a job in progress.
Once our first job has been setup we can view details about it by navigating to Backup->List Jobs. Here we can do many things such as suspend (disable), edit, or delete our jobs, as well as view their current running status. Clicking the Reports icon will allow us to drill down into more detail about the last run of the job, showing us the size, status, and time taken to perform the job.
Essentially this is it for creating and running a backup job for vSphere within Vembu BDR, however there is one more vSphere protection strategy for VMware that Vembu provides – Replication.
Replicating VMware vSphere VMs
Selecting VM Replication from the top menu, then clicking the Replicate Now icon next to your desired vCenter server will introduce us to the Replication wizard. The Chose VMs and Configure Scheduling options are the same as that of the backup process we went through earlier, allowing us to select our desired VM and setup an hourly/daily/weekly schedule to perform replication. That said, things start to change a bit as we move into third step of the setup.
The Target Replication Host section is where we specify where we would like to host our replicated virtual machine. Here we can select an existing vCenter/ESXi host or ‘Add DR VMware Server’ if we would like to add a new one. Also specified is the datacenter and datastore where the replicated VM will reside. Since this will be an exact copy of our VM we have the option to add a suffix to our VM as well in order to distinguish it from that of our production VM, as well as set our desired retention policy on the replicated VM.
Network Mapping allows us to map between our source and target networks. Normally, when replicating to an offsite location we may have different network names within our vSphere environments that we attach our VMs to in order to gain network connectivity. Network mapping allows us to configure a table of sorts that will map our source production networks to networks within our DR site, eliminating a mundane and time consuming step when it comes to actually failing over our replicas.
Re-IP Mapping allows us to specify some rules around what our replica IP address will be, supporting the situation where we may have different addressing schemes between the production and replication site. Adding a Re-IP rule is as simple as clicking ‘Add Rule’ and specifying the source and target IP schemes, along with DNS and Gateway information. Then, during failover, BDR will automatically apply these Re-IP rules to the replicas in order to ensure we have the proper connectivity during a disaster.
Again, just as with our backup job, once configured we will be brought to the same simple, clean progress screen outlining everything we need to know about the running process of our replication job.
Hyper-V Backup
Adding a Hyper-V server into Vembu is fairly straightforward and similar to that of adding a VMware host. In terms of Hyper-V we can had either a standalone host, or an SMB host. Either way, once added Vembu will push what they call ‘Integration Services’ to the hosts in order to handle the processing of VMs. In order to do so, BDR will need some sort of administrative privileges, meaning you will have to ensure that the service in which Vembu runs, runs under an account with sufficient privileges to go out and install software on your Hyper-V hosts. Once providing the proper credentials and hostname of your Hyper-V host, the integration services are deployed and the host will be available for you to backup inside of Vembu. These integration services contain a number of technologies that are used to create the full backup as well as a CBT driver in order to track modified blocks for incremental backup. If our disks are stored on an SMB host, we will need to deploy the Vembu Integration services here as well.
Similar to vSphere we can begin creating jobs directly after adding our Hyper-V host by clicking the ‘Backup Now’ button.
Just as we did in our vSphere backup we simply check the VMs we wish to include in this job, and use the ‘VMs/Disk Exclusion’ button to backup only certain VMs or disks within the VMs.
As we can see above, the backup options are identical to that as were in the VMware backups. We have the option to set our schedules and apply different retention policies such as GFS, restore points, etc., as well as configure options related to Application Aware and additional full backups.
Again, after naming and creating our Hyper-V job we get a nice backup progress screen that auto refreshes throughout the backup process. As we can see here we are getting some very nice performance with our Hyper-V backup job, processing over 500 MB/s!
Physical Machine Backup
Aside from just backing up Virtual Machines, Vembu BDR provides data protection for both physical servers and desktops as well. As shown below we have a couple of options when we browse to ‘Backup->Physical Machine’; Physical Images and Files and Applications
What each option does is actually quite different. The ‘Physical Image’ option allows us to backup and process a complete physical machine and store it as an image file, while the ‘Files and Applications’ allows us to backup just those files or application item such as Exchange mailboxes, SQL databases, etc. that we prefer. No matter which option is selected we are taken to a page within Vembu.com to download the respective client which will need to be installed on the physical machine we wish to protect. Let’s go ahead and take a look at the physical image component of Vembu BDR.
The client/agent installation is quite simple; just requiring you to specify a globally unique ID that will allow you to identify the machine within Vembu BDR. After that it takes care of pulling down all of the perquisites and required packages needed to run. Once installed we can go ahead and run the Image Backup web console, which will takes us to a familiar UI, similar to that of Vembu BDR. Keep in mind these clients are installed on the physical server we wish to backup, not the Vembu BDR server.
After logging in and setting a time zone we simply need to point our client to our desired Vembu BDR server. Once connected we will be redirected directly into our backup job setup as shown below….
As we can see, the layout and UI of the wizard is exactly the same as that of the Vembu BDR server where we were setting up backup jobs for our hypervisors and VMs. It’s nice to have this uniformity between the different components that make up the BDR suite. Also as we can see above, before we are able to create our backup we will need to install the Vembu ImageBackup Disk image driver. I asked Vembu why they opted to go the route of having a second install for the image driver rather than simply bundling it in. Their answer has to do with reboot polices – rather than set a reboot policy and automatically reboot our production workloads, Vembu gives us the option to simply install first and reboot when it is appropriate for us. Either way, after rebooting and re-authenticating to the client, the same wizard appears as below…
The first step, just as in a Virtual Machine backup is to chose our source – what we want to backup. In terms of a hypervisor this includes VMs, however when dealing with physical machine image backups, this includes physical disks and partitions within the server itself. As we can see above I’ve chosen to backup all of my partitions on my physical machine.
On the next step we once again see the familiar scheduling settings as we did within Virtual Machine backups. Set our desired schedule, as well as our target backup server and click ‘Next’.
The last configurable step of the wizard allows us to specify the retention on the backups we take. The same options that were available to us within Virtual Machine backups are also applicable to physical server backups as well – meaning we can setup GFS backups, Application Aware settings, as well as schedule additional full backups to be kept on disk aside from the set retention policies.
Once completed our initial full backup will start, and we will be left with a nice progress screen just as we have seen within the Virtual Machine backup. The backup of a physical machine is pretty straightforward and easy but I would still like to see some way of deploying these clients out centrally from our BDR server, as well as setting up the initial backup jobs for them – maybe in a future release! It should be noted though that although we do not centrally create these physical backups through BDR, we can indeed report on them – As we can see below, the screenshot to the left is the reporting from ImageBackup locally on the physical server, with the corresponding screenshot on the right reporting on our physical backup amongst all other VM backup operations (Never mind the failures as I had some VMs powered down in my lab during certain times). Also we can see that the performance and deduplication provided by ImageBackup is very good, taking only a handful of minutes to backup roughly 22 GB, and compressing down to 16GB.
Aside from simply setting up the backup job, the Image Backup UI contains some other useful information and configuration options as well. Under configuration we can see a number of options.
- User Management – allows us to create users and grant access to the Vembu ImageBackup UI
- Backup Schedule Window – allows administrators to define certain times of certain days where backups should NOT run – thus guaranteeing that our backups will not impact our business during certain production hours.
- Bandwidth Throttling – This can be used as another means to limit the impact of backups on our production networks. Bandwidth throttling allows us to limit the network bandwidth to a certain amount of MB that is consumed by backup jobs. We can do this by always throttling or by throttling only between certain times of the day, with the option to include or exclude weekends when the production network may not be in use.
Image Verification
So now that we have setup multiple jobs, backing up both VMware and Hyper-V, as well as a physical machine the next logical step is to perform some restores! That said, before we go into the restore process I wanted to talk a bit about what Vembu calls Image Verification. What Image Verification does is ensure that before we go to perform a restore on a given backup our data will indeed be restorable, correct, and in-tact. Vembu’s Image Verification processes in a tiered approach, attempting to detect a lot of factors that may cause failure during a restore…
- Mount Check – A mount check basically takes our backed up VM and performs a mount to the BDR server. This ensures that if we ever need to perform instant mount during a DR scenario that we will be successful. We will talk more about this mount process in part 2 of this review.
- Boot Check – The last step of the verification where our backup is booted up within a Virtual Machine. Once booted, Vembu takes a screenshot of the booted VM and stores it within the configuration – allowing us to get a visual “piece of mind” that our backups are restorable.
- Integrity Check – This is an optional step of the verification as it performs a chkdsk on our VMs which can take quite a bit of time.
Vembu’s deployment of Image Verification is not something that we need to schedule as it is in other backup products – instead, Vembu, by default automatically runs the verification process once a day. Certainly this is a nice feature to have as nobody wants to go and restore a VM and find out that the backups themselves are corrupt!
Stay tuned for Part 2
So we have went over the backup of vSphere, Hyper-V and physical environments, as well as touched on how we perform items such as vSphere replication and Image Verification. What I really liked about going through the process of each item was the uniformity – no matter what we were doing the wizards and configuration of jobs was very very similar – no need to learn new terminology and processes when switching source environments. In our next post we will take a look at what really matter, recovery. Going through all of the different restore types as well as replica failover. For now, if you wanted to get started with your own Vembu deployment you can do so by downloading a 1 month free trial of the entire BDR suite! Thanks for reading and stay tuned for part 2.
