In this, the fourth article in our series investigating the benefits of Vembu BDR for Virtualized Environments, we examine Vembu’s backup 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.
Once again, you are sitting in your cube, monitoring your environment. OK, playing Gorf. All is calm in the world. It has been several weeks since the data center failure and five weeks since you saved Steve’s hide. The year end went well, the CEO is happy, your management is happy, and you are content. As a result of the issues with the data center failure, management has decided that it is time to move to a new data center. It seems that the air conditioning failed in data center one, and that caused the failure of the host machines. I suppose that is one of the downsides of having near 100% sunshine. It has been decided that all services will move to a second colocation. You are not ready to move to the cloud yet, but you are not worried, because it’s “Vembu to the rescue” again.
You have been using Vembu to protect your environments for over a year now, and you are very happy with it. However, now, you are going to push the limits. You are going to move data centers with Vembu. Management has stated that it wants to have the ability to move from its current vSphere-based hypervisor technology to Hyper-V, but also to retain the ability to return to vSphere if the user experience is not acceptable. You have been giving this some thought—in fact, so much that it has even been cutting into your Gorf time at work. Management has agreed that this move will be a vSphere-to-vSphere move, so you have no need to complicate matters this time with a hypervisor change.
To manage the migration, you decide to implement Vembu ImageBackup across the board. This entails adding an agent to your virtual machines and treating your guests as physical machines. Your team members are not on board with this, but you have sold it to your management.
The thing with Vembu ImageBackup is that it can aid in the migration of physical machines to either vSphere or Hyper-V. In addition to laying down an image file, the product also lays down a Hyper-V VHD file and a vSphere Flat VMDK. The problem with Vembu ImageBackup is that it is a long way short of a true migration product. It does not inject the new storage device driver, remove any shadow device drivers post-migration, or install the relevant virtualization tool enhancements. However, it does create a VMDK or VHD in the desired location on mass. No solution on the market can do all of that anyway.
You install the relevant agents in the virtual machines and start your modified backup processes. These are not being backed up to your normal Vembu backup repository; you have created a separate store using the VembuHIVE file system at your new data center. This is good for all of your Windows-based machines, but you still have to consider your Linux machines. Here, you utilize Vembu NetworkBackup to back up the personality of the Linux machine and create new Linux guests at your new data center to accept the backed-up data as a standard restore.
Over the next couple of weeks, you back up all your machines, both physical and virtual, to your new VembuHIVE file system. You are aware that VembuHIVE is effectively a RAID 0 for nodes, so you also continue with your regular backup regime.
It is now the weekend of the changeover, and although you are nervous, you are not worried. You have preseeded your new data center with your virtual machines and have preloaded the VMDK flat file.
Your team is ready to start the migration process. For the virtual machines, you simply power on the virtual machine that has been created from the VMDK flat file and change the IP addresses. This is managed by a PowerShell script that powers on the guests and automatically changes the IP address and default gateway. For your domain controllers, you simply deploy a couple of new virtual machines from your template and run dcpromo into your existing domain.
The process is a little more complicated with the physical machines. For those that are remaining physical, you restore the image file that was created during backup to the same model of hardware. However, for those machines that are being converted to a virtual machine, you boot the new virtual machine and inject the correct storage controller. This is a manual process that requires forcing the guest into repair mode. Once this has been done, the guest will successfully boot. You then remove shadow device drivers and hardware-specific programs and change the IP address and default gateway. Finally, you install VMware Tools and test.
It is now early Monday morning. Several crates of Jolt cola have been drunk, and you feel like several tons of pizza have been consumed, but you have migrated. The environment has passed all your test plans, and you just have time for a sneaky game of Gorf before heading home for a well-deserved rest.