Tintri VMstore Data Recovery
Tintri VMstore is a hybrid or all-flash array built specifically around per-VM storage management rather than traditional LUNs or file shares, presenting an NFS datastore to hypervisors while tracking every virtual disk individually inside its own operating system. Tintri filed for bankruptcy in 2018 and its assets were acquired by DDN, which continues the VMstore line under the EC-series alongside legacy T-series hardware still in the field.
Platform Lineage and Naming
Tintri introduced VMstore with a hybrid flash-and-disk design, later extending the line to the T400, T500, T600 and T800 series and the higher-capacity T5000 and T7000 all-flash systems. Tintri OS underpinned all of these with per-VM analytics and management as its distinguishing feature.
Following Tintri's 2018 bankruptcy, DDN acquired the company's assets and continued VMstore development under its own branding, releasing the EC6000 and EC8000 series while maintaining compatibility with the per-VM model pioneered by the original product.
- Tintri VMstore T400, T500, T600, T800 series
- Tintri VMstore T5000, T7000 all-flash
- DDN Tintri EC6000, EC8000 series
- Tintri OS
- FlashFirst tiering
Generations and Models We Evaluate
| Generation / family | Models |
|---|---|
| Legacy Tintri | VMstore T400, T500, T600, T800, T5000, T7000 |
| DDN-era | Tintri EC6000, EC8000 |
Architecture and Data Layout
VMstore abstracts storage at the level of individual virtual machines and virtual disks rather than LUNs or volumes, so administrators and Tintri OS itself track per-VM performance, snapshots and capacity even though the underlying datastore is presented over NFS.
FlashFirst places active data on flash and de-stages colder blocks to disk on hybrid models, with Tintri OS making that placement decision continuously based on observed per-VM I/O patterns rather than fixed tiers.
Snapshots and clones in VMstore are taken at VM or vDisk granularity, which is useful for restoring individual machines but means that recovering a whole datastore after serious damage requires reconstructing the per-VM metadata layer, not just the NFS export.
Protocols and formats: NFS, VMware vSphere, Hyper-V (select models), REST API for per-VM management
- Data protection is RAID-based beneath the per-VM abstraction layer, with the specific scheme varying by model generation.
- Per-VM metadata sits above the physical RAID layer and must be intact, or reconstructable, for individual virtual disks to be identified correctly during recovery.
Failure Scenarios
Logical failures
- Deleted VMs, vDisks or per-VM snapshots
- NFS datastore corruption visible to the hypervisor
- Failed Tintri OS upgrade
- Replication or migration errors between VMstore systems
- Accidental reformatting or datastore removal during decommissioning
Hardware failures
- Multiple drive failures exceeding RAID tolerance on a shelf
- Controller failure with an incomplete or failed failover
- Flash tier failures on hybrid models affecting FlashFirst placement
- Power-loss events during active tiering operations
What Not To Do Before an Evaluation
- Do not run rebuilds, reconstructions or re-initialisations against an array that has already lost more drives than its protection level allows.
- Do not recreate pools, aggregates, disk groups, storage pools or clusters — these operations write new metadata over the structures a recovery needs.
- Do not swap drives between slots, and do not reorder shelves. Record the original slot and shelf positions before removing anything.
- Do not run file-system repair tools against production volumes before the underlying storage layer has been evaluated.
- Do not restore a backup or replication set over the affected volumes until the recovery scope has been assessed.
- Do not eradicate deleted volumes or empty recycle/destroyed states on platforms that hold deleted data for a retention window.
Our Evaluation and Recovery Process
- Intake and platform identification — array model, generation, firmware, protection layout and the sequence of events that led to the failure.
- Read-only evaluation of the media and array structures, including assessment of drive health and the extent of any physical damage.
- Forensic imaging of all contributing media, with cleanroom work where drives require it. Originals are preserved unaltered.
- Reconstruction of the storage layer — pools, aggregates, parity groups, chunklets, extent groups or objects — from the images.
- Extraction of the layers above: file systems, virtual machines, databases, mailboxes and shares.
- Verification against a file list and customer-nominated critical data, followed by secure return on encrypted media.
Frequently Asked Questions
Is Tintri VMstore still supported now that DDN owns it?
DDN continues the VMstore line under the Tintri and EC-series branding; legacy T-series units in the field may have limited vendor support depending on age and contract status, which is worth confirming before planning a recovery.
Can individual VMs be recovered without touching the whole datastore?
Because VMstore tracks storage at per-VM granularity, isolated VM or vDisk recovery is often possible where the underlying array and its metadata are otherwise intact.
Does the per-VM design change how RAID recovery works?
The physical RAID layer is recovered in a broadly similar way to other block arrays, but an additional step is needed afterwards to reconstruct the per-VM mapping so individual virtual disks can be identified.