The recovery question behind Live Mount

In backup and recovery conversations, speed often gets reduced to one familiar question: How fast can we restore?

That question still matters, but it is not always the question the business is asking during an outage. Users, application owners, and business leaders are usually asking something more immediate: How fast can we make the service usable again?

That is where Live Mount becomes valuable.

With Hitachi Data Protection Suite (HDPS), powered by Commvault, Live Mount and related live recovery workflows can help organizations use protected backup copies more actively. Instead of waiting for every block of data to be copied back to production storage before a virtual machine can be started, teams can mount a protected VM from backup storage, power it on, validate it, and in some recovery scenarios make it available while the longer restore or migration process continues.

That capability changes the recovery conversation. Backup data is no longer just something that waits in the repository until a restore finishes. It can become a temporary source of availability, a practical validation point, and a useful platform for recovery readiness.

There is an important boundary, though: running a VM from backup storage is not the same as running it from primary storage. Live Mount is powerful when it is used for the right purpose and backed by the right architecture. Understanding that balance is what makes the feature operationally useful instead of just interesting.

From protected copy to usable workload

At its simplest, Live Mount allows a protected virtual machine to be mounted directly from a backup copy and powered on in the virtual environment. For an administrator, that means the backup repository can become an immediately available recovery source. A VM can be started to confirm that it boots, verify that the operating system is healthy, inspect application behavior, or provide temporary access while a permanent recovery path is completed.

The word mounted can sound a little fuzzy, so it is worth making it concrete. In a VMware environment, the backup infrastructure presents the protected VM to an ESXi host as a temporary datastore, commonly through an NFS presentation. From the VMware side, that looks much more familiar: a datastore appears, the VM files are available there, and the mounted VM can be registered and powered on. Instead of thinking of Live Mount as a mysterious backup process, think of it as the backup platform presenting the VM in a form the hypervisor already understands.

That also helps explain why the VM can become usable before a full restore finishes. The VM configuration and virtual disk files, including the VMX and VMDK files, are presented through the mounted datastore. Reads are serviced through the backup infrastructure, while the longer restore or migration back to production storage can continue in the background depending on the recovery workflow.

The value is not only that the data exists. The value is that the workload can become usable sooner.

That distinction matters during a real recovery. Consider a large VM, such as a 2 TB system supporting an important application. If that VM has to be recovered using a traditional streaming restore, the restore may take a significant amount of time depending on network bandwidth, repository performance, deduplication layout, destination storage, and the design of the environment. Even when everything is working correctly, moving terabytes of data is not instantaneous.

During that restore window, the business may still be waiting. Users may not care that the restore job is progressing normally. They care that the ERP system, reporting platform, middleware service, or departmental database they need is unavailable.

Live Mount helps bridge that gap. Instead of telling users, "The system is down while we restore the VM," the message may become, "The system is available while recovery completes, but performance may be reduced until the workload is moved back to production storage." Those are very different business outcomes.

The live-mounted state is a bridge, not a destination. The VM may not perform the same way it would on primary storage, and it should not be treated as a long-term production placement. But for the recovery window, degraded-but-available service can be much better than no service at all. Once the restore or migration back to production storage is complete, the workload can return to storage designed for sustained production performance.

The practical reality: backup storage is not primary storage

The storage behavior behind Live Mount is worth understanding because it determines how far the capability can scale.

Backup repositories are typically optimized for backup and restore operations. Those workloads often involve large amounts of data moving in large sequential streams or larger chunks. That design makes sense. During backup, the goal is to ingest a large volume of data efficiently. During restore, the goal is usually to read large amounts of related data back from the repository. Larger write and read patterns can help throughput and may also help with data locality because related backup data can be stored near other related data.

Live Mount changes the workload profile.

When a VM is powered on directly from backup storage, it starts behaving like a running workload. The guest operating system may request one set of blocks, the application another, and a database, log file, service, or background process still another. Instead of a large sequential backup or restore stream, the repository may see smaller and more random I/O.

That mismatch can become visible quickly on traditional spinning disk. Hard drives can deliver strong sequential throughput, but random I/O is limited by mechanical movement and seek latency. A backup repository built primarily for low-cost retention on spinning disk may perform very well for backups and traditional restores, while still supporting only a limited number of live-mounted VMs before performance becomes constrained.

For a quick validation, a single system recovery, or a small DR test, that may be acceptable. The key is to match expectations to the storage design.

SSD-backed backup storage changes the practical range of what Live Mount can do. Flash media, whether TLC or QLC, is far better suited than spinning disk to handling random read activity. SSDs can absorb much of the performance impact created when a running VM requests small pieces of data scattered across the repository.

That does not turn backup storage into primary storage. Primary storage is still designed, tuned, and sized for production workloads, with different expectations for latency, caching, controller behavior, service levels, and workload mix. But SSD-backed repositories can make Live Mount much more practical for recovery testing, cyber recovery validation, clean-room exercises, application testing, and short-term recovery bridges while a full restore is underway.

Getting more value from SSD-backed backup storage

Once an organization invests in SSD-backed backup storage, it is natural to ask whether that performance can do more than make backups and restores faster. The answer is yes, as long as the role of the repository stays clear.

The point is not to run the business from backup storage simply because the repository is fast. That would blur the line between recovery infrastructure and production infrastructure. The better use of that investment is recovery readiness.

SSD-backed backup storage can become a practical platform for DR practice, clean-room recovery testing, and operational validation. Teams can mount selected workloads in an isolated environment, confirm that systems boot, validate application dependencies, test recovery sequences, and document the process without first provisioning a full set of temporary recovery storage.

