Cloudy With A Chance of Tintri - Part II
This is the second half of our 2-part series on protecting Tintri VMs in the cloud. Part I showed you how to upload a Tintri VM to S3 (or Azure, or both) using Integra; in this post we show you how we pull the VM down from the cloud and leave it resting in a Tintri VMstore. If you haven't already, please do read Cloudy With A Chance of Tintri - Part I so you get a bit of background info. After the VM is brought back from the land of the forgotten, you can use other tools from Tintri to do yet more interesting things with your newly revived VM.
We'll start off with the premise that the original clone created in Part I is gone, deleted into the ether, with its only remnants stored in the cloud. The original VM remains, and we can assume that the data in its virtual disks has continued to change and evolve over time. Now, imagine the files stored in the cloud contain an important piece of information you wish to recover: this is where an Integra workflow like the one you will see below could rescue you from guaranteed frustration.
The same VMs that we used before remain:
The communication path changes only slightly from S3 down to Integra, as we are doing a download versus an upload.
There is nothing new in terms of the providers used in Part I. We continue to have 3: the PowerShell provider--named Tintri below--, allows us to communicate with the VMstore, the AWS provider which allows us to perform the download from S3, and the Azure provider which exists in case that is your cloud provider of choice.
As you may suspect, new actions have to be configured in order to perform a download instead of an upload. Those new actions have been tagged with the Restore keyword so that they are easier to identify. You can leverage tagging in your own environment to categorize and filter actions; because folders are so passé.
If you notice the results from the execution of the List S3 Backups, you will see that we found the VM that was uploaded some time in the past. It is that individual backup that will be used in the restore workflow coming up next. Integra allows you to execute individual actions in order to test them. This comes extremely handy for making sure an end-to-end workflow will behave as you expect.
We finally hit the crux of the matter. This workflow isn't that much different from the upload workflow, and there is a good reason for that. If you recall from Part I, the Tintri filesystem is an awesome abstraction over datastores, volumes or LUNs. Moreover, we don't really need to interact with the hypervisor to create clones or take snapshots. The workflow below does precisely that: we set the stage by creating a new clone and then replacing its contents with the files that came from the cloud. Once the files are downloaded the VM can be started from the hypervisor without any fanfare.
Once you execute the workflow, you can see it runs successfully. Chances are you won't execute restores in a scheduled fashion, so we will not bother creating a schedule for this simple example.
Once the VM is started successfully in vCenter, we can launch the console and verify that it is running without a problem.
Uploading/downloading a Tintri VM to/from the cloud is easily done with Integra. If it were databases running inside each VM, you could certainly leverage the application providers offered by Integra in order to achieve application crash consistency before sending the VM to the cloud. Regardless, this exercise proves extremely useful for leveraging one of Tintri's cool offerings: SyncVM.
By using SyncVM, you can take the disks from the recently downloaded VM and literally make them available to any other running VM. Tintri has a great video explaining how SyncVM works, so make sure to check it out.
Once you are done recovering your data, you are welcome to destroy the downloaded VM knowing that a copy still resides in the cloud, stored away until it is needed again.