Skip to main content
Terraform state is Terraform’s “memory” of the real-world resources it manages. This guide walks through a simple scenario—five virtual machines—showing what happens if Terraform loses access to its state file, and how to recover safely. Imagine a Terraform configuration that defines five virtual machines. You run terraform apply, and the state file is stored remotely (for example, in an S3 bucket). Configuration, state, and cloud resources are all in sync.
A person is writing on a transparent board, creating a diagram with numbered squares in one section and arrows pointing to a box labeled "S3".
Now you have five VMs running in the cloud and a state file that records those resources.
The image shows a person standing in front of a blackboard, drawing a flowchart with boxes and arrows labeled with numbers, "S3," and "CLOUD."
If the state file is deleted, corrupted, or otherwise inaccessible, Terraform no longer knows about the existing infrastructure. With the same configuration files, running terraform plan or terraform apply makes Terraform behave as if it’s starting from scratch.
A person is standing in front of a transparent board with a diagram drawn in blue and orange marker, illustrating a process from a group of numbered boxes to the cloud, bypassing a labeled section marked "S3."
Because the state is missing, Terraform will query the cloud for resources but—finding no local state entries—it will plan to create the five VMs described in your configuration. This results in Terraform attempting to provision new resources in addition to the ones already running in your cloud, since it can’t tell they already exist. In short: losing the Terraform state causes Terraform to try to re-create resources it believes are absent unless you recover the state or re-associate existing resources with your configuration. Recovery options
  1. Restore the state file
  • If you use a remote backend (for example, an Amazon S3 bucket), check for backups or enablement of versioning. Restoring a prior terraform.tfstate is often the fastest way to recover.
  • Restore the backup/version of terraform.tfstate into the remote backend so Terraform can pick it up.
The image shows a person standing in front of a transparent board with a diagram illustrating a "terraform plan," featuring boxes, arrows, and cloud-related elements.
Enable remote backend versioning and periodic backups (for example, S3 versioning or GCS object versioning). Store copies of terraform.tfstate so state restoration is straightforward when needed.
  1. Re-import existing resources into state If you cannot restore a prior state file, re-associate real resources with your Terraform configuration using terraform import (official docs: https://developer.hashicorp.com/terraform/cli/commands/import). The workflow:
  • Ensure your Terraform configuration contains resource blocks that match the resources you want to manage. Create or update resource blocks first so each real resource has a corresponding address.
  • Use terraform import to map each existing cloud resource into the matching resource block address.
Example: import a single EC2 instance into a resource named aws_instance.web: 
terraform import aws_instance.web i-0123456789abcdef0
If the resources were created with count or for_each, import using the indexed address: 
terraform import 'aws_instance.web[0]' i-0123456789abcdef0
After importing every resource, run: 
terraform plan
Terraform will list imported resources in state and display differences between your configuration and the actual resource attributes. Adjust either the configuration or the real resources so they match.
Import is a per-resource operation and can be time-consuming for large fleets. Always run terraform plan after imports and review planned changes before terraform apply to avoid unintended modifications or replacements.
Tips for successful imports
  • Add resource blocks to your configuration before importing so you have deterministic addresses to import into.
  • Import each resource (or each indexed element) individually; there’s no bulk-import native to Terraform core.
  • Use terraform state list and terraform state show after importing to inspect entries and verify attributes.
  • When possible, prefer reconciling configuration to actual resource attributes rather than changing resources to match configuration.
Why a config-driven recovery is best
  • A configuration-first approach (define resources in code, then import real resources into those blocks) restores state while preserving a version-controlled source of truth. This avoids adhoc fixes and helps teams understand intended infrastructure.
Recovery options at a glance
Recovery methodWhen to useNotes
Restore state fileYou have backups or backend versioningFastest, simplest; restores exact prior state
Re-import resourcesNo backups availableSafe but manual; ensure config matches real resources
Recreate resourcesWhen resources are disposable or cheapRisky for production—can cause duplicates or lost data
Recap
  • Losing Terraform state causes Terraform to treat existing resources as absent and plan to recreate them.
  • Recovery approaches:
    • Restore the state file from backend versioning or backups (recommended if available).
    • Re-import existing resources into properly defined resource blocks using terraform import.
  • Best practices to avoid or mitigate state loss:
    • Use remote backends (S3, GCS, Terraform Cloud).
    • Enable object/version backups.
    • Store Terraform configuration in source control.
    • Periodically back up state snapshots and test recovery procedures.
Links and references

Watch Video