That is where the additional value appears. The same performance that helps accelerate restores can also make recovery exercises more realistic and easier to repeat. Instead of waiting for a declared disaster to discover whether a recovery plan works, teams can practice more often, with less setup, and with a better view of how their protected systems actually behave when recovered.

Used this way, the backup repository remains what it should be: a high-value recovery platform, not a substitute for production storage.

Where Live Mount is most useful

Live Mount is useful in several places, but the common thread is simple: it reduces the friction between having a backup and proving that the backup can support a real outcome.

Recovery validation

Backups are only valuable if they can be recovered. Yet in many environments, recovery testing is disruptive enough that it happens less often than it should. Teams may need to allocate temporary storage, perform a full restore, coordinate with application owners, validate the system, document results, and then clean up the test environment.

Live Mount reduces that friction. Administrators can mount a VM from backup storage, power it on, confirm that it boots, inspect the operating system and application, and demonstrate that the recovery point is usable. The question changes from, "Do we believe this backup is good?" to "Can we run this workload from the backup copy right now?"

Disaster recovery testing

Traditional DR testing often requires dedicated infrastructure, temporary storage, manual coordination, and a significant restore window. That can make testing expensive and time-consuming, especially when an application depends on a group of VMs.

With Live Mount, teams can test recovery directly from protected copies. For example, a team may need to validate 20 or 30 virtual machines that support a business service. Instead of restoring every VM before the test can begin, they can mount the systems from backup storage, power them on in an isolated environment, and validate the recovery sequence.

This is where repository performance matters. A spinning disk repository may support a small test or a few live-mounted systems. An SSD-backed repository gives the organization a much stronger foundation for larger DR exercises where many VMs may create random I/O at the same time.

Clean-room and cyber recovery

After a ransomware event or destructive incident, the first recovery point is not always the right recovery point. Teams may need to inspect multiple backups, validate system state, scan data, test application behavior, and confirm whether a copy is clean before committing to a full restore.

Live Mount supports that process by allowing VMs to be started in an isolated environment for investigation and validation. Security and application teams can examine a protected copy, determine whether it is suitable for recovery, and reduce guesswork before restoring data back into production.

In some situations, Live Mount may also provide strictly temporary access to selected critical systems while the broader recovery plan continues. That use should be deliberate and time-bounded, with the expectation that workloads return to production storage once the permanent recovery path is complete.

Application testing and change validation

Live Mount is not only for emergencies. It can also help application teams test patches, upgrades, configuration changes, or troubleshooting steps against realistic copies of production systems.

Instead of creating a full clone or performing a traditional restore, an administrator can mount a recent backup in an isolated environment and allow the application team to validate the change. The test instance reflects a real production state, but it does not affect the production workload. Once testing is complete, the mounted instance can be removed.

This makes backup data more useful to the broader IT organization. The backup platform is no longer only a place where data waits for an emergency. It becomes a source of operational flexibility.

Designing for the outcome you want

The most important design question is not simply, "Does the product support Live Mount?" The better question is, "What do we expect Live Mount to do for us?"

If the goal is to occasionally validate a single VM, the requirements may be modest. If the goal is to support temporary access to a small number of systems during a recovery, the design requirements increase. If the goal is to run larger isolated DR tests, validate application groups, support clean-room recovery exercises, or keep users working while a large restore completes, repository performance becomes a major design consideration.

That is where SSD storage becomes key. It gives the backup environment a better chance of handling the random I/O patterns created when VMs are powered on directly from backup copies. The feature enables the workflow, but the storage architecture determines how far that workflow can scale.

Capacity and retention still matter. Organizations still need the right retention policies, immutability controls, network design, security model, and recovery procedures. But when Live Mount is part of the recovery strategy, performance has to be part of the design conversation as well.

What Live Mount is not

Live Mount is valuable, but it should not be misunderstood.

It is not a replacement for primary storage. It is not a reason to run the environment from the backup repository simply because the repository is fast. It is not a substitute for restore planning, DR design, application dependency mapping, cyber recovery procedures, or performance testing.

A live-mounted VM is usually a temporary operating state. It may be used for validation, clean-room testing, limited emergency access, or short-term service availability during recovery. For sustained production operation, the workload should be restored or migrated back to storage designed for production use.

That boundary is what makes the capability credible. Live Mount helps reduce downtime and improve recovery flexibility, but it works best as part of a broader recovery architecture with clear expectations.

Why it matters

Recovery time objectives are often measured in minutes and hours, but business impact is measured in lost productivity, lost revenue, missed commitments, and lost confidence.

Live Mount helps close the gap between protected data and usable systems. During an actual recovery, it can change the experience from complete outage to temporary degraded service while the permanent recovery process continues. During testing, it can make DR exercises, clean-room validation, and application recovery checks easier to perform and easier to repeat.

The practical lesson is just as important as the feature itself: Live Mount is not magic. It is architecture.

When the backup environment is designed only for capacity and low-cost retention, Live Mount may be useful for smaller tests and limited recovery scenarios. When the environment is designed with SSD-backed performance, Live Mount becomes a much stronger tool for realistic DR testing, cyber recovery validation, clean-room recovery, and short-term workload availability while restore operations continue.

That is the real value. Live Mount is not just about starting a VM from backup. It is about making recovery more immediate, more testable, and more operationally useful without pretending that backup storage is production storage.

When the storage behind it is designed for the job, Live Mount can help turn backup from a passive insurance policy into an active recovery capability.