Se il file di configurazione di una macchina si rovina: dove sta la vecchia versione

Ogni macchina virtuale e ogni container ha un piccolo file di testo. Quanti core, quanta memoria, quale disco, quale rete: è tutto lì, scritto in una forma leggibile da un essere umano.

Cosa succede se quel file si rovina, dov'è la vecchia versione, e a cosa devi fare attenzione se lo modifichi a mano?

Prima la buona notizia: un file rovinato colpisce solo la sua macchina

Ogni macchina ha il proprio file separato. Un errore di battitura in uno non fa cadere il pannello, non ferma le altre macchine, non tocca il server.

Il sintomo di solito è questo: quella macchina smette di comparire nell'elenco, oppure si rifiuta di partire. Tutto il resto continua a funzionare normalmente. Sappilo prima di farti prendere dal panico, perché la prima impressione di solito è "il sistema si è rotto" e non è così.

Come si rovina

Modifica a mano. È la causa più frequente. Una virgola, una virgoletta, il nome di una chiave sbagliato.

Modifica mentre la macchina è accesa. Anche se il file non si rovina, succede qualcosa che non ti aspetti: la tua modifica ha effetto al prossimo avvio mentre tu la credi immediata. Oppure il sistema aggiorna da sé il file e sovrascrive quello che hai scritto.

Una scrittura interrotta a metà. Va via la corrente, il disco si riempie, il processo viene ucciso. Il file resta a metà.

Il terzo è il più insidioso e merita un titolo tutto suo.

Un file scritto a metà è peggio di nessun file

Se un file manca, è uno stato lampante. Un programma guarda, non lo trova, dice "non c'è" e prosegue con i valori predefiniti. Quello stato si gestisce facilmente.

Un file scritto a metà non è così. Sembra un file. Il programma verifica che esista, lo trova, si fida, e prova a lavorare con i dati incompleti che contiene. Il guaio non salta fuori al momento della lettura, ma dopo.

La soluzione è semplice e vale per ogni scrittura: non sovrascrivere il file direttamente. Scrivi prima con un nome temporaneo, poi spostalo al suo posto. Uno spostamento o avviene del tutto o non avviene; non esiste una via di mezzo. Così il contenuto del file è o quello vecchio o quello nuovo, mai la metà.

Se stai scrivendo uno script che tocca la configurazione di Proxmox, quell'unica abitudine vale più di tutto il resto del codice che scriverai.

La vecchia versione sta in due posti

Dentro il backup. Il backup di una macchina porta con sé non solo il disco ma anche il file di configurazione com'era in quel momento. Quando ripristini il backup torna anche la configurazione. La maggior parte pensa al backup come a soli dati e non si accorge di avere in mano una via di recupero.

Dentro l'istantanea. Quando prendi un'istantanea, la configurazione di quel momento viene scritta in una sezione con un nome dentro lo stesso file. Quindi il file porta dentro di sé una parte della propria storia.

Ma i due non si sostituiscono a vicenda, e la differenza conta: la registrazione dell'istantanea sta dentro lo stesso file. Se il file stesso viene distrutto, quella registrazione se ne va con lui. Un backup sta da un'altra parte. La vera via di recupero è il backup; un'istantanea è solo un punto a cui potresti voler tornare.

Se hai intenzione di modificare a mano

Ferma prima la macchina.

Fai una copia prima di modificare, e metti quella copia da un'altra parte. Il posto dove vive la configurazione è stato pensato per la configurazione; non lasciarci backup.

Dopo la modifica avvia la macchina e verifica che funzioni davvero. Non rimandare al prossimo riavvio dimenticandotene; una modifica lasciata a metà e dimenticata torna mesi dopo come un guasto che nessuno collega a nulla.

La regola generale: "file assente" e "file rovinato" sono stati distinti

La via di recupero di un programma di solito è scritta pensando allo stato "file assente", perché è il primo che viene in mente. Lo stato "il file c'è ma il contenuto è rovinato" non viene in mente.

Eppure il secondo è quello davvero pericoloso, proprio perché non è stato considerato. E i due appaiono diversi: un file mancante porta un contrassegno, un contenuto rovinato no.

Cosa fa Atlas

Atlas tiene alcuni piccoli file di impostazioni suoi, e qui ci sono varie cose da raccontare onestamente, perché tutte sono state trovate misurando.

Due file fratelli si comportavano in modo diverso. Uno si riparava da solo quando il suo file era corrotto: metteva da parte quello rovinato e ripartiva pulito. L'altro no: sollevava un errore e si fermava lì, cioè quella funzione diventava permanentemente inutilizzabile e l'utente non aveva modo di sistemarla dal prodotto.

La causa era esattamente la regola qui sopra: il ramo di recupero era scritto per lo stato "file assente". Un errore di contenuto rovinato non porta quel contrassegno, quindi il ramo non lo intercettava e l'errore scappava verso l'alto.

Le copie messe da parte non venivano mai ripulite. Ogni evento di corruzione lasciava un file permanente, senza un tetto al loro numero. Misurato su una macchina in esercizio: due stavano lì da mesi. È la stessa regola scritta altrove in questa wiki: tutto ciò che scrive deve avere un tetto.

Due messe da parte nello stesso istante producevano lo stesso nome e la seconda copia sovrascriveva la prima, così una versione rovinata spariva in silenzio.

Tutto è stato corretto, e alla messa da parte è stata imposta una regola: non solleva mai un errore, in nessun caso. La messa da parte è un passo di recupero, e un passo di recupero non deve diventare una nuova fonte di guasto. Quella frase sembra piccola, ma è quella che chiunque scriva codice di recupero dovrebbe appendere al muro.