Expanding Cloud-Native Protection Across Clouds With Commvault

Cloud-native applications depend on data distributed across databases, object stores, retrieval pipelines, and lakehouse tables. When that data is deleted, corrupted, or changed by a bad deployment, recovery can require full restores, temporary resources, application reconfiguration, and the reconstruction of downstream dependencies. In the closing segment of Commvault’s Cloud Field Day 26 session, Jeff Cassianna and his colleague Akshay turned from Clumio’s AWS capabilities to its expansion across clouds. Akshay observed that applications increasingly ignore cloud boundaries, with customers assembling the best services from AWS, Google Cloud, and Azure, so Clumio is becoming a multi-cloud data protection offering. Clumio announced support for Google Cloud Storage at Google Cloud Next in May 2026, with general availability in summer. It brings the same operating principles Clumio uses for S3 backups that are air-gapped and immutable in a separate Google Cloud project, an agentless and serverless design that needs only a role with the right permissions, and scalability to the 70 to 80 billion objects per bucket already proven on S3.

Delegate questions drew out how customers actually operate the product. Akshay said most Clumio users work through the API or Terraform rather than the console, noting that the average user logs into the console only once every 37 days and that Clumio’s Terraform module was long among the most downloaded in data protection. Asked about recovery as code, he said Clumio has long described itself as data protection as code, and he noted that customers are now moving toward agentic recovery, in which an LLM orchestrates the entire restore from a prompt, though many still use scripted recovery. He also explained that Clumio describes its focus as AI-based rather than AI-native applications because it operates at the data layer, not at the agent or application level.

Jeff then gave a live demo in the Clumio SaaS interface. He showed a Google Cloud project he had already onboarded, a process he said takes about five minutes, and a bucket protected by a backup policy and a protection group. The policy sets how often backups run and how long they are kept, and the protection group applies the policy to a specific asset. The policy used continuous backup, which checks for changes every 15 minutes, the most frequent option for S3 and GCS. Jeff’s Python script simulated a ransomware attack on a prefix of 100 objects, renaming each one and replacing its 32-byte contents with a fake ransom note. Jeff then restored the entire prefix from the previous day’s Secure Vault copy, choosing the latest version only to save cost. In about two minutes, the object names, sizes, and contents were back to normal. He confirmed that GCS currently supports Secure Vault only, with no S3 Backtrack equivalent yet. He added that in a real attack he would recover to a separate Google Cloud project, since the rest of the compromised project may also be affected. On monitoring, Akshay said Clumio provides built-in task alerts but does not natively integrate with security or observability tools such as CrowdStrike, Wiz, or ServiceNow. Some customers connect those tools through Clumio’s API, which he called the product’s “gateway to the world.”