Blog ·
Wat er niet in een backup zit
Dezelfde ontbrekende optie betekent ja bij een virtuele machine en nee bij een container. Zo maten we de backupdekking van Proxmox in plaats van te beloven.
Door Provibr
Vraag een beheerpaneel of een machine geback-upt is en je krijgt meestal ja. De interessante vraag is smaller en veel lastiger: welke delen ervan zitten in het archief en welke niet. Een container met een bind mount naar een map op de host heeft data die geen enkele vzdump ooit aanraakt, en een paneel dat over die configuratie "geback-upt" zegt is niet optimistisch, het doet een belofte namens de software van iemand anders.
Dus we zijn gestopt met beloven en begonnen met meten. Elke backup en elk terugzetpunt draagt nu een waarneming van hoe de gast er op dat moment uitzag, en het paneel leidt de dekking af uit die waarneming en niet uit het feit dat een backup slaagde.
Dezelfde afwezigheid, twee tegengestelde betekenissen
De reden dat dit gemeten moet worden en niet beredeneerd, is één regel gedrag van Proxmox die voor de twee gastsoorten precies de andere kant op gaat.
Bij een container zit een mountpoint alleen in het archief als er backup=1 bij staat. De documentatie is expliciet: wil je een mountpoint in de backup, zet dan de backupoptie ervoor aan. Afwezig betekent nee.
Bij een virtuele machine zit een schijf ín het archief tenzij er backup=0 bij staat. Dat staat niet met zoveel woorden in de handleiding; het staat in de functie die vzdump zijn lijst geeft, waar de waarde gelezen wordt als de backupvlag van de schijf met standaard één. Afwezig betekent ja.
| Configregel | In het archief? |
|---|---|
rootfs: local-lvm:vm-101-disk-0,size=8G | ja, altijd; de rootfs kent het backupveld niet eens |
mp0: local-lvm:vm-101-disk-1,mp=/data,backup=1 | ja |
mp0: local-lvm:vm-101-disk-1,mp=/data | nee |
mp0: /srv/data,mp=/data (bind mount) | nee; de inhoud van bind mounts gaat niet mee |
mp0: /dev/sdb1,mp=/disk (device mount) | nee; hetzelfde geldt voor device mounts |
scsi0: local-lvm:vm-100-disk-0,size=32G | ja |
scsi1: local-lvm:vm-100-disk-1,backup=0 | nee |
ide2: local:iso/debian.iso,media=cdrom | niet van toepassing |
efidisk0: … mét bios: ovmf | ja |
efidisk0: … zónder bios: ovmf | nee |
tpmstate0: … | ja |
scsi2: /dev/sdb (passthrough) | ja |
unused0: local-lvm:vm-100-disk-4 | nee |
virtiofs0: dataset-a | nee |
De twee vetgedrukte regels zijn dezelfde afwezigheid. Vouw ze samen tot één zin en één van je twee schermen liegt, en geen van beide geeft een fout.
De bron lezen, niet de intuïtie
Drie van die regels vielen anders uit dan het plan voor dit werk aannam, en alle drie zijn beslecht door Proxmox te lezen in plaats van te redeneren.
Van een passthrough-schijf werd aangenomen dat het hostdata is die achterblijft, naar analogie met de device mount van een container. Dat klopt niet. De functie die de backuplijst opbouwt kijkt nergens naar het pad, en de voorbereidingsstap maakt van een volid zonder storage erachter een blockdevice en neemt hem mee. Dat verkeerd hebben in de veilig ogende richting zou klanten vertellen dat er data buiten hun archief valt die er wél in zit, wat onschuldig klinkt tot je merkt dat het bij élke restore een erkenning afdwingt en mensen zo leert door erkenningen heen te klikken.
Losgekoppelde schijven en gedeelde hostmappen ontbraken domweg in het plan. Een unusedN is echte klantdata die op de storage staat zonder bus eraan, en vzdump logt dat hij hem overslaat. Een virtiofsN is een map van de host en nooit een volume, en daarmee de tegenhanger van een bind mount bij een virtuele machine. Allebei zijn het echte gaten in de dekking en allebei zouden ze als volledig zijn geteld.
De voorvoegsels van de schijfsleutels en hun aantallen komen uit diezelfde plek: vier IDE-plaatsen, zes SATA, eenendertig SCSI, zestien virtio, één EFI-schijf, één TPM-staat, tweehonderdzesenvijftig ongebruikte plaatsen, tien virtiofs. Een sleutel buiten die bereiken is voor Proxmox geen schijf, dus hij mag hier ook niet stil een schijf worden. En virtiofs wordt vóór virtio getoetst, want virtiofs0 begint met virtio: andersom zou een gedeelde hostmap als schijf gelezen worden en als geback-upt gemeld.
Onbekend heet nooit volledig
De woorden op het scherm bij een ongemeten gast zijn "niet vastgesteld", voluit: wat een backup bevat is niet vastgesteld. Nooit "volledig", nooit "niet in de backup". Er zijn drie manieren om daar te belanden en alle drie zijn echt: de gast is een soort die de agent niet kan lezen, de agent is ouder dan de release die configs leest, of de agent probeerde het en kon er niet bij.
Dat laatste geval is de reden dat de waarneming een expliciete vlag draagt die zegt dat de config gelezen is. Zonder die vlag is een lege lijst mountpoints niet te onderscheiden van een container zonder extra mounts, behalve dat de tweede niet bestaat: er is altijd een rootfs. Een agent die niet kon kijken zou anders gelezen worden als een gast met niets buiten het archief, en dat is precies de faalvorm waar dit werk voor bestaat.
Twee regels duwen dezelfde kant op. Een containerconfig die wél gelezen is maar geen rootfs bevat is onbekend en niet volledig, want we hebben kennelijk iets gelezen dat geen containerconfig was. En een configuratie van een virtuele machine waarin niets staat waar een dekkingsvraag bij hoort, niets of alleen cd-roms, is om dezelfde reden onbekend: volledig betekent dat alles erin zit, en dat over nul dingen zeggen is een bewering zonder meting eronder. De prijs is bekend en aanvaard, en dat is dat een werkelijk schijfloze machine nu als niet-vastgesteld leest en bij een restore om een erkenning vraagt. Dat is de kant waar een fout niets kost.
Het oordeel is ook met opzet geordend: aantoonbaar buiten wint van niet gemeten. Een container met één bind mount en één onleesbare regel is gedeeltelijk en niet onbekend, want het deel dat ertoe doet is bewezen. De onleesbare regel verdwijnt niet; hij houdt zijn eigen rij met zijn eigen woord.
Niet van toepassing is niet hetzelfde als uitgesloten
Een cd-romstation krijgt een eigen dekkingsstand, en het onderscheid is geen muggenzifterij maar de handeling die eruit volgt.
Uitgesloten betekent dat er klantdata buiten het archief staat en dat er een vinkje in Proxmox is dat dat verandert. Een cd-rom draagt geen data van deze machine: het is een image uit een bibliotheek, of de cloud-init-schijf die bij elke start opnieuw gemaakt wordt, en Proxmox slaat hem over voordat hij iets anders beoordeelt. Zou een cd-rom uitgesloten heten, dan was elke machine met een ISO in zijn station gedeeltelijk en vroeg elke restore een erkenning over een station waar niets op staat. Mensen zouden leren dat de erkenning niets betekent, en dan betekent hij niets.
De rij staat wél in de tabel, met zijn eigen woord. Een rij die ontbreekt roept de vraag op óf we gekeken hebben, en dat is precies de dubbelzinnigheid die de leesvlag wegneemt.
De erkenning is fail-closed
Een archief terugzetten waarvan de dekking iets anders is dan een gemeten "volledig" vraagt om een vinkje dat noemt wat er buiten viel. Ook bij onbekend, en dat is het bewuste deel: een oud terugzetpunt, of een archief dat iemand anders maakte, kan best hostdata missen, en het vinkje is waar de klant leert dat zelf na te gaan. Alleen een gemeten volledig slaat het over, want dan valt er werkelijk niets te erkennen.
Dezelfde zin bewaakt twee deuren, de handler en de functie erachter, want een scherm is geen grens. En de bevestigknop wordt niet uitgeschakeld terwijl het paneel openstaat: een uitgeschakeld element kan geen focus houden, dus een dialoog die zijn eigen opener uitschakelt kan de focus bij het sluiten niet teruggeven en een toetsenbordgebruiker belandt op de body. Een bezig-stand en dimmen doen hetzelfde werk zonder dat te breken.
Wat er buiten het archief viel wordt daarnaast als gebeurtenis op de restore geschreven, op waarschuwingsniveau, met de mountpoints in zijn gegevens. Een restore die stilletjes slaagde terwijl er drie mappen achterbleven hoort een maand later vindbaar te zijn door iemand die er niet bij was.
Wat wij zouden opschrijven
- Meet de dekking, leid haar niet af. "De backup is gelukt" en "je data zit in de backup" zijn twee uitspraken over twee verschillende dingen.
- Toets of een standaardwaarde aan beide kanten van je abstractie hetzelfde is. Hier betekent één ontbrekende optie ja voor de ene gastsoort en nee voor de andere, en een gedeelde zin is op precies één scherm onwaar zonder ergens een fout.
- Lees de code die de lijst werkelijk opbouwt, niet alleen de handleiding. Drie van onze regels waren fout tot we dat deden, en één ervan was fout in de richting die veilig voelt.
- Geef "niet gemeten" een eigen woord en laat het nooit samenvallen met ja of nee.
- Geef "hier is geen vraag" ook een eigen woord. Een stand die een betekenisloze bevestiging afdwingt leert mensen bevestigingen te negeren.
- Zet de waarneming en het oordeel op verschillende plekken. De agent meldt wat hij zag; één functie beslist wat dat betekent, met tests ernaast en zonder dat de melder volledigheid kán beweren.
Voor de duidelijkheid over wat dit is: klantbackups zitten achter een uitrolschakelaar die standaard uit staat, dus niets hiervan is vandaag te koop, en de regels zijn geverifieerd tegen de documentatie en de broncode van Proxmox en niet tegen een eigen draaiende hypervisor. Drie dingen zijn onbewezen of bewust buiten bereik. De dekking van een afzonderlijk terugzetpunt wordt geërfd van de run die hem maakte in plaats van uit het archief zelf gelezen. Schijven van virtuele machines met backup=0 zijn zichtbaar in deze tabel en nergens anders in het product. En een werkelijk schijfloze machine leest als niet-vastgesteld, wat een prijs is die we boven het alternatief verkozen.
Uit het backupwerk aan Provibr. Waarom een ongeteste restore geen backup is staat in een backup die nooit is teruggezet, en wat de drie vzdump-modi werkelijk garanderen staat in vzdump-modi in Proxmox: wat ze garanderen.