Cohesity’s Cloud Recovery Bet: Rebuild From Code, Not From a Snapshot
Terraform recreates the environment a company declared; Cohesity restores the data. The distinction matters when the last snapshot already contains the attacker’s changes.
Cohesity announced that HashiCorp, now part of IBM, has validated its cloud rebuild capability for use with Terraform Self-Managed, making it the first cloud recovery method IBM has validated for that platform. The mechanism is straightforward to describe and harder to build: Terraform recreates the cloud environment a company declared in its infrastructure-as-code files, and Cohesity restores the application data from backup. The result is an application returned to the state its engineers specified, rather than to whatever production looked like an hour before someone noticed the intrusion.
That distinction is the whole argument. Most recovery tooling restores a copy of production as it existed immediately before the attack, which sounds correct and often is not. If an attacker spent three weeks inside an environment, modifying security groups, adding IAM roles and quietly changing configuration, the last pre-detection snapshot faithfully preserves their work. Restoring it puts the intruder’s changes back into production along with the data.
What was validated
The validation covers cloud rebuild as it runs against Terraform Self-Managed, the self-hosted version of HashiCorp’s infrastructure-as-code platform. Cloud rebuild itself is not new. Cohesity shipped it earlier this year for Terraform-provisioned environments and select AWS services, and it sits inside Cohesity Data Cloud Enterprise Edition. What is new is that IBM has reviewed how the two products work together and confirmed the interoperability, which matters to buyers who will not run recovery on an unvalidated integration.
The mechanics that are actually difficult
Four steps carry the design, and each addresses a problem practitioners will recognise. Cloud rebuild first reads the organisation’s Terraform code and builds a map of every cloud resource that needs protection, along with the order in which those resources must come back. That ordering is not cosmetic. A database restored before its network and security groups is useless, and an application load balancer brought up before its target groups is worse than useless. Terraform already encodes those dependencies, which is why using it as the recovery blueprint beats a hand-written runbook.
Second, it saves trusted versions. Cloud rebuild captures the processed infrastructure code as a timestamped manifest, a single JSON document that becomes the recovery point, and backs up both the code and the application data over time. Third, it rebuilds step by step, recreating the declared infrastructure and then restoring data from the latest usable backup for that recovery point, with a guided multistep process for stateful services such as Amazon RDS where the restored database has to reconnect to the rest of the application.
Surfaces The Timing Gap
Fourth, and most interestingly, it surfaces the timing gap. Infrastructure code and application data back up on separate schedules, so the code version a team wants and the data backup it wants rarely sit at the same moment. Cloud rebuild pairs the closest data backup with the chosen code version and shows how far apart in time the two are. That is a small feature answering a question every recovery exercise eventually raises: what exactly am I restoring, and how much state am I losing to get it.
The clean room matters as much as the rebuild. Cohesity’s recovery workflow validates and scans restored workloads in an isolated environment before anything returns to production, which addresses the failure mode that has embarrassed more than one recovery exercise: restoring quickly, and restoring malware with the data. Speed and safety pull against each other in every incident, and the design choice here makes the safety step explicit rather than optional.
Anyone who has run a recovery exercise knows where these plans break. The runbook is out of date because someone changed a subnet range six months ago and nobody updated the document. The dependency order lives in one engineer’s head. The database restore works, but the application’s service accounts point at the old instance and nothing reconnects. Cohesity’s design addresses the first two by deriving the map and the order from code engineers maintain for other reasons, and the third with the guided reconnection step. None of that guarantees a clean recovery, but it moves the failure modes from documentation drift to things the code already knows.
Why your code, not a generated model, is the real claim
The competitive claim sits in a single sentence of Cohesity’s technical explanation: the platform rebuilds from the customer’s Terraform, the modules the team already reviewed, approved and versioned, while other tools rebuild from a model they generate themselves. That is a sharper distinction than it first appears. A vendor-generated model of an environment can cover estates nobody provisioned in code, which is most enterprises. But it is also a second artefact that someone has to trust, maintain and reconcile against reality, and during an incident nobody has time to reverse-engineer it.
The change-control argument follows from the same point. When recovery runs on the organisation’s own code, the rebuild passes through the review process the team enforces everywhere else rather than around it. A platform team that has spent years refusing manual production changes will find it easier to defend a recovery that used the same pull requests as the original deployment.
The cloud recovery market has organised itself around three claims. Rubrik emphasises cyber resilience and data security posture. Veeam and Commvault emphasise breadth of workload coverage and speed of restore. Cohesity’s cloud rebuild is narrower and more specific: it recovers cloud applications provisioned in a particular way, and it argues that the specificity is the point. That is a defensible position for a segment of the market and a limiting one for the rest, which explains why the company leads with validation by the infrastructure-code vendor rather than with recovery-time benchmarks.
The dependency nobody mentions
There is a question the announcement does not address, and it matters. The entire approach assumes the infrastructure code is trustworthy. If an attacker can push to the repository or alter the Terraform state, then rebuilding from code restores a compromised blueprint with the same fidelity it restores a clean one. Cohesity mitigates this by versioning the code and backing it up alongside the workloads, so a team can choose an earlier version, and by keeping Git credentials on the customer’s own automation host rather than collecting them over the network. But the integrity of the code itself rests on repository controls, branch protection and review discipline, none of which a backup product can supply. Buyers should treat the infrastructure repository as a tier-one security asset after reading this announcement, because the cloud recovery strategy now depends on it.
The readiness gap
The release leans on a survey that deserves attention on its own terms. Cohesity’s 2026 Global Cyber Resilience Report, conducted by Vanson Bourne across 3,200 security and IT decision-makers, found that 83 per cent of organisations say their recovery plans would need moderate or significant changes to handle attacks that use AI to find and exploit software weaknesses. Only 3 per cent describe their plans as ready today. That gap is the market this product sells into, and it is worth noting that the survey is the vendor’s own commissioned research, which is standard practice and worth flagging whenever the figure gets quoted.
What it does not cover
Three limits are worth stating plainly. Cloud rebuild works for environments provisioned with Terraform and, at present, select AWS workloads, which means an enterprise with a mixed estate gets a partial capability rather than a universal one. It rebuilds infrastructure and restores data, but it does not decide which recovery point is clean; a separate capability scans candidate points against threat intelligence feeds and validates workloads in the clean room before cutover. And it does not address identity compromise, which is increasingly how destructive attacks begin, because a rebuilt environment with a compromised identity provider is still compromised.
What it signals
The announcement marks a convergence that has been forming for two years: infrastructure-as-code discipline migrating from provisioning into resilience. Teams that adopted Terraform did so to make environments reproducible, and reproducibility is precisely what recovery needs. The vendors that win the next phase of cloud recovery will be those that treat the customer’s own definitions as the source of truth rather than inventing a parallel model of the environment. Cohesity‘s bet is that disciplined platform teams will pay for recovery that follows their code. The bet is sound for those teams and irrelevant to the many organisations that still provision by console, which is the honest limit of the claim.
A second-order effect is worth noting. If recovery increasingly depends on infrastructure code, then the quality of that code becomes a resilience metric, and most organisations do not measure it. A platform team that knows how many of its workloads are Terraform-managed, how current the modules are and who can approve a change to them sits in a materially better position than one that does not. That improvement costs nothing and is available today, which makes it the cheapest item on any cyber resilience roadmap.
There is a competitive question underneath all of this. If cloud recovery increasingly runs from infrastructure code, the natural winner is whichever platform can read the widest range of code and workloads, not whichever has the deepest integration with one vendor’s tooling. Cohesity has chosen depth first, which is the right order for a company selling into platform teams, and it will need breadth to sell beyond them.