In this, the seventh article in our series investigating the benefits of Vembu BDR for virtualized environments, we carry on examining Vembu’s migration 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.
For once, life is being kind to you, and again you are sitting in your cube, monitoring your environment. OK, you know the score by now—playing Gorf. Steve’s score has improved, but because your environment is all calm and joy, yours is still better. All is calm in the world, and you are planning the next phases of the company cloud migration.
Cast your mind back to our previous conversation, when we managed to move into Azure and decommission our expensive colo site. Well, it has been decided by the powers that be that this cloud is a great idea and it is time to create an active cloud presence. Now, it makes sense to have this located in Azure, as your virtualization layer of choice is currently Hyper-V, so migration is going to be easy. Famous last words, of course, but remember, you have your trusty Vembu to aid you.
Currently, you have a live on-premises Hyper-V cluster and an offsite Azure hot standby. You are planning to add a second Azure site that is active to enable the later decommissioning of the current active on-premises data center.
There are a number of things you could do here. However, once again, you have chosen to simply utilize Vembu’s OnlineBackup feature to create an online repository. This will be used to populate your new zone and later as a backup repository for your company’s backups. Further, you know that you can relax, as you already know that even if there is an outage to your hot-standby site, the backup processes will restart from the last point of failure automatically on resumption of service. The main purpose of this stage is to effectively pre-seed your new cloud location. As your current Azure site is only acting as a hot standby, this can all be done without significant impact or disruption.
You quickly deploy a new Vembu backup server in your Azure site to back up the machines there. Once again, you lament that it would have been nice if you could have just added a replication target to your already existing server and configured it replicate to the instance you have set up in Azure using Vembu OffsiteDR, but that ability is not yet here (you can’t have everything). Speed is not of the essence right now, and you have time to plan. You can just leave the replication to trickle to completion. Once it is complete, it is time to deploy your new site on its new home location of Azure.
As usual, we are not going into the vagaries of cloud networking over on-site virtualization or physical networking; suffice it to say that it is configured correctly.
It is again time to summon the power of Vembu, in this case by restoring your replicated VHDs and VHDXs directly into Azure from your OffsiteDR instance. Admittedly, creating the virtual machines to utilize the restored virtual disks is a manual process. OK, it’s a PowerShell script you wrote that creates the guest, starts the guest, and changes any networking details as necessary.
Once everything is complete, you decommission the Vembu BDR server in your on-premises site and repoint your new Azure Vembu BDR server to utilize the instance in your hot-standby Azure as its OffsiteDR target.
Once verification that everything is back in sync has been gathered, you can start the process to decommission the main data center site. However, you manage to persuade your management to allow a test and development lab in the old environment. Also, as a belt and braces move, you secretly set up a new Vembu BDR server and set it up to accept replication of your hot-standby Azure instance. Who knows? It may be needed.
Things are definitely a lot more stable now. And your Gorf score is getting even better.