Wat de vzdump-modi van Proxmox echt garanderen

Proxmox biedt drie backupmodi aan in één keuzelijst, en daardoor zien ze eruit als drie snelheden van hetzelfde. Dat zijn ze niet. Ze verschillen in wat er met de draaiende gast gebeurt, en dus in waar het archief eigenlijk een kopie van is.

Eerst de korte versie, daarna de lange:

Het woord dat in die tabel al het werk doet is crash-consistent. Het betekent dat het archief eruitziet zoals de schijf eruitgezien zou hebben als iemand op dat moment de stekker eruit had getrokken. Een journaling-bestandssysteem komt daar overheen. Een database met een transactie onderweg misschien niet, en een applicatie die zijn staat over twee bestanden verdeelt, weet niet dat het ene bestand ouder is dan het andere.

snapshot betekent niet dat er iets bevroren wordt

snapshot is de standaard, en het is de enige modus die niets onderbreekt. Proxmox maakt een snapshot op opslagniveau en leest de backup daaruit, dus de gast schrijft de hele tijd door naar het levende volume.

Er is een manier om dat archief beter te maken: de QEMU-gastagent kan het bestandssysteem binnen de gast bevriezen op het moment dat de snapshot genomen wordt. Dat schrijft de wachtende writes weg en levert een archief op dat de gast zelf schoon vindt. Is de gastagent geïnstalleerd, draait hij, en antwoordt hij, dan gebeurt dat.

De valkuil zit in dat "is". Niets in het antwoord van de API vertelt je of dat bevriezen gebeurd is. De vzdump-taak geeft een taak-ID terug en, als hij klaar is, een status. Of qemu-guest-agent op het bevriesverzoek antwoordde, is een regel in het takenlogboek en geen veld dat je kunt teruglezen.

Dat is een beslispunt voor iedereen die hier automatisering bovenop bouwt, en het loont om daar bewust in te zijn. Toen wij het backuppad voor onze Proxmox-integratie bouwden, zijn we consistentie gaan vastleggen als wat er gebeurd is, nooit als wat er gevraagd is: een stop-backup leggen we vast als consistent, en zowel snapshot als suspend als crash-consistent, punt uit. Er bestaat een waarde voor "de gast is bevroren" in ons schema en de agent zendt hem nooit uit, want dat uitzenden zou betekenen dat we kennis claimen over een bevriezing die we niet uit de API kunnen nagaan.

Een archief dat iets slechter beschreven staat dan het is, kost je niets. Een archief dat beter beschreven staat dan het is, kost je precies die ene restore die ertoe doet.

suspend pauzeert de gast, en is geen tussenweg

suspend leest beter dan het zich gedraagt. Mensen gaan ervan uit dat het "snapshot, maar dan veiliger" is, een compromis tussen geen downtime en volledige downtime. Wat het werkelijk doet, is de gast pauzeren terwijl de data gelezen wordt.

Het geeft je dezelfde crash-consistentie als snapshot, want een machine pauzeren is niet hetzelfde als hem laten wegschrijven en tot rust laten komen. Je krijgt een onderbreking en geen sterkere belofte. Het geval waarin het wél zin heeft is smal: een opslagbackend dat helemaal niet kan snapshotten, waar de modus snapshot niets heeft om vanaf te lezen.

stop is de enige eerlijke garantie

stop sluit de gast af, maakt de backup, en start hem weer op. Het is de langste onderbreking en de enige modus waarin het archief onmiskenbaar een kopie is van een bestandssysteem waar niemand naar aan het schrijven was.

Voor een databaseserver die iemand om drie uur 's nachts onder druk gaat terugzetten, is dat geen zware prijs. Voor een vloot webservers is het een prijs die niemand elke nacht wil betalen. Beide zijn het juiste antwoord op een andere vraag, en precies daarom hoort de modus in het beleid thuis en niet in één globale instelling.

Eén implementatiedetail doet er hier toe. Omdat stop en suspend allebei een draaiende machine onderbreken, mag een ontbrekende of onbekende moduswaarde nooit stilzwijgend bij een van die twee uitkomen. In ons commandoschema reist de modus mee als het letterlijke Proxmox-woord (snapshot, suspend, stop) en niet als een eigen woordenlijst, en een lege waarde wordt snapshot. Een vertaaltabel tussen onze woorden en die van hen zou een verkeerde vertaling neerleggen op precies de plek waar een verkeerde vertaling de machine van een klant afsluit.

De parameters die bepalen of de taak überhaupt start

Vóór consistentie komt een saaiere vraag: gaat vzdump eigenlijk wel starten? Vier dingen op het verzoek bepalen dat, en drie ervan falen op een manier die lastig te lezen is.

De doelopslag moet backups accepteren. Proxmox-opslag heeft een content-lijst, en alleen opslag waarvan die lijst backup bevat kan een vzdump ontvangen. Dat is geen advies. Stuur de taak naar opslag die alleen schijfimages bewaart en Proxmox weigert hem met een melding als storage 'x' does not support vzdump backups. Correct, en betekenisloos voor de klant die op de knop drukte. Het loont om dat te controleren vóór je indient, zodat de weigering "deze opslag accepteert geen backups" kan zeggen.

Een verwant geval: opslag die in de lijst met clusterbronnen met status unknown verschijnt, is wel geconfigureerd maar antwoordt niet. Een NFS-share die eruit ligt, ziet er precies uit als een geldig doel, tot op het moment dat de taak faalt.

