Als het configuratiebestand van een machine kapotgaat: waar de oude versie staat

Elke virtuele machine en elke container heeft een klein tekstbestand. Hoeveel kernen, hoeveel geheugen, welke schijf, welk netwerk: het staat er allemaal in, in een vorm die een mens kan lezen.

Wat gebeurt er als dat bestand kapotgaat, waar staat de oude versie, en waar moet u op letten als u het met de hand bewerkt?

Eerst het goede nieuws: een kapot bestand raakt alleen zijn eigen machine

Elke machine heeft zijn eigen bestand. Een typefout in het ene haalt het paneel niet onderuit, stopt de andere machines niet, raakt de server niet.

Het verschijnsel is meestal dit: die machine verschijnt niet meer in de lijst, of weigert te starten. Al het andere blijft normaal werken. Weet dat voordat u in paniek raakt, want de eerste indruk is meestal "het systeem is stuk", en dat is het niet.

Hoe het kapotgaat

Bewerken met de hand. Dit is de meest voorkomende oorzaak. Een komma, een aanhalingsteken, een verkeerd gespelde sleutelnaam.

Bewerken terwijl de machine draait. Zelfs als het bestand niet kapotgaat, gebeurt er iets onverwachts: uw wijziging gaat pas bij de volgende start in terwijl u denkt dat die meteen werkte. Of het systeem werkt het bestand zelf bij en overschrijft wat u schreef.

Een halverwege afgebroken schrijfactie. De stroom valt uit, de schijf loopt vol, het proces wordt afgebroken. Het bestand blijft halfaf.

Die derde is de sluwste en verdient een eigen kop.

Een half geschreven bestand is erger dan helemaal geen bestand

Ontbreekt een bestand, dan is dat een duidelijke toestand. Een programma kijkt, vindt het niet, zegt "niet aanwezig" en gaat verder met standaardwaarden. Die toestand is makkelijk af te handelen.

Een half geschreven bestand is anders. Het ziet eruit als een bestand. Het programma controleert of het bestaat, vindt het, vertrouwt het, en probeert te werken met de onvolledige gegevens erin. De ellende komt niet bij het lezen aan het licht, maar daarna.

De oplossing is eenvoudig en geldt voor elke schrijfactie: overschrijf het bestand niet rechtstreeks. Schrijf eerst onder een tijdelijke naam en verplaats het daarna op zijn plek. Een verplaatsing gebeurt helemaal of helemaal niet; er is geen tussentoestand. Zo is de inhoud van het bestand ofwel de oude ofwel de nieuwe, nooit de helft.

Schrijft u een script dat aan Proxmox-configuratie komt, dan is die ene gewoonte meer waard dan alle andere code die u schrijft.

De oude versie staat op twee plekken

In de back-up. De back-up van een machine draagt niet alleen de schijf maar ook het configuratiebestand zoals het op dat moment was. Zet u de back-up terug, dan komt de configuratie ook terug. De meeste mensen zien een back-up alleen als gegevens en beseffen nooit dat ze een herstelweg in handen hebben.

In de momentopname. Maakt u een momentopname, dan wordt de configuratie van dat moment in een benoemd deel van hetzelfde bestand geschreven. Het bestand draagt dus een stukje van zijn eigen geschiedenis in zich.

Maar die twee vervangen elkaar niet, en het verschil telt: de vastlegging van de momentopname staat binnen hetzelfde bestand. Wordt het bestand zelf vernietigd, dan gaat die vastlegging mee. Een back-up staat ergens anders. De echte herstelweg is de back-up; een momentopname is slechts een punt waar u misschien naar terug wilt.

Als u met de hand gaat bewerken

Stop eerst de machine.

Maak een kopie voordat u bewerkt, en zet die kopie ergens anders. De plek waar de configuratie woont is ontworpen voor configuratie; laat daar geen back-ups achter.

Start de machine na de wijziging en zie dat die echt werkt. Stel het niet uit tot de volgende herstart en vergeet het niet; een vergeten halfafgemaakte bewerking komt maanden later terug als een storing die niemand ergens aan koppelt.

De algemene regel: "bestand ontbreekt" en "bestand kapot" zijn aparte toestanden

De herstelweg van een programma wordt meestal geschreven met de toestand "bestand ontbreekt" in gedachten, want dat is wat als eerste opkomt. De toestand "het bestand is er maar de inhoud is kapot" komt niet op.

Toch is de tweede de echt gevaarlijke, juist omdat eraan niet gedacht is. En de twee zien er verschillend uit: een ontbrekend bestand draagt een kenmerk, kapotte inhoud niet.

Wat Atlas doet

Atlas houdt een paar eigen kleine instellingenbestanden bij, en hier valt het een en ander eerlijk te vertellen, want alles is door meten gevonden.

Twee zusterbestanden gedroegen zich verschillend. Het ene herstelde zichzelf wanneer zijn bestand beschadigd was: het zette het kapotte apart en begon schoon. Het andere niet: het wierp een fout en bleef daarbij, wat betekende dat die functie blijvend onbruikbaar werd zonder dat de gebruiker het via het product kon herstellen.

De oorzaak was precies de regel hierboven: de hersteltak was geschreven voor de toestand "bestand ontbreekt". Een fout door kapotte inhoud draagt dat kenmerk niet, dus ving de tak hem niet op en ontsnapte de fout naar boven.

De apart gezette kopieën werden nooit opgeruimd. Elke beschadigingsgebeurtenis liet een blijvend bestand achter, zonder bovengrens. Op een draaiende machine gemeten: twee ervan stonden er al maanden. Dat is dezelfde regel als elders in deze wiki: alles wat schrijft heeft een plafond nodig.

Twee keer apart zetten op hetzelfde moment leverde dezelfde naam op en de tweede kopie overschreef de eerste, waardoor een kapotte versie stilletjes verdween.

Alles is hersteld, en aan het apart zetten zelf is één regel opgelegd: het werpt onder geen enkele omstandigheid een fout. Apart zetten is een herstelstap, en een herstelstap mag geen nieuwe bron van storing worden. Die zin lijkt klein, maar het is de zin die iedereen die herstelcode schrijft aan de muur zou moeten hangen.