Смена backend: чем migrate-state отличается от reconfigure

В backend изменили путь или bucket, и init остановился с просьбой указать -migrate-state либо -reconfigure. Эти флаги не являются двумя равнозначными способами убрать сообщение. Первый пытается перенести существующий state, второй принимает новую конфигурацию подключения без такого переноса.

Ошибка выбора часто проявляется следующим plan: в новом пустом хранилище нет прежних привязок, и почти все ресурсы предлагаются к созданию. Инфраструктура при этом никуда не исчезла. Инструмент просто смотрит на другое состояние.

Сначала установим источник и назначение

До изменения выясните текущий backend, workspace, путь state и владельцев CI-запусков. Сохраните защищённую резервную копию штатным способом хранилища. Остановите конкурирующие записи на время согласованного переноса: наличие двух доступных копий не означает, что обе можно продолжать изменять.

Служебная конфигурация в .terraform запоминает параметры инициализированного backend. Если удалить этот каталог до разбирательства, можно потерять удобный контекст старого подключения. Не выдавайте удаление локального кэша за миграцию данных.

Локальная демонстрация переноса

В новом учебном каталоге создайте main.tf только с terraform_data. Terraform требует 1.4+ для этого типа; OpenTofu тоже его поддерживает. Выполните init и подтверждённый apply выбранного продукта, чтобы получить локальный state в стандартном месте.

resource "terraform_data" "demo" {
  input = "preserve-this-binding"
}

output "demo_id" {
  value = terraform_data.demo.id
}

Запишите demo_id и затем добавьте в тот же main.tf блок backend. Сам resource и output оставьте прежними.

terraform {
  backend "local" {
    path = "state/managed.tfstate"
  }
}

Используя прежний инициализированный рабочий каталог, выполните один из наборов команд и прочитайте запрос подтверждения переноса.

terraform init -migrate-state
terraform state list
terraform output demo_id
terraform plan

tofu init -migrate-state
tofu state list
tofu output demo_id
tofu plan

Ожидается сохранение привязки terraform_data.demo и прежнего ID, а обычный plan не должен предлагать новый экземпляр. Для этой демонстрации используется default workspace. У локального backend размещение других workspaces настраивается отдельно; не переносите вывод одного workspace на все остальные.

Когда выбирают reconfigure

Reconfigure нужно, если state уже находится в правильном месте и вы хотите заново настроить локальное подключение к нему без копирования старого состояния. Например, новый рабочий каталог подключают к существующему backend или меняется способ доступа, а путь к данным остаётся согласованным.

Если вместо переноса из первого каталога выбрать reconfigure с новым пустым path, файл сам не получит прежние объекты. Поэтому до последующего apply обязательно проверьте state list и plan. Массовое предложение create после изменения backend — повод остановиться и проверить путь, а не подтверждать создание копий инфраструктуры.

Почему force-copy не стоит добавлять по умолчанию

В Terraform init и OpenTofu init -force-copy подавляет вопросы миграции и подразумевает migrate-state. Он полезен только после явного выбора источника и назначения. Автоматическое согласие в незнакомом окружении убирает точку, где можно заметить неверный backend.

Для удалённого хранилища отдельно проверьте существование назначения, права, шифрование, версионирование и поддержку lock. Сам init не создаёт произвольный S3 bucket только потому, что его имя появилось в backend. Credentials не стоит записывать прямо в HCL или коммитить с backend-config.

Завершённая миграция подтверждается не сообщением init, а чтением нужных адресов и ID из нового backend, корректным plan и переключением всех разрешённых писателей на новое место. Старую копию сохраняют как контролируемую резервную, исключая параллельное продолжение работы с ней.

Ещё по теме

• Sensitive скрывает вывод, но что остаётся в state Terraform и OpenTofu
• Terraform и OpenTofu: что делать с блокировкой state после оборванного запуска

Продолжить изучение

Хотите управлять инфраструктурой через код и понимать последствия изменений? Plan, state, модули и работа с существующими ресурсами — темы программы «Terraform и OpenTofu: инфраструктура как код».