Notifications
Clear all
Topic starter
14/08/2026 6:33 pm
TL;DR: Terraform is built for desired-state provisioning, while Cloud Rewind captures actual deployed state for point-in-time recovery, according to Commvault. The distinction matters because code, state files, and Git history do not guarantee you can restore what was actually running when an outage or bad change hits.
NHIMG editorial — based on content published by Commvault: Terraform and Cloud Rewind differ in cloud recovery strategy
Questions worth separating out
Q: What breaks when Terraform is treated as a recovery tool?
A: Teams can redeploy desired configuration, but they may not be able to reconstruct the exact environment that was running before the incident.
Q: Why do cloud teams need both IaC and recovery tooling?
A: IaC makes provisioning repeatable, while recovery tooling preserves what was actually deployed.
Q: How do organisations know if their rollback process is actually working?
A: A real test is whether the team can restore a known-good environment after a change made outside Terraform.
Practitioner guidance
- Separate provisioning from recovery controls Use Terraform for desired-state management and a distinct recovery mechanism for live-state capture and point-in-time restore.
- Identify drift-prone change paths Map where console edits, scripts, break-glass accounts, and service identities can change cloud infrastructure outside IaC.
- Test restoration against real incidents Run recovery exercises for deleted resources, failed deployments, and out-of-band modifications.
What's in the full article
Commvault's full article covers the operational detail this post intentionally leaves for the source:
- How the vendor distinguishes desired-state rebuilds from actual-state rewind in practical cloud recovery workflows
- Examples of incident scenarios where Terraform state and Git history fail to restore the running environment
- The specific recovery use cases the source maps to point-in-time restoration after deletion, drift, or failed deployments
- The vendor's explanation of how Cloud Rewind fits alongside existing infrastructure-as-code processes
👉 Read Commvault's analysis of Terraform recovery limits and actual-state rewind →
Terraform vs recovery tools: why actual state still matters?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
14/08/2026 6:38 pm
Terraform drift has become a recoverability problem, not just a configuration problem. Once teams accept that infrastructure can change through consoles, scripts, and emergency fixes, they also accept that code history will not always tell the full story. That creates a control gap between change management and incident recovery. The practical conclusion is that cloud governance must distinguish declared state from actual state.
A question worth separating out:
Q: What is the difference between desired state and actual state in cloud operations?
A: Desired state is the configuration infrastructure-as-code says should exist. Actual state is the environment that is truly running at a given moment. Security and resilience teams need both views because incidents, drift, and manual intervention often affect actual state first.
👉 Read our full editorial: Terraform is not a recovery plan for cloud infrastructure incidents
