Introduction to Multicloud Snapshot Technology (MST)

What is MST?

Multicloud Snapshot Technology (MST) is a purpose-built storage stack designed for high-performance snapshot management. It allows for the storage and retrieval of a massive volume of application snapshots within any Nutanix validated S3-compliant object store.

By utilizing MST, enterprises can maintain deep snapshot chains while delivering extremely low retrieval latency and bounded-time garbage collection, regardless of how deep the chain grows. This promotes smooth application performance, even in complex hybrid multi-cloud environments.

Why does MST matter?

Enterprises need to maintain long snapshot chains to address a variety of use cases like Business Continuity and Disaster Recovery (BCDR), cyber resiliency and compliance. 

• Cost-efficiency: By choosing  an object store as the substrate to manage snapshots, it opens the door to a multitude of opportunities, ranging from cost effective Disaster Recovery to the public cloud to low cost retention for compliance.
• Primary Storage optimization: Snapshots consume expensive primary storage space, especially in all-flash clusters. MST frees the primary HCI cluster from having to manage long snapshot chains which occupy expensive storage in all-flash clusters. The primary system continues to do what it is best at, i.e.,serve application I/O. Retention of snapshots gets offloaded to MST.
• Nutanix native: MST is native to the Nutanix BCDR stack. It integrates with all other BCDR functionalities and shares the same management platform as rest of the BCDR features.

Anatomy of a Snapshot in MST

MST leverages a novel indexing scheme based on copy-on-write B+Trees.  Snapshots are laid out in an object store in hierarchical fashion, as depicted below.

• Storage Target is a global object for the MST. It contains information about the bucket and its various other parameters like type, region, etc. This provides an abstraction layer on top of various object stores and generalizes the property of the underlying backend. Storage target acts as a repository for the recovery points and its associated metadata described below.
• Recovery Point is an object that contains a serialized form of the snapshot configuration. For example, a VM recovery point contains the VM name, identifier, the VM’s configuration (e.g., virtual CPUs, memory), recovery point creation time, expiry time, etc.
• Disk is an object that contains a serialized form of the metadata of a snapshot disk. It contains information like disk state (committed, expired), pointer to a parent disk (e.g. delta replication), pointer to B+tree root, disk size, etc.
• Index node contains a node of the B+Tree index. It can be a leaf node that references the data objects, or a non-leaf node which points to child nodes in the tree.
• Data object contains data ranges of a given disk. Data stored in an object is divided into fixed sized slices (typically 32 KB in size) and each slice is transformed before storing into the object. Transformation could be compression, encryption, etc.

MST Services

The MST cluster itself comprises three primary services and three auxiliary services. All these services run as pods in a Nutanix managed Micro Services platform (Kubernetes® cluster). Each service can scale out linearly by creating more instances (Pods) of itself. The primary MST services are:

Control Service: Responsible for managing the workload configuration captured by the snapshots. For instance, it manages the virtual machine configuration like virtual CPU, memory size, NIC cards, etc. as captured by a snapshot. The control service stores this metadata in the object store for durability, and in a local database called Recovery Point Database for queryability. The local database enables a user to issue sophisticated queries (e.g., list the snapshots of VM hr-vm that were created within a date range) on various attributes of the snapshots.

Data Service:  The data plane of MST, which is responsible for managing the data blocks of the snapshots’ virtual disks. The data service stores data for these disks as objects in the object store. Once the data of a virtual disk is stored as a bunch of objects, we need a way to read from an arbitrary offset of that virtual disk. For this, the Data Service creates a Copy-on-write B+Tree index for each virtual disk, keyed by the offset. This index is responsible for the consistent retrieval time for the data, regardless of the length of the snapshot chain. As discussed below, this same B+Tree index provides a scalable garbage collection scheme, enabling MST to support hundreds of snapshots of thousands of VMs.

Janitor Service: This service is responsible for garbage collection of snapshots once they expire. It leverages the copy-on-write B+Tree index to compute garbage in bounded time. For instance, garbage collection of any disk snapshot can be performed in bounded time, by doing a B+Tree differencing with two adjacent snapshots.

The above services leverage the following auxiliary services for their functioning.

Recovery Point Database: This is a document database, stored on a local storage in the k8s cluster. As the name suggests, it stores the recovery point metadata (configuration) such as VM name, identifier, resources like vCPU, memory etc. Additionally, it maintains snapshot specific information like creation time, expiration time etc.

Distributed key-value store: When the data service receives a data range (virtual disk, offset, length, data) of a snapshot from the primary system, it writes the data to an object at a specific offset. It needs to retain this information somewhere to create the B+Tree index later. A distributed key-value store is used for this purpose. We use our home grown distributed key-value store called ChakrDB.

Zookeeper: Many of the MST services exhibit a leader-worker model. The Apache ZooKeeper™ service is used for leader election as well as global configuration management of these services.

Conclusion

Multicloud Snapshot Technology (MST) provides a robust, scalable architecture for managing snapshots in object stores, efficiently offloading from primary clusters while helping promote resilient data management. This transforms BCDR into a streamlined cost-effective strategy, enabling enterprises to build operational resilience and confidently modernize at scale.

©2026 Nutanix, Inc. All rights reserved. Nutanix, the Nutanix logo and all Nutanix product and service names mentioned are registered trademarks or trademarks of Nutanix, Inc. in the United States and other countries. Kubernetes is a registered trademark of The Linux Foundation in the United States and other countries. All other brand names mentioned are for identification purposes only and may be the trademarks of their respective holder(s).