Terraform State Recovery Checklist
A safety-focused Terraform state recovery checklist for preserving backups, confirming lineage, resolving locks, reconciling real resources and proving convergence after repair.
Choose the right control
Use this template when
- Terraform state is unavailable, locked incorrectly, incomplete or mapped to the wrong resource identity.
- A failed import, move or backend operation has left configuration, state and infrastructure inconsistent.
Use another workflow when
- A normal plan shows expected drift that can be handled through an ordinary reviewed change.
- The backend may be actively written by another operator or automation run.
Before you start
Collect these inputs before review so unchecked controls become evidence-backed decisions rather than placeholders.
How to use this template
Freeze applies and preserve the backend before attempting repair.
Use the least invasive state operation that restores truthful resource mapping.
Require a reviewed plan before any post-recovery apply.
# Terraform state recovery ## Containment - [ ] Automated and manual applies are paused - [ ] Workspace, backend, account and region are confirmed - [ ] Current incident owner and recovery approver are recorded - [ ] No lock is removed until the active writer is disproved ## Preserve evidence - [ ] Backend version, state serial and lineage are recorded - [ ] Current state is pulled to an access-controlled location - [ ] Backup hash and storage location are recorded - [ ] Configuration commit and provider lock file are preserved ## Reconcile identity - [ ] Real resource identifiers are verified through the provider - [ ] Configuration addresses are compared with state addresses - [ ] Missing, duplicate and stale bindings are listed explicitly - [ ] Dependencies and moved blocks are reviewed ## Recovery decision - [ ] Restore, import, move, remove or provider replacement is justified - [ ] The least invasive operation has been selected - [ ] Every command has an expected state change and rollback path - [ ] A second reviewer approves destructive or lineage-changing work ## Validation - [ ] State can be read through the normal backend path - [ ] A fresh plan contains no unexplained create, replace or destroy actions - [ ] Critical resource attributes match the live provider state - [ ] Backend locking and versioning protections are restored ## Return to service - [ ] Recovery evidence and final state version are retained - [ ] Automation resumes under a named owner - [ ] A final plan confirms convergence - [ ] Follow-up prevention work has an owner and due date
Evidence to retain
Review record
- Backend object version, serial and lineage identifiers
- State pull and immutable backup hashes
- Pre-repair and post-repair plans with resource identity checks
Definition of done
Acceptance criteria
- Only one approved writer can access the workspace during recovery.
- State entries map to verified real-resource identities without unintended create or destroy actions.
- A final reviewed plan shows the expected convergence and the backend protection is restored.
Apply it to a real change
A resource was imported into the wrong module address and a subsequent plan proposes both deletion and recreation. The recovery must preserve the live resource while correcting its state address.
- Pause automation and retain the current state version.
- Verify the provider resource ID before using a state move.
- Require a no-destroy plan and peer review before resuming applies.
Related KBY resources
Follow Terraform failures and fixes
A useful digest about twice a week with new error references, tools, integration notes and production lessons. No daily noise.