Unlike most of my stories, this one is basically all for me and storing a note to my future self. But I hope that this note helps you as well when you encounter the dreaded:
Pre-existing state was found while migrating the previous “s3” backend to the newly configured “s3” backend.
This is a classic Terraform show stopper and, if you answer it wrong, will completely ruin your day.
THE ANSWER IS NO. If you answer YES it blows away your remote state store.
Ok, now that we’ve got that out of the way, here’s why this is confusing and how to keep yourself from accidentally blowing away your state store.
Here’s the full text of the error, just in case you search for this error by a slightly different phrase in the error message:
Do you want to copy existing state to the new backend?
Pre-existing state was found while migrating the previous "s3" backend to the newly configured "s3" backend. An existing non-empty state already exists in the new backend. The two states have been saved to temporary files that will be removed after responding to this query.
Previous (type "s3"): /tmp/terraform878210618/1-s3.tfstate
New (type "s3"): /tmp/terraform878210618/2-s3.tfstate
Do you want to overwrite the state in the new backend with the previous state?
Enter "yes" to copy and "no" to start with the existing state in the newly
configured "s3" backend.Enter a value: no
What does this even mean?
It seems that somehow, Terraform gets confused about which state it is looking at is the latest one. I’ve seen this happen when trying to plan and apply while switching between our AWS accounts for different environments.
We store our state in a central S3 bucket and then use that state to do cross-account applies of infrastructure. However, it seems that Terraform is copying the state locally and then not knowing which state is actually correct.
So it asks you which “s3” state to use — the one really long cryptic path or the other really long cryptic path. Answer wrong and your state file is gone. And that means you’re either importing state all over again…or hopefully just reverting back to the last known good file in S3.
Always version in S3
The easiest way to combat this is with good foresight. For your S3 bucket holding your state, TURN ON VERSIONING. This has saved me more than once when I had to do a quick rollback after selecting the wrong answer to this question.
It’s as simple as turning on the deleted versions, downloading the version before the current version, and re-uploading that. Just like that, state restored and your day is saved.
Other community tricks
This issue, it seems, has been occurring for quite some time — at least since 2017 based on a quick Google search.
In this GitHub issue, apparentlymart suggests using terraform init -reconfigure which will work like answering “no” the original question.
There is another GitHub issue where users discuss the potential root causes, mostly overlapping conflicting local state.
StackOverflow has a question and comment thread by Todd showcasing this same outcome — and disaster when answering incorrectly. He does figure it out that “no” is the correct answer.
And if you want even more backstory about this issue, 2ndWatch has a long blog post written by Ryan Kennedy about the technical underpinnings of what’s happening.
Photo by Julia Joppien on Unsplash
