NetApp Buys JetStream—and Adds Recovery Orchestration to Its Resilience Stack
NetApp acquired JetStream Software on August 6, 2026, adding technology for protecting, recovering and moving VMware workloads. A NetApp-sourced release dated August 6 says JetStream extends the company’s data-protection reach to VMware environments using either NetApp or third-party storage.
An Axios report published August 7 identifies JetStream as a San Jose cyber-resilience technology company that had raised about $13 million. Public deal details do not include the purchase price or a timetable for incorporating JetStream into named NetApp products.
NetApp bought the recovery layer around protected data
JetStream DR does more than retain a copy of a virtual machine. It continuously protects VMware workloads, groups related machines into protected domains and coordinates how those workloads are reconstructed and restarted at a recovery site.
That operational layer is the important addition to NetApp’s resilience stack. Storage replication can preserve data, but application recovery also requires virtual machines, network mappings and dependent services to return in a usable sequence. JetStream manages the transition from replicated data to running workloads, including failover, failback and disaster-recovery testing.
The acquisition therefore gives NetApp control of recovery-orchestration software, not merely another backup repository. It does not, by itself, mean that JetStream functions are already embedded across NetApp’s existing services or that current deployments have different infrastructure requirements.
How JetStream’s documented Azure design works
NetApp’s JetStream deployment documentation describes on-premises VMware changes being captured through host I/O filters and replicated to Azure Blob Storage. Related virtual machines are placed in protected domains, which define which workloads are protected together and their priority during failover and failback.
The protected site uses a JetStream DR Management Server Virtual Appliance, host-level I/O filter packages, one or more DR Virtual Appliances and replication-log volumes. Administrators also need an Azure storage account in the recovery region, suitable connectivity and enough replication bandwidth for the workload plan.
At the destination, JetStream software runs in an Azure VMware Solution private cloud. It connects to the existing Blob container, discovers the protected domains and deploys the required recovery appliances. A Recovery Virtual Appliance then places reconstructed machines on an available vSAN or Azure NetApp Files datastore.
Failover runbooks provide the orchestration layer. They can arrange virtual machines into recovery groups, control boot order and change CPU, memory and IP configurations for the recovery environment. Standard failover rebuilds workloads after an incident, while continuous rehydration prepares destination storage in advance for workloads with tighter recovery-time requirements.
Why the capability extends beyond conventional backup
Conventional backup focuses on creating, retaining and retrieving recoverable copies. JetStream continues into the execution phase: it maps stored virtual-machine data into a recovery environment, applies workload relationships and network settings, starts systems in a defined order and supports their return to the original site.
The Azure architecture also separates retained recovery data from the compute environment that will eventually run the applications. Azure Blob Storage can hold replicated data without requiring the full recovery environment to carry production workloads continuously. Recovery still depends on Azure VMware Solution capacity, destination networking, suitable datastores and the appliances needed to reconstruct the machines.
JetStream consequently complements storage-level protection rather than replacing every replication or backup mechanism. Its role is to coordinate VMware workload recovery across the stored data, virtual infrastructure and application dependencies involved in a failover.
Point-in-time recovery supports ransomware response
JetStream supports recovery from available points in time, allowing administrators to select a state that predates suspected corruption. In the documented Azure design, workloads can be reconstructed in an isolated network where related applications communicate with each other without immediately accepting normal north-south traffic.
That isolation creates a controlled environment for forensic examination and remediation, but it does not prove that a selected recovery point is clean. Incident responders must still establish when the compromise began, check application and data consistency, look for persistence and decide when recovered systems can safely reconnect.
Protected domains are significant in this scenario because an enterprise application may span several dependent virtual machines. Recovering the group according to retained priorities and an ordered startup plan is a different task from restoring unrelated disk images individually.
Product integration remains the open question
The completed acquisition gives NetApp software that connects continuous VMware protection, cloud object storage and orchestrated recovery. Existing JetStream deployments nevertheless retain their documented management, replication, recovery and destination-infrastructure dependencies unless NetApp publishes a replacement architecture.
NetApp has not publicly specified when the technology will appear in named commercial offerings, whether licensing will change or how support for existing customers will be organized. As of August 9, the confirmed development is the acquisition of JetStream’s recovery-orchestration capability—not the release of a newly integrated NetApp product.
Also read:
Subscribe to our newsletter
Get the latest Web3, AI, and crypto news delivered straight to your inbox.