Tintri provides flexible recovery and copy data management capabilities that are an essential part of the toolkit for anyone staging DevOps environments, managing databases, or pushing out software upgrades.
The first blog in this series explained Tintri Snapshots and some of the things you can do with them, including how you can automate protection of a VM, a set of VMs, or an entire Tintri all-flash storage system. Tintri SyncVM builds on the foundation created by Tintri Snapshots to enable more advanced functionality.
SyncVM gives you flexible options for recovery and copy data management that are useful in a wide variety of scenarios. SyncVM also provides great flexibility in application and database environments. For instance, you might want to use SyncVM in your DevOps or dev/test environment. Because SyncVM works at VM-granularity, it allows you to do things that are almost impossible with LUNs found in traditional storage.
In this blog, I’ll explain several use cases for SyncVM:
The first type of recovery that SyncVM allows you to do is recover an entire VM. You simply right click on the VM you want to recover in the Tintri UI and select SynchronizeàRestore VM/files… and then choose a snapshot to restore.
This restores everything from the snapshot, including all vDisks and the configuration file, in place of the original VM.
You can also do a more selective recovery of one or more vDisks. This allows you to get a little finer grained, depending on the issue you’re trying to address, by recovering individual vDisks rather than an entire VM.
SyncVM also allows you to restore individual files from within a vDisk. SyncVM accomplishes this by mounting the appropriate snapshots of the desired vDisk(s) to the original VM as temporary disks. Once that occurs, you (or an affected user) can go into the snapshot and get exactly the files that are needed.
This functionality is so useful that we have talked about it quite a bit in past videos and blogs:
There are a variety of IT processes that require copies of large data sets. For example, when development and test engineers roll out new versions of software, they need test data sets that have the same size and complexity as the production data. Most teams make do with too few data copies, and those are often weeks or months out of date. This is because the traditional approach for provisioning data copies is cumbersome, time-consuming, and difficult to manage. Full copies consume a large amount of expensive storage space and take hours to create.
Copy data management allows a DevOps team to have the up-to-date data copies they need, when they need them. Instead of relying on multiple physical copies, copy data management with SyncVM creates “virtual” copies, eliminating the data duplication and time required to make physical copies.
The problem with most approaches to data synchronization in a DevOps environment is that you have to rebuild the entire environment, including all the necessary VM settings, any time you refresh the data. With SyncVM, Tintri makes it possible to accomplish refreshes without rebuilding the environment, streamlining the process. You can take one or more vDisks from a production database and efficiently clone them out to one or more targets as illustrated below.
SyncVM copy data management is also extremely useful for staging environments. For instance, you can clone a set of VMs from production, and then modify the clones to suite your needs. The production VMs may be configured with more resources than you need for staging, and you may want to assign the staging VMs to an isolated VLAN to ensure you can do staging without accidentally stepping on anything in production. Once the staging environment is configured the way you want it, you can refresh data sets from production on a regular basis without affecting it or make additional copies of the environment.
If you want to learn more about copy data management using SyncVM, we again have a lot of resources.
Tintri all-flash storage and software controls each application automatically