Terraform state: backends, locking y recuperación sin superstición

El state no es la infraestructura y tampoco es un caché descartable. Es el mapa que relaciona direcciones del código —por ejemplo, aws_s3_bucket.lab— con objetos remotos concretos. Si ese mapa se pierde, Terraform no olvida que el bucket existe: pierde la evidencia necesaria para saber que ese bucket es su bucket.

Terraform recomienda no guardar state en un sistema sin control de acceso y locking porque puede contener datos sensibles y porque dos escritores pueden producir pérdida de información. [1]

El invariante que conviene proteger

Antes de discutir S3, Consul o un servicio administrado, fija este invariante:

cada operación de escritura debe empezar desde la última versión confirmada del state y terminar publicando una nueva versión completa, o no publicar nada.

El backend decide dónde vive el snapshot y, cuando lo soporta, cómo se serializan las escrituras. El locking no vuelve correcta una configuración; evita que dos ejecuciones correctas por separado se destruyan mutuamente al escribir desde snapshots distintos. Terraform bloquea automáticamente las operaciones que pueden escribir state y se detiene si no logra adquirir el lock. [2]

Backend no significa solo “archivo remoto”

Un backend serio cubre cuatro preguntas:

1. Durabilidad: ¿hay versionado y recuperación ante borrado o escritura fallida?
2. Exclusión mutua: ¿el locking existe y qué identidad deja como evidencia?
3. Acceso: ¿quién puede leer state y quién puede escribirlo?
4. Trazabilidad: ¿puedes saber qué ejecución publicó cada versión?

Los backends determinan almacenamiento y pueden ofrecer locking; no todos lo hacen. En un error no recuperable al persistir state remoto, Terraform puede escribir un state local de emergencia para evitar pérdida de datos, y esa copia exige una reconciliación consciente. [3]

force-unlock no es un botón de desatascar

Un lock viejo puede aparecer por una ejecución interrumpida. Antes de forzarlo, responde con evidencia:

• ¿la ejecución dueña del lock terminó realmente?;
• ¿hay un apply todavía hablando con el provider?;
• ¿qué lock ID reportó el backend?;
• ¿cuál es el último serial y quién lo escribió?;
• ¿existe una copia recuperable antes de intervenir?

Forzar el unlock mientras otro proceso sigue vivo devuelve el problema original: múltiples escritores. Por eso el ID del lock funciona como nonce y no como decoración. La recuperación correcta no es “quitar el candado”; es demostrar que no queda un escritor legítimo y que el state vigente representa el último resultado confirmado.

Fallo parcial: objeto creado, state no publicado

El caso más incómodo ocurre cuando el provider creó el recurso, pero el backend no recibió el nuevo state. El siguiente plan puede proponer crearlo otra vez o chocar con un nombre ya existente. La salida segura es detener nuevos applies, conservar logs y state de emergencia, inspeccionar el objeto remoto y reconciliarlo mediante import o una restauración controlada. Nunca empieces editando JSON a mano.

La distinción importante es esta: la nube contiene el hecho; el state contiene la asociación. Recuperar consiste en volver a hacer coincidir ambas capas sin inventar una tercera historia.

Diseñar recuperación antes del incidente

El backend necesita una política de versionado, cifrado, acceso y retención coherente con el impacto del stack. Restringe lectura tanto como escritura: el state puede contener datos sensibles aunque ningún output esté marcado. Separa el rol que ejecuta planes del que administra el backend y evita que un job ordinario pueda borrar versiones o desactivar el lock.

Una restauración debe comenzar con el sistema detenido para nuevos escritores. Conserva state actual, versión candidata, lineage, serial y logs del último apply. Compara bindings con los objetos remotos y ensaya primero en una copia. Después de restaurar, ejecuta un plan refresh-only para observar la realidad y un plan normal para evaluar la intención; no apliques hasta explicar cada diferencia.

La métrica relevante no es “tenemos backups”. Es cuánto tardas en recuperar una asociación consistente y qué evidencia demuestra que no duplicaste, abandonaste ni reemplazaste recursos. Esa prueba convierte el backend de simple almacenamiento en una pieza operable.

Programa el ensayo con un stack descartable y mide desde la detección hasta el plan reconciliado. Las dudas encontradas durante el simulacro pertenecen al runbook, no a la memoria de quien lo ejecutó.

Repite el ejercicio cuando cambien backend, permisos o procedimiento de despliegue.

Contrato de lab

Practica sin credenciales con dos procesos que intenten modificar el mismo state local. El lab debe capturar:

• identidad y momento de adquisición del lock;
• rechazo observable del segundo escritor;
• lineage y serial antes y después;
• copia del state anterior;
• procedimiento documentado de recuperación;
• plan final sin cambios inesperados.

No fuerces el unlock durante la primera corrida. Primero demuestra qué protege. Después simula un lock huérfano, verifica que no queda proceso vivo y recién entonces ensaya la recuperación.

Conexiones dentro de la serie

• Antes: Terraform y OpenTofu para laboratorios reproducibles.
• Después: Módulos como contratos de composición.
• Lab relacionado: Terraform lab network, cuyo artefacto de guardrails debe existir antes de usar un backend real.