In the last weeks I migrated my personal lab to a new location, with new servers and all. I took the opportunity to rebuild some of the test machines I had in my previous one, but one cumbersome and boring task is always to recreate the virtual machines used to do demos, where different applications are deployed and configured to make the demo more “real”; things like Oracle databases, websites, file servers and so on. As both the platforms at source and destination use VMware vCloud Director, I took this opportunity to learn more about migrating vApps from one vCloud to the other, using Veeam Backup & Replication.
Take a backup and transport the backup to destination
Backing up a vCloud Director environment is well documented, and it’s what every service provider using Veeam for vCloud Director is doing already. There’s really nothing to be added here. What someone may not know is that vCloud Director can be further protected by using Backup copy jobs, so that providers can create a secondary location for the backups of their hosted vApps. Again, creating this type of jobs is fairly easy, just like any other backup copy job:
The rest of the configuration is exactly like any other Backup copy job, and in my case, I decided to use my Veeam Cloud Connect platform as a target. In my new lab, in fact, both the IaaS platform and the Cloud Connect platform share the same physical infrastructure. No better way to ship my vCloud backups to the other side of Europe (from northern Italy to Amsterdam) than Cloud Connect!
Import the backups at destination
I don’t actually need to have a full retention stored into Cloud Connect, I only need one restore point of each vApp/VM saved at my destination:
As you can see in the screenshot, there are two different Backup Copy jobs where the platform is listed as vCloud, one backup for each tenant I have in VCD. Once I had one restore point for each vApp, it was time to move to the destination site and start the import.
At the provider side, I have two different Veeam Backup & Replication installations: the first one is the Veeam Cloud Connect server, responsible for managing the offsite backups coming from tenants (and the replicas, but this is not the topic of today). Here I don’t see the backups, as per default VCC doesn’t show to the providers the tenants backups. Because in my fictitious service provider I want to offer also IaaS services, I deployed another Veeam server, this one connected to the local vCloud Director installation:
The next step is to import the backups coming from Veeam Cloud Connect into this second Veeam installation. After physically copying the backup files into one of the repositories mapped into the IaaS platform, I can rescan the repository itself and see the new backups. The backup sets show up as imported in the console (as they are not linked to any local backup or backup copy job):
Restore the vApps in a new location
Now that the backups are available in the local console, I can start a restore. As I said before, I don’t need to link the backup set to any job, I can simply select one of the vApps, and choose to restore it:
The restore wizard is started. I fisrt choose which objects I want to restore from the vApp, and which of the three restore points I have I want to use. Then, in the restore mode, I choose to restore the vApp “in a new location or with different settings”. You can see immediately that more steps appear in the left menu of the wizard. That’s because I will have to choose more options in terms of positioning the vApp inside the new environment:
Here, I can:
– change the vApp name, and map it to a selected Organization vDC. As the original one is missing, I can use this step to restore the vApp to a different vDC; there are cases where I can use this feature to move a vApp also inside the same environment, but to a different vDC:
– change the network mapping. Since the original machine was connected to a Routed network, Veeam searches for one in the destination vDC and suggests to use that; we can always go into the details of the network mapping and select a different one, if we want so. In my case, I’m happy with the selection that the software did for me:
You can verify this behaviour by trying to restore another vApp with different network settings, like trying to use the Isolated type. In this second case, Veeam sends us a warning:
Finally, we select the desired datastore, or better said, the desired storage policy we want to apply to the vApp, and the datastore available for the selected policy:
Then, we complete the wizard and we start the restore process. Note: 99% of the times, in my tests any error during the restore process has been caused by a wrong network configuration, like the one I showed before. Be sure to configure networking correctly before starting the restore process.
And obviously, you see the restored vApp in the vCloud Director console:
