For decades, the disaster recovery playbook was straightforward: maintain a secondary datacenter, replicate production data and switch operations to the second site if the primary facility became unavailable.

That model was built mainly for physical disruptions such as fires, floods, power failures and regional connectivity outages. It still has a role, but the risk environment has changed.

Today, organizations must also prepare for ransomware, compromised identities, malicious data deletion and attacks on backup infrastructure. In these situations, a second facility does not automatically guarantee recovery. If it shares the same credentials, administrative tools and network trust as production, it could be exposed to the same attack.

The question for infrastructure leaders is therefore no longer simply, “Do we have another datacenter?” It is: Can we recover critical services from a clean, isolated and tested environment if production systems and administrative controls are compromised?

The Shared-Fate Challenge

Traditional disaster recovery environments are often close replicas of production. This makes failover easier during a physical outage, but it can create a shared-fate problem.

Production and recovery environments may use the same identity directory, privileged accounts, replication paths, service accounts and administrative consoles. During a physical failure, these connections help restore services quickly. During a cyberattack, they may allow the compromise to spread.

Replication also has limitations. It maintains current copies of data, but it cannot determine whether that data is clean. Encrypted, corrupted or deleted data may be replicated before an attack is detected.

This does not mean secondary sites or replication are no longer valuable. It means recovery architectures must now be designed for cyber compromise as well as physical disruption.

Is a Second Production Environment Really a Recovery Site?

Many organizations use their secondary datacenter for development, testing, analytics and other non-production workloads. While this improves infrastructure utilization, it can complicate recovery.

During a disruption, existing workloads may need to be stopped before production applications can be restored. Capacity must be released, dependencies reconfigured and applications restarted in the correct order, often under severe time pressure.

Non-production environments may also have broader access, more frequent changes and less restrictive security practices. Unless properly segmented, this reduces the isolation expected from a recovery platform.

A secondary location can be highly valuable. However, the presence of infrastructure alone does not make it recovery-ready.

Recovery Must Be Demonstrated, Not Declared

Modern operational resilience frameworks increasingly focus on whether recovery can be tested, evidenced and executed under realistic conditions.

For example, the EU Digital Operational Resilience Act requires applicable financial institutions to document and periodically test backup and recovery procedures. It also addresses the physical and logical segregation of systems used to restore backup data. The UK Prudential Regulation Authority expects applicable firms to test their ability to remain within defined impact tolerances under severe but plausible disruption scenarios.

In India, the Reserve Bank of India’s Information Technology Governance, Risk, Controls and Assurance Practices Directions address business continuity, disaster recovery management and cyber incident response and recovery. US FFIEC guidance similarly covers resilience strategies, exercises, testing and continuous improvement.

Specific obligations vary by industry and jurisdiction. The broader direction, however, is clear: organizations need evidence that critical services can be restored securely and within agreed business requirements.

Why Cloud Can Be the Right Recovery Target

The economics of cloud depend on how frequently infrastructure is used.

Applications with high, predictable utilization may be better suited to dedicated infrastructure. Disaster recovery compute has a different demand pattern. Outside scheduled exercises or an actual disruption, it may be used infrequently.

This allows organizations to separate what must remain continuously available from what can be activated when needed.

Recovery data must remain protected, discoverable and restorable. Recovery compute does not always need to run at full capacity throughout the year.

Microsoft Azure can therefore provide an on-demand recovery location for suitable workloads. Nutanix Cloud Clusters on Azure supports Nutanix environments on Azure infrastructure and can be used for disaster recovery and business continuity scenarios.

The benefit is not only financial. A cloud recovery environment can also be designed with separate identity, access and network boundaries, reducing dependence on the production trust plane.

Building a Disaggregated Hybrid Architecture

A modern recovery platform can assign a specific role to each layer rather than expecting one technology to address every requirement.

Nutanix for Compute and Virtualization

Nutanix AHV provides the enterprise compute and virtualization layer, with centralized, virtual machine-focused operations through Nutanix Prism.

Separating compute from storage allows organizations to increase compute capacity without automatically buying more storage or expand storage without adding unnecessary compute.

Pure Storage for Enterprise Data Services

Pure Storage FlashArray provides the external all-flash storage layer. The joint Nutanix and Pure Storage architecture supports external storage using NVMe/TCP, enabling compute and storage to scale independently.

This model is particularly relevant for storage-intensive environments or organizations where compute and storage demand grow at different rates.

Rubrik for Cyber Recovery

Rubrik provides backup and cyber recovery capabilities for Nutanix workloads, including immutable backups and recovery from clean snapshots.

The objective is not simply to maintain another copy of production data. It is to retain recoverable data that cannot easily be modified or removed through compromised production credentials.

Azure for On-Demand Recovery Capacity

Azure provides the storage, networking and Nutanix recovery compute required during testing or an actual disruption.

Organizations can retain recovery data and the foundational cloud configuration without running a complete recovery estate continuously. Recovery compute can then be provisioned when required and applications restored according to business priorities.

Nutanix also documents zero-compute and pilot-light recovery models, with different implications for recovery speed, automation and ongoing cost.

Together, these technologies create a hybrid platform in which production compute, enterprise storage, cyber recovery and disaster recovery capacity can be scaled and governed independently.

Important Considerations

On-demand cloud recovery will not be right for every workload.

Recovery time must be validated through regular exercises. Data volumes and network bandwidth can affect restoration times. Software and database licensing may change the commercial model. Data residency requirements may also restrict where certain workloads or recovery data can be hosted.

These factors determine whether an organization should use an on-demand, pilot-light, warm-site or mixed recovery model.

From Infrastructure Duplication to Recovery Readiness

The traditional DR datacenter will not disappear from every enterprise. Certain applications, recovery-time requirements and regulatory obligations may continue to justify dedicated secondary infrastructure.

However, maintaining a second location should no longer be treated as proof of resilience.

By combining Nutanix for compute, Pure Storage for enterprise data services, Rubrik for cyber recovery and Microsoft Azure for on-demand capacity, organizations can move from infrastructure duplication to a more flexible, isolated and testable recovery model.

The future of disaster recovery is not defined only by where the recovery infrastructure resides. It is defined by whether an organization can restore clean data, recover critical services and prove that its recovery plan works before a real disruption occurs.