Git已版本化Terraform配置，仍需保留tfstate旧版本吗？

先搞懂代码声明和tfstate的核心差异 #

• Terraform代码声明：是你写在.tf文件里的「期望状态」，比如定义VM的规格、存储桶的权限规则，这是你手动编写的、想要达到的资源目标，存在Git仓库里，是静态的意图描述。
• tfstate文件：是Terraform自动维护的「实际状态快照」，它记录了当前云环境里资源的真实状态——比如资源的ID、云服务商自动生成的属性值、资源间的依赖关系等。Terraform每次执行plan或apply时，都会用这个文件对比「期望」和「实际」，从而确定要执行的变更操作，它是动态的状态记录。

是否需要保留旧版本的tfstate？ #

你的思路在简单场景下是可行的：如果terraform apply全量失败，回滚Git代码到之前的可用版本再重新执行，确实能恢复资源状态。但在生产环境的复杂场景中，旧tfstate是不可替代的，比如：

• 部分apply成功的情况：比如执行apply时，前3个资源创建成功，第4个失败。此时Git代码是变更后的版本，但云资源已经有部分变更。如果没有旧tfstate，用回滚后的Git代码重新apply，Terraform会认为那些已创建的新资源是「未被管理的」，要么报错，要么试图删除它们，反而导致混乱。
• 资源属性自动变更：有些云资源的属性会被服务商自动修改（比如系统级的配额调整、自动更新的证书有效期），这些变更不会出现在Git代码里，但会被记录在tfstate中。如果没有旧tfstate，回滚代码后Terraform无法识别这些自动变更，可能出现属性冲突导致apply失败。
• 状态不一致的修复：当apply失败导致tfstate处于半更新的不一致状态时，直接恢复到旧的tfstate版本，能让Terraform快速回到一个可靠的基准线，避免手动排查和修复的繁琐工作。

Azure Blob Storage本身支持开启状态文件的版本控制，操作成本很低，从生产环境的稳定性和可恢复性考虑，强烈建议保留旧版本的tfstate。

内容的提问来源于stack exchange，提问作者hideous