Data protection vendors usually demo a slick console, walk through protection and restore wizards, and point at a dashboard full of green ticks. That made sense when backup admins spent their days in the backup console. It makes far less sense for cloud-native applications, where infrastructure is defined in code and deployed by pipelines. At Cloud Field Day 26, Commvault’s Akshay Joshi shared a number that stuck with me. The average Clumio user logs into the console once every 37 days. Most customers drive Clumio through its application programming interface (API) or through Terraform. Protection is managed through an application pipeline, and recovery is treated like an application rollback.
Protection Policies Belong in the Deployment Pipeline
Cloud teams already build their applications this way. A new DynamoDB table, Amazon S3 bucket, or Google Cloud Storage bucket arrives through a Terraform configuration in a CI/CD pipeline, not through someone clicking in a console. If the backup policy is part of that same plan, the new resource is protected from the moment it exists. If the backup policy is a separate step owned by a different team, there’s a gap. Someone might forget to log a ticket, and the bucket goes into production without a policy; nobody notices until they need a restore. Akshay said Clumio has long described itself as data protection as code, and that its Terraform module has long been one of the most downloaded in data protection. Teams that manage infrastructure as code want their protection policies reviewed, versioned, and deployed the same way as everything else.
Recovery Benefits Most from Code
Backups are the easy part; Akshay said backup is now commoditized. But backup was never the point; we back up only to restore. Recovery is the hard part, and it usually happens under pressure and out of the blue. A bad canary deployment corrupts some tenant partitions. A script overwrites a few thousand objects. Ransomware encrypts and renames a whole prefix of files. Each needs a recovery that targets the right objects at the right point in time, and attacks arrive at the worst possible moment. I’d much rather run a recovery script that was written and tested last month than have a stressed engineer clicking through a wizard at 3 a.m. Scripts can be reviewed by a colleague and tested against a non-production account. They can also recover billions of objects in bulk through the API, which nobody would attempt one click at a time. Jeff Cassianna recommended restoring to a separate Amazon Web Services (AWS) account or region after a cyber event, or to a separate Google Cloud project, since the rest of a compromised environment may not be trustworthy. That’s the kind of decision you should make calmly ahead of time and write into code; it feels more like a disaster recovery plan than a data restore.
Automated Recovery Needs a Timestamp
Like activating a DR plan, recovery usually requires a human to decide when to recover and to what point in time. Clumio doesn’t currently detect when a bad event happened, so customers supply the recovery timestamp themselves. Point-in-time recovery to the second is only useful if you know which second to pick. In a manual recovery, an engineer digs through logs and makes a judgment call. In an automated recovery, something else has to provide that timestamp. Clumio has built-in task alerts and an API to integrate with security and observability tools such as CrowdStrike, Wiz, or ServiceNow. Akshay called the API Clumio’s gateway to the world. Most organizations will spend their effort here. The recovery API already exists, and the harder job is building a detection pipeline that can hand it a reliable timestamp.
Agents Should Propose Recovery Plans for Human Approval
Akshay said some customers are moving toward agentic recovery, where a large language model (LLM) orchestrates the whole restore from a prompt. Many still use scripted recovery. I’m a little wary of handing the keys to an agent during an incident, although I can see the appeal. An agent can read logs, identify the affected objects, find a plausible timestamp, and call the recovery API faster than any person. The danger is a confident wrong choice. Granular in-place recovery merges good data with restored data, so a restore from the wrong point in time isn’t always obvious afterward. I’d want the agent to propose a recovery plan as code, have a human approve it, and then let the pipeline execute it. We already use this pattern for infrastructure changes with Terraform plan and apply. The agent writes the plan. A person signs off. The pipeline runs it.
Build Recovery the Way You Build Infrastructure
The lesson from Clumio’s customers extends beyond one product. If you define your cloud infrastructure in code, your protection policies and recovery procedures should live in code too. A console helps you learn a product and is great for the occasional investigation. It’s a poor place to recover millions of objects while your customers wait. Start by putting backup policies into the same Terraform modules that create your data stores. Then write recovery scripts for your three most likely failures and test them on a schedule. Once those scripts are reliable, an agent can call them, and a human or an LLM can run your recovery with some confidence. It’s a lot better than clicking through a wizard at 3 a.m. and hoping.
You can watch Commvault’s presentations on the Commvault Presents at Cloud Field Day 26 appearance page, and find more Cloud Field Day content at TechFieldDay.com.
