Tintri Cloud Connector – Long Term Backup To The Public Cloud

Everyone wants to have some level of public cloud backup strategy.  It doesn’t matter if it’s for personal use or business, we are all either doing it, or want to do it.  The goal is to leverage multiple clouds to keep data protected for different reasons.  In most cases Public Cloud Object storage is cheaper than our on premises storage so it makes sense.  We’ve seen this shift for years and it’s certainly become more mainstream.  I know in my personal life I use Google Drive for business a lot to store things offsite not only for long-term retention but for easy restore should I need to replace a device.  So this is no different for VIrtual Machines and Tintri has announced the Tintri Cloud Connector integrated into their arrays for the same purpose.  Last week Tintri annouced the new Tintri Cloud Connector, so let’s take a peek at how it works.

Tintri Cloud Connector Use Case

The main use case for the new Tintri Cloud Connector is offsite long-term archival of Tintri Snapshots.  It provides a native mechanism to offload snapshots of desired intervals for whatever retention period you choose.  The general idea is always to have a staged approach to your backups such as this:

  • Local Device – 1 Day Retention
  • Remote Device – 1 Month Retention
  • Public Cloud – 1 Year Retention

The varying retention is key but you can also set the snapshot interval schedules for each of these retention periods.  This allows you to free up some space on your local and remote VMstores and house long-term backups offsite in the public cloud.  Once you have the data stored in the cloud you can then restore it to the original Tintri array or another array managed by the same TGC.  It is possible to restore to net new arrays and a new TGC, and I may cover that in another post.  Restoring to the original VMstore or even another VMstore in the same TGC works very easily which you can see below.  Let’s remember this is intended to be an archival solution not necessarily a Disaster Recovery solution, primarily because your company RTO may dictate that the time to download via the internet will be too long for the number of machines and/or the amount of data.  While it can be done a better approach for a site disaster would be the below illustrated remote synchronization between VMstores in two sites.

Play the video below for an illustration.

How Tintri Cloud Connector Works

What makes this very efficient is that all de-duplication and compression is done on the local array prior to uploading to the public cloud.  This creates much less data to move from on premises to the cloud.  it will also result in less cloud storage cost over time.  Tintri has also worked in some level of GET/PUT optimizations in as well behind the scenes.

Configuring the destination

Adding this into your regiment is very simple and it can be configured either from the UI or via API’s leveraging self-service human readable options.  You will need to have Tintri Global Center running and VMstores managed by TGC to configure it.  When you add a new replication destination you only need to provide some standard information.

Key information you need to have and also store in a secure place is:

  • The Repository ID (Bucket name)
  • Encryption Passphrase (Must record and retain)
  • Access Key and Secret Key (IAM keys for API access to the location)

Should you need to connect a new TGC to the public cloud you will need some of this information later but that’s a blog post for a later date.  Just know you want to retain especially the bucket name and the encryption passphrase in a safe place.  You will even get a warning telling you to save it in a safe place.  Once configured a new bucket will be created for you and you will have this later to configure as a destination.

Configuring and Managing Replication

This is where it is very easy to get started.  In the example below you can see I have configured one hourly snapshot schedule.  From that single schedule I can then set the local and remote retention.  In this case 24 hours for local and 720 hours (one month) for the remote replications.  Finally I have set the cloud retention to 365 days.  It’s important to make the distinction to the snapshot frequency vs the retention.  We can take daily, weekly, and custom snapshots and then use those as part of any number of retention options.  For illustration purposes I am using hourly in the lab just so the time is compressed for testing.

If you configure additional schedule types you can in turn use those for the cloud replication and retention.  Once replication has started you can see the list of snapshots available and also what the destination is for it.

 

In the example above we can see that the hourly snapshot has been saved on the local VMstore, the remote VMstore as well as the cloud location.  If we wanted to download the cloud version we simply highlight it and click Download.

Finally, we can select any one of the VMstores that are available in the current TGC to download the snapshot too.  It will in fact download the FULL copy of the virtual machine for you so you can create a complete clone after the fact and start up the image.  You may find that it is not possible to restore to the original VMstore location due to space or performance restrictions, however the cool thing is you can download to any other VMstore available in the TGC.  The point being, by the time you want to restore something 6 or 12 months later, the original VMstore could simply be at capacity or a performance level that you decide you want to download it to a different array in the same TGC instance.  This is actually a great option in my opinion giving you added flexibility on your restore location options.

Tintri Cloud Connector Conclusions

If you are looking for additional long term public cloud based backup of your virtual machines running on Tintri VMstores, this could be the answer for you.  This works very well and is intended for exactly that, cloud based backup with long term retention.  If you want to use this as a Cloud DR solution, while you can do so, in its first release it will take some more work to truly restore from a complete site disaster, not to mention dealing with the potentially long RTO of restoring large amounts of data from the cloud.  I know when I have to restore all my Google Drive data to a new laptop, it’s a long process, but it works for me.  The bottom line is when Ttinri Cloud Connector is available on your arrays it does work, and it does have some nice advantages for Tintri customers to backup to a public cloud.

About Chris Colotti

Chris is currently a Field CTO for Tintri. In his role he spends the majority of his time talking to customers and partners alike helping develop use case architectures for the Tintri platform and software. He also acts as an active interface between the field and engineering/product management. Chris is active on the VMUG and event speaking circuit and is available for many events if you want to reach out and ask. Previously to this he spent close to a decade working for VMware as a Principal Architect. Previous to his nine plus years at VMware, Chris was a System Administrator that evolved his career into a data center architect. Chris spends a lot of time mentoring co-workers and friends on the benefits of personal growth and professional development. Chris is also amongst the first VMware Certified Design Experts (VCDX#37), and author of multiple white papers. In his spare time he helps his wife Julie run her promotional products as the accountant, book keeper, and IT Support. Chris also believes in both a healthy body and healthy mind, and has become heavily involved with fitness as a Diamond Team Beachbody Coach using P90X and other Beachbody Programs. Although Technology is his day job, Chris is passionate about fitness after losing 60 pounds himself in the last few years. Now he spreads both the word of technology and fitness along with the Team Beachbody Business through his blogs.

Leave a Reply

Scroll To Top
%d bloggers like this: