Si el archivo de configuración de una máquina se rompe: dónde está la versión anterior

Cada máquina virtual y cada contenedor tiene un pequeño archivo de texto. Cuántos núcleos, cuánta memoria, qué disco, qué red: todo está ahí, escrito de forma que un humano puede leer.

¿Qué pasa si ese archivo se rompe, dónde está la versión anterior, y a qué debes prestar atención si lo editas a mano?

Primero la buena noticia: un archivo roto solo afecta a su propia máquina

Cada máquina tiene su propio archivo. Una errata en uno no tira abajo el panel, no detiene las otras máquinas, no afecta al servidor.

El síntoma suele ser este: esa máquina deja de aparecer en la lista, o se niega a arrancar. Todo lo demás sigue funcionando con normalidad. Sábelo antes de entrar en pánico, porque la primera impresión suele ser "el sistema se rompió" y no es así.

Cómo se rompe

Editar a mano. Es la causa más frecuente. Una coma, una comilla, un nombre de clave mal escrito.

Editar mientras la máquina está encendida. Aunque el archivo no se rompa, pasa algo que no esperas: tu cambio surte efecto en el siguiente arranque mientras tú crees que fue inmediato. O el sistema actualiza el archivo por su cuenta y sobrescribe lo que escribiste.

Una escritura interrumpida a mitad. Se va la luz, se llena el disco, se mata el proceso. El archivo queda a medias.

El tercero es el más insidioso y merece su propio título.

Un archivo escrito a medias es peor que ningún archivo

Si un archivo falta, es un estado evidente. Un programa mira, no lo encuentra, dice "no está" y sigue con los valores por defecto. Ese estado se maneja con facilidad.

Un archivo escrito a medias no es así. Parece un archivo. El programa comprueba que exista, lo encuentra, confía en él, e intenta trabajar con los datos incompletos que contiene. El problema no aparece al leer, sino después.

La solución es simple y vale para toda escritura: no sobrescribas el archivo directamente. Escribe primero con un nombre temporal y luego muévelo a su sitio. Un movimiento ocurre entero o no ocurre; no hay término medio. Así el contenido del archivo es o el viejo o el nuevo, nunca la mitad.

Si estás escribiendo un script que toca la configuración de Proxmox, ese único hábito vale más que todo el resto del código que escribas.

La versión anterior está en dos sitios

Dentro de la copia de seguridad. La copia de una máquina lleva no solo el disco sino el archivo de configuración tal como estaba en ese momento. Cuando restauras la copia, la configuración vuelve también. La mayoría piensa en una copia solo como datos y nunca se da cuenta de que tiene en la mano un camino de recuperación.

Dentro de la instantánea. Cuando tomas una instantánea, la configuración de ese momento se escribe en una sección con nombre del mismo archivo. Es decir, el archivo lleva dentro parte de su propia historia.

Pero estos dos no se sustituyen entre sí, y la diferencia importa: el registro de la instantánea está dentro del mismo archivo. Si el archivo se destruye, ese registro se va con él. Una copia está en otro sitio. El camino real de recuperación es la copia; una instantánea es solo un punto al que quizá quieras volver.

Si vas a editar a mano

Detén la máquina primero.

Haz una copia antes de editar, y pon esa copia en otro sitio. El lugar donde vive la configuración se diseñó para configuración; no dejes copias ahí.

Después del cambio, arranca la máquina y comprueba que de verdad funciona. No lo dejes para el siguiente reinicio y lo olvides; una edición a medias olvidada vuelve meses después como una avería que nadie relaciona con nada.

La regla general: "archivo ausente" y "archivo roto" son estados distintos

El camino de recuperación de un programa suele escribirse pensando en el estado "archivo ausente", porque es el primero que viene a la cabeza. El estado "el archivo está pero su contenido está roto" no viene a la cabeza.

Y sin embargo el segundo es el de verdad peligroso, justo porque no se pensó en él. Y los dos se ven distintos: un archivo ausente lleva una marca, un contenido roto no.

Qué hace Atlas

Atlas mantiene unos pocos archivos de ajustes propios, y aquí hay varias cosas que contar con honestidad, porque todas se encontraron midiendo.

Dos archivos hermanos se comportaban distinto. Uno se reparaba solo cuando su archivo estaba corrupto: apartaba el roto y empezaba limpio. El otro no: lanzaba un error y se quedaba ahí, es decir, esa función quedaba permanentemente inutilizable y el usuario no tenía forma de arreglarla desde el producto.

La causa era exactamente la regla de arriba: la rama de recuperación estaba escrita para el estado "archivo ausente". Un error de contenido roto no lleva esa marca, así que la rama no lo atrapaba y el error escapaba hacia arriba.

Las copias apartadas nunca se limpiaban. Cada suceso de corrupción dejaba un archivo permanente, sin tope de cuántos. Medido en una máquina en servicio: dos llevaban ahí meses. Es la misma regla escrita en otras partes de esta wiki: todo lo que escribe necesita un techo.

Dos apartados en el mismo instante producían el mismo nombre y la segunda copia sobrescribía la primera, con lo que una versión rota desaparecía en silencio.

Todo se corrigió, y al propio paso de apartar se le puso una regla: nunca lanza un error, bajo ninguna circunstancia. Apartar es un paso de recuperación, y un paso de recuperación no debe convertirse en una nueva fuente de fallo. Esa frase parece pequeña, pero es la que debería colgar en la pared cualquiera que escriba código de recuperación.