In this, the eighth 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.
Again life is being kind to you, and once again you are sitting in your cube, monitoring your environment. OK, you know the score by now — playing Gorf! Well your wrong you’ve stated re-playing Donkey Kong after watching the movie Pixels at Steve’s Daughters birthday party. This is more fun as both you and Steve can now have a real points tally competition. 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 where we managed to moved completely into Azure and started the decommission our last on-premises datacenter. Well there has been a change at the top and they and the powers that be have decided that although Cloud is a great idea and enabler, the release of Windows 2016 and AzureStack has brought some interesting options to the table, and they now want to take a more hybrid position on their Cloud utilization and have therefore decided to return the corporate crown jewels; the Databases back in house. You die a little inside as, this is what you actually advised in the first place, but hey never mind.
This is actually fairly simple from a technology perspective as I have my trusty Vembu to aid you.
Currently we have two live Azure instances one, running our active environment and a second Azure instance running as a hot standby, we are planning to migrate our live general use databases as well as our ERP and CRM databases back to our in-house datacenter. It is decided that we will keep the two Azure sites running in the same format; one running the active application stack and VDI environments and keep the other site as an offisite standby site that include all layers.
Once again there are a number of things we can do here. However, as we already have an instance of Vembu BDR replicating all our VHD,s and VHDX’s to our local datacenter, we can simply to utilize Vembu’s OnlineBackup feature to restore our machines and re-populate our On-site datacenter. Further, as you know we can relax, as even if there was an outage during any time, the backup processes will have restarted from the last point of failure automatically on resumption of service. This time we really have stolen a march as we have already pre-seeded our local datacenter. Sometimes plans come together
You do not bother to change any of the replication rules on your stealth Vembu BDR server, because it is very easy to utilize that repository to quickly instantiate a new test and dev environment. But you do deploy a new Vembu Backup Server in your datacenter, this will be used to back up the Database machines there and replicate to your main Vembu BDR service in your hot-standby Azure instance.
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 your local Hyper-V environment from your locally deployed OffsiteDR instance. Admittedly, creating the virtual machines to utilize the restored virtual disks is a manual process. OK, it’s reusing the PowerShell script you wrote to aid you in the original migration tasks that creates the guest, starts the guest, and changes any networking details as necessary.
Once everything is completed, you consider decommissioning the stealth Vembu BDR server in your Azure Hot Standby site, and its replication partner but decide to keep it running due to the benefits it brings in keeping your test and dev environment current. You finalize the configuration of your newly create Vembu BDR server to utilize the original Vembu BDR instance in your Hot-Standby Azure its OfflineDR target, you can do this as Vembu OfflineDR can take multiple sources to a single target.
Once verification that everything is back in sync has been gathered, you can pat yourself on the back for managing to persuade your management to allow a Test and Development lab in the old environment thereby negating the full decommission. You also decide to come clean regarding the stealth Vembu instance as budgets are due and as a belt and braces move it makes perfect sense to your management as who knows it may be needed.
Things are definitely a lot more stable now. And your Donkey Kong score is getting even better, if only you could beat Steves.
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