Compressie heeft een waarde die niet het woord is dat je verwacht.

Proxmox schrijft "geen compressie" als 0, niet als none. none sturen is het soort fout dat een stille weigering oplevert in plaats van een duidelijke, en het is de reden dat onze testsuite de exacte tekenreeks nagaat die de agent verlaat, in plaats van alleen te toetsen dat de aanroep slaagde.

Mailmeldingen staan standaard op luidruchtig, en op de verkeerde persoon. Zonder een expliciete mailnotification=failure mailt Proxmox na elke backup naar root@pam. Op een machine die vanaf een platform beheerd wordt, is dat post aan de provider over iets wat de klant deed.

Twee optionele velden zijn het kennen waard. notes-template hangt een notitie aan het archief, en Proxmox vult daarin zijn eigen plaatshouders in, zoals {{guestname}}. protected=1 markeert een archief als beschermd, en Proxmox weigert het daarna op te ruimen. Dat is precies het mechanisme dat je wilt voor de kopie die iemand maakt vóór een riskante wijziging, en precies de verkeerde standaardwaarde voor een nachtelijke taak.

Bewaartermijn is geen vzdump-parameter

Er staat geen bewaarinstelling op het backupverzoek. Opruimen wordt op de opslag ingesteld, in Proxmox, en het is de eigenaar van die opslag die bepaalt hoe lang kopieën blijven leven.

Dat heeft een ontwerpgevolg voor iedereen die hier iets bovenop bouwt: een paneel dat een veld "bewaar 7 kopieën" aanbiedt, grijpt óf in de opslagconfiguratie in, óf verwijdert zelf archieven. Wij kozen geen van beide, en zeggen dat ook, in plaats van iets anders te suggereren met een veld dat niets doet.

Een timeout is niet hetzelfde als een mislukking

Een vzdump van een grote machine kan elke redelijke verzoektimeout overleven. Gebeurt dat, dan is het belangrijk om te begrijpen dat er niets geannuleerd is: de taak loopt gewoon door op de hypervisor, en die maakt hem af of laat hem falen op zijn eigen tempo.

Een timeout is dus een uitspraak over jouw verbinding, niet over de backup. De run blijft open, het taak-ID is nog steeds geldig, en het eerlijke antwoord voor een interface is "loopt nog" en later bijwerken. Het alternatief, hem als mislukt markeren en iemand een tweede laten starten, zet twee vzdump-taken op dezelfde opslag voor dezelfde machine.

Terwijl hij loopt, is de echte voortgang beschikbaar: vzdump schrijft regels als 12% (1.2 GiB of 10.0 GiB) in zijn takenlogboek. Een voortgangsbalk die daaruit gevoed wordt is eerlijk. Een voortgangsbalk die uit een schatting gevoed wordt is een gok met een procentteken erachter.

Terugzetten, en waarom unique erop moet

De vraag naar de modus houdt op zodra het archief bestaat. Terugzetten heeft zijn eigen valkuil, en dat is er een op het netwerk.

Zet een archief terug in een nieuwe VM zonder om nieuwe identifiers te vragen, en de nieuwe machine erft de MAC-adressen van het origineel. Draait het origineel nog, dan staan er nu twee machines met hetzelfde MAC-adres op dezelfde bridge, en het symptoom is niet "de restore is mislukt" maar "het netwerk van de productiemachine doet raar". De vlag unique op de restore-aanroep is wat dat voorkomt, en op een platform dat terugzet naast een draaiend origineel is dat geen optie maar een voorwaarde.

Nog twee dingen zijn het weten waard vóór de eerste restore:

• storage betekent hier iets anders. Bij een backup is het de plek waar het archief heen gaat, en moet backup in de contentlijst staan. Bij een restore is het de plek waar de teruggezette schijven landen, en moet images erin staan. Dezelfde veldnaam, een andere eis.
• Alleen de schijven komen terug. Een teruggezette machine is een machine met schijven en hardware uit het archief. Adrestoewijzingen, firewallregels en welke automatisering er ook aan het origineel hing, leven in je eigen systemen en niet in het vzdump-bestand, en ze reizen niet mee.

Wat hier niet gemeten is

Alles hierboven over de vorm van de aanroepen komt uit het API-schema van Proxmox en uit het bouwen ertegen; de betekenis van de modi is die van Proxmox zelf, zoals beschreven in hun documentatie.

Wat we bewust niet zeggen, is hoeveel tijd elke modus kost. We hebben geen gemeten pauzeduur voor suspend en geen gemeten downtime voor stop: dat hangt af van de gast, de opslag en de hoeveelheid vuil geheugen, en een getal gemeten op één machine zou geciteerd worden als een algemeen getal. Die moeten van je eigen hardware komen.

Nog twee gaten die het benoemen waard zijn. Alles hier gaat over QEMU-gasten; backups van containers hebben hun eigen regels rond mountpoints en bind mounts, en die hebben we niet gemeten. En er zit in dit alles geen incrementeel pad: vzdump naar gewone opslag schrijft elke keer een volledig archief. Incrementele backups zijn waar Proxmox Backup Server voor is, en dat is andere software met een andere set beloftes.

Dit kwam voort uit het bouwen van het Proxmox-backuppad voor Provibr, een server-managementpaneel voor hostingproviders, waar een backup die beter beschreven staat dan hij is de ergst denkbare bug zou zijn. De installatienotities voor de hypervisorkant staan in de Proxmox-documentatie, en de pagina over de Proxmox-integratie beschrijft wat de agent kan.