Product1 publisher3 min readPublished
Commvault triples Cloud Rewind's Azure reach and reframes recovery as a rebuild job
The expanded service will cover 62% of the Azure resource types Commvault calls enterprise-relevant, and it targets configuration rather than data. Runbooks still assume humans do the rest.
The Product Desk · Product desk
Drafted by a language model from the sources cited here and checked against its claim ledger before publication. How we use AISend a correction
What happened
- Commvault Systems Inc. said it will triple the range of Microsoft Azure resources its Cloud Rewind service can protect and rebuild, part of a push to cut the time enterprises spend piecing cloud applications back together after an attack.
- The expanded coverage takes in 62% of the Azure resource types Commvault considers relevant to enterprise deployments.
- Configuration data is the target of the expanded coverage, not the application data itself.
- Commvault launched Cloud Rewind in October 2024.
- Cloud Rewind runs on technology from Appranix Inc., a Boston cloud resiliency startup that Commvault acquired in April 2024.
Compiled by The Product DeskSomething wrong?How this is made
Why it matters
Commvault said it will triple the range of Microsoft Azure resources its Cloud Rewind service can protect and rebuild, lifting coverage to 62% of the Azure resource types the company considers relevant to enterprise deployments [1] [2]. The target is configuration data, not the application data itself [3], which moves the pitch off familiar backup ground: the question is not whether the bytes survived but whether anyone can reassemble the environment around them.
Cloud Rewind launched in October 2024 and runs on technology from Appranix, a Boston cloud resiliency startup Commvault acquired in April of that year [4] [5]. The service continuously discovers cloud resources and maps the dependencies between them [6]. When something breaks, it orchestrates a rebuild of the application together with the infrastructure and configurations underneath, and teams can run recovery simulations beforehand, including inside isolated air-gapped environments [7] [8].
The case for automating that work rests on how badly manual reconstruction goes. Absolute Security's "The Resilient CISO" survey of 750 chief information security officers, published in January, found that 57% took more than 4.5 days on average to fully recover from an attack or incident, and that no respondent restored operations inside a day [9] [10]. That is a vendor survey and should be read as one, but the shape of it matches the failure mode Commvault is selling against: the data comes back quickly, and then engineers spend days rebuilding networks, identities, policies and dependencies by hand.
Two smaller changes ship with the update. Protection Groups pull application data and cloud configuration into a single air-gapped recovery workflow [11]. Policy-based protection enrolls newly discovered resources automatically by tag, region and type, across multiple clouds from one workflow [12]. Melinda Marks, senior research director and chief analyst at Omdia, said many organizations find out their recovery plan is incomplete "only after an incident has occurred," and pointed to the growing tangle of cloud resources behind modern applications [13]. Pranay Ahlawat, Commvault's chief technology and AI officer, framed the product as recovering interconnected services, infrastructure and configurations together through Commvault Cloud [14].
The commercial context matters as much as the feature list. Commvault signed a multiyear agreement with Microsoft in June to make its recovery and resilience technology available as a native Azure service [15]. Cloud Rewind is available now as an add-on workload in Commvault Cloud, with the broader Azure protection targeted for release in the coming months, and pricing is metered on the number of protected cloud resources [16] [17].
Three things to watch. First, the gap: 62% coverage leaves 38% of enterprise-relevant Azure resource types outside the rebuild scope [18], and a recovery plan that reconstructs most of an application is still a plan with human hours in it. Buyers should ask which types are excluded before treating the runbook as automated. Second, the arithmetic of the claim: if the tripling is measured against the same set of enterprise-relevant types, coverage before this update was roughly 21% [19], which is a useful reminder of how narrow configuration rebuild has been to date. Third, the meter. Policy-based auto-enrollment by tag and region combined with per-resource pricing [12] [17] means the bill tracks cloud sprawl rather than data volume, so finance and platform teams will need to agree on what gets tagged into scope.