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.
Editorial analysis by NHI Mgmt Group, based on content published by Commvault: “Terraform Builds Your Cloud. Commvault® Cloud Rewind™ Recovers It.”.
Key questions
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 code, state files, and Git history fall short for cloud recovery?
A: They capture configuration intent and version history, not a point-in-time snapshot of what was running.
Q: How should teams design recovery when cloud drift is possible?
A: They should treat drift as a normal operating condition and maintain a separate restoration path for actual deployed state.
Practitioner guidance
- Separate provisioning from recovery controls Document Terraform as the desired-state engine and designate a distinct recovery process for restoring live cloud environments after incidents.
- Test restoration from actual deployed state Run incident drills that restore a known-good cloud snapshot rather than replaying code and state files, so teams validate true recovery.
- Inventory out-of-band change paths Identify console edits, manual interventions, and drift sources that can bypass Terraform so recovery assumptions do not depend on incomplete state.
Bottom line: Terraform is built to manage desired state, but desired state alone does not equal recoverable state.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
14/08/2026 6:38 pm
Recovery requires an operational state record, not just configuration code. Terraform proves that cloud change can be repeatable, but repeatability is not the same as recoverability. When a production incident unfolds, teams need a record of what was actually deployed, not only what was intended. The practitioner lesson is to separate infrastructure provisioning from infrastructure restoration in governance and tooling.
A question worth separating out:
Q: When should organisations rely on point-in-time recovery instead of infrastructure-as-code rollback?
A: Use point-in-time recovery when the incident changed live resources, introduced manual edits, or deleted infrastructure that Terraform no longer accurately represents. Infrastructure-as-code rollback is useful for controlled change reversal, but it is not a substitute for restoring the deployed environment that existed before the failure.
👉 Read our full editorial: Terraform is not a recovery plan for cloud infrastructure incidents