In this, the second article in our series investigating the benefits of Vembu BDR for Virtualized Environments, we examine Vembu’s restoration capabilities. We all know that backing up your data is only one part of the equation. The ability to recover is the other, and arguably more important, side. This is where Vembu BDR really shines.
Imagine you are sitting in your cube, monitoring your environment. It is your company’s financial year end. Finance is diligently working at finalizing those accounts, sales is frantically calling to pull in those last orders, and everything is good in the world. You are staring at your favorite monitoring application of choice, and all is green in the world as well. You are content.
Suddenly, something goes red. On your overview, you drill down, and your next layer is all red, too. You start to get worried. Phones begin ringing all over the office, and panic sets in. Your worst nightmare has happened, and your data center has failed—and this is before you have your vaunted hot standby environment finished.
But you are calm. Why? Well, you have Vembu Quick VM Recovery, Vembu OnlineBackup, and Vembu OffsiteDR to cover you. Your data center may be a smoking hole in the ground, but that doesn’t matter to you, because your backups have been replicated to Vembu Cloud. Even though your hot standby environment is not up and running, you do have physical and logical access to the remote site. It is true, though, that this does not make you special; your friend who works at another company has Veeam Backup and Replication, so she, too, has Instant Recovery and a fifteen-minute RTO (recovery time objective) of her virtual machines.
There are not many recovery products that can offer a fifteen-minute RTO, but you feel empowered, as this is the case across the board with Vembu’s products. What is even more impressive is that Vembu BDR also offers an RPO (recovery point objective) of fifteen minutes through the use of continuous data protection. This is not just for protected virtual machines, but also for Windows-based physical machines. This will keep the finance team happy.
When it is time to initiate your BCDR (business continuity/disaster recovery) process, again, you are not worried. You have your host machines powered up at your second data center. You have replicated all your backups to the remote site using Vembu Power Replication, including backups of your physical machines that are now stored in an image format. All you have to do is initiate Vembu Quick VM Recovery. You can be up and running again in the time it takes your sales team to make a cup of coffee.
The instant recovery of a virtual machine is as simple as sharing the Vembu Virtual Drive, which is situated on your Vembu Backup Server; mounting it via NFS to your VMware hosts or via an SMB share to your Hyper-V hosts; and then creating a virtual machine using the VMDK or VHD that was created on the machine during the normal backup process. However, because of the method Vembu uses to create image-based backups of physical machines, this process can instantly recover your physical backups directly to a VM. All your physical machine backups are stored as an image, but this image has also been converted into a VHD file and a VMDK Flat file. True there is a little bit of manual recovery in this process, but that is simply changing the Storage device driver. and removing any shadow device entries, simple SysAdmin work that needs to be done when you P2V any machine. It would be nice if it was automated, but you are where you are. So, while the sales team are making that coffee, you create the VM’s that are going to host the newly “converted” physical machines and work your P2V post migration magic.
Fifteen minutes later, there you go. All is green again, and the phones have stopped ringing. Quarter saved. There has even been a minor miracle, the sales team even made you a coffee. Now its time to go back to your retro game of Gorf and smell the arabica beans of success.
Share this Article:
Latest posts by Tom Howarth (see all)
- That Was the Year That Was: 2016 - January 16, 2017
- Docker Has Been in an Acquisitive Mood Again, This Time Pulling in Infinit - January 9, 2017
- Acquisitive LANDESK Bought Out - January 5, 2017