Accelerating Large-Scale Clone Replication using MST

Why does Clone support matter?

For modern enterprises, the ability to handle large-scale, highly synchronized infrastructure scale is essential. Whether spinning up automated database clones for development, provisioning temporary application sandboxes, or deploying thousands of Virtual Desktop Infrastructure (VDI) seats, scaled environments inevitably share an immense amount of identical block data. This shared data encompasses everything from identical baseline operating system images and corporate software suites to core database configurations and attached application data disks.

When executing mission-critical operations like backup, disaster recovery, or cross-cluster migration, efficiently replicating these large, interconnected clone lineages is important. However, if the underlying replication engine fails to natively optimize for shared storage lineages, enterprise infrastructure can hit a critical operational bottleneck.

To address this trade-off, the MST replication path was designed to support uncommitted references, enabling parallel replication of related clone workflows. Here is a look at the architectural journey, the alternative frameworks that were explored, and the final design that MST leverages.

Understanding the Disk Relationship

To understand how data flows across clone or snapshot trees, we must first establish a baseline for how disks and snapshots relate to one another. Fig 01 provides the structural legend for these relationships. Subsequent figures use this convention.

• Live vDisks (V_i​​): Active, un-snapshotted virtual disks that are actively processing live I/O.
• Snapshots (V_i​S_j​​): Point-in-time, read-only state of a specific virtual disk.
• Clones (V_i​S₀​): New virtual disks spun up directly from an existing parent snapshot.
• Child Snapshots (V_i​S_j+1​): Sequential descendant snapshots capturing changes built on top of previous iterations.

Alternate Solutions Explored

Before describing the MST clone-replication design, let’s evaluate two traditional approach patterns to handle clone replication from primary clusters to a Multicloud Snapshot Technology (MST). These simplified approaches are included to illustrate the trade-offs.

Solution 1: Full Data Transfer for Clones

As illustrated in Fig 02, when parallel replication of clones to the storage target begins, there is no existing reference candidate established on the target side yet. Because the target has nothing to use as a reference for incremental transfers, each concurrent clone stream may need to perform a full data transfer of its entire storage volume over the network when no usable reference exists on the target. Forcing duplicate baseline OS and data disk blocks over the wire results in wasted bandwidth and highly uneven throughput.

Solution 2: Lineage-based Clone Serialization

To mitigate the network strain of the above  scenario, seeding replication can be serialized  based on a unique lineage ID as shown in Fig 03.

This strategy forces the replication engine to transfer the first disk in the lineage entirely on its own while other descendant disks may wait until the initial disk has completed and been committed on the target. Once the baseline replication for that pioneer disk is fully completed and committed on the storage target, the remaining disks are permitted to replicate in parallel, safely using it as a reference for incremental replication.

While this avoids redundant data transfers, it introduces a trade-off: potentially longer replication completion times and reduced recovery-point freshness in some environments due to serialization. If there aren't enough independent disks to fill the pipeline, cluster replication resources sit idle, lowering overall system throughput.

The Final Design: True Parallel Clones Replication via Uncommitted References

To break the deadlock between network bloat and serialization delays, MST supports an uncommitted disk snapshot that can serve as a reference for related replication streams.

Fig 04 demonstrates this optimized parallel workflow. When multiple clones replicate simultaneously from the source cluster to MST, the system dynamically selects one of the incoming disks to act as the reference for the remaining sibling streams.

Crucially, this reference disk does not need to be committed on the target side to be useful. The descendant disks can run parallel, incremental data transfers right alongside the reference disk while it is actively writing. This is designed to improve cluster throughput and supports replication objectives, depending on workload, configuration, and the replication environment.

Under the Hood: Overhauling System Mechanics

Moving from a strict "committed-only" referencing rule to a dynamic, uncommitted state required an overhaul of several core system mechanics:

1. Dynamic Reference Resolution: The data-receiving ingestion service was updated in the applicable MST workflow to accept uncommitted snapshots as valid reference candidates. The underlying data layer was updated to handle concurrent replication requests to a chain of uncommitted snapshots, allowing child disks to be created from uncommitted parents in the supported workflow.
2. Strict Top-Down Finalization Order: A snapshot cannot be committed if its parent snapshot is still undergoing replication (i.e. still uncommitted). Because clients cannot consume such a snapshot having incomplete data. To guarantee absolute data integrity, the system enforces a strict top-down finalization order. If the parent of a given snapshot is uncommitted, the snapshot itself is delayed from finalization.
3. Smart Deletion & Garbage Collection Safety Rails: Managing storage reclamation when multiple uncommitted disks depend on one another requires carefully calibrated Garbage Collection (GC) safety rails:
   • Deletion of a committed parent: If a parent snapshot was fully committed and is subsequently deleted by system policy, ongoing uncommitted child replications are unaffected and can continue building normally.
   • Deletion of an uncommitted parent or Abort: If a parent disk is deleted or its replication is aborted before it can finish finalization, the entire child chain dependent on it becomes invalid and gets garbage collected.
4. Retaining reference snapshots: To ensure that reference snapshots are not prematurely deleted while clones are being replicated, MST applies a persistent lock to the reference snapshots  upon client request.

Conclusion

As enterprise clone environments continue to expand, underlying MST infrastructure must support increasing scale to handle highly parallelized demands without sacrificing core cluster efficiency. MST introduces uncommitted reference support within the storage system to achieve significant milestones in breaking the trade-off between massive network bandwidth bloat and strict serialization delays. This makes MST a preferable choice for storing snapshots of clones for longer retention.

©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. All other brand names mentioned are for identification purposes only and may be the trademarks of their respective holder(s).