Een backup die nooit is teruggezet is geen backup

Iedereen is het met de titel eens. Bijna niemands dashboard laat het zien.

De reden is geen luiheid. Het is dat drie werkelijk verschillende soorten bewijs door dezelfde pijp binnenkomen, in kolommen naast elkaar belanden en uiteindelijk als één groen vinkje getekend worden. Zodra ze één vinkje zijn, leent de sterkste bewering uit de groep stilletjes de geloofwaardigheid van de goedkoopste, en leest een klant "beschermd" waar er in werkelijkheid alleen een taak met exitcode nul is geëindigd.

We hebben een ronde besteed aan het uit elkaar trekken van die drie in ons eigen schema, en een tweede ronde aan het meten van een echte Proxmox Backup Server om erachter te komen welke ervan hij ons werkelijk kan geven. Dit is waar we op uitkwamen.

Drie bewijzen, en ze zijn niet uitwisselbaar

Het eerste is het goedkoopste en het is het bewijs dat elk product laat zien. Het is precies waard wat het zegt: er is een proces afgelopen. De garanties achter elke vzdump-modus gaan over wat dat proces wel en niet kon beloven over de toestand van de gast, en geen van die garanties overleeft daarna een aanraking met een beschadigde chunkopslag.

Het tweede is echt bewijs en het is makkelijk om er te veel in te lezen. Daarover hieronder meer.

Het derde is het enige dat de vraag beantwoordt die een klant werkelijk stelt, en het is het enige waarvoor je iets moet bouwen in plaats van iets te lezen. Die scheefheid is de reden dat het meestal ontbreekt.

Wat een groene verificatie werkelijk beweert

Proxmox Backup Server kan een snapshot verifiëren: hij leest de chunks opnieuw en toetst ze aan het manifest. Is dat gebeurd, dan draagt de snapshotlijst een verification-object met een toestand erin.

Dat is werkelijk nuttig om te weten, en het is smaller dan het aanvoelt. Het zegt dat de bytes op die datastore de bytes zijn die er geschreven zijn. Het zegt niet dat de machine zal opstarten. Het zegt niet dat de applicatie erin zal starten. Het zegt niet dat de database consistent was op het moment van de snapshot. En is de backup aan de clientkant versleuteld, dan zegt het niet dat iemand de sleutel nog heeft: een integriteitscontrole op cijfertekst slaagt prima als de sleutel weg is.

De toestand staat daarom in een eigen kolom in ons schema, en in de code is vastgelegd dat hij bij bewijs twee hoort en nooit vermengd mag worden met "herstel bewezen". Bewijs drie krijgt zijn eigen tabel op de dag dat iemand het bouwt. Een vierde waarde aan een bestaand enum toevoegen was een halve dag werk geweest en een blijvende bron van verwarring.

Een ontbrekend veld is geen mislukking

Onze kolom heeft drie waarden: ok, mislukt en onbekend. De middelste is niet de interessante.

Gemeten tegen een draaiende Proxmox Backup Server 4.2 met echte snapshots erop: een snapshot die nooit door een verificatietaak is gegaan heeft simpelweg geen verification-sleutel. Het veld is afwezig. Dat is iets anders dan een verificatie die gedraaid en mislukt is, en die twee samenvouwen kost je naar beide kanten. Zet je de standaard op ok, dan wordt elke ongecontroleerde snapshot een gecontroleerde. Zet je hem op mislukt, dan staat elke historische snapshot in je database opeens in brand. De derde waarde bestaat om het enige ware te zeggen: er is niets bekend.

Een gewone Proxmox-opslag vult de kolom helemaal nooit in, want zijn inhoudslijst kent geen begrip van verificatie. Dat is geen gat in onze integratie. Dat is het antwoord.

Nog één eerlijk detail, want het is het soort detail dat wordt afgerond. Het verification-object dat wij gemeten hebben draagt een toestand en een taaknummer, en geen tijdstip. Het moment "geverifieerd op" dat wij vastleggen is dus het moment waarop wij die toestand voor het eerst zagen, en dat is een andere vraag dan "wanneer heeft de opslag dit geverifieerd". Het beantwoordt "sinds wanneer weten wij dit". Legt een toekomstige versie de echte tijd bloot, dan hoort de kolom die te gaan dragen en hoort het commentaar dat dit allemaal uitlegt te verdwijnen.

Leeg moet leeg betekenen

Hier is de scherpste regel van het hele gebied, en hij heeft niets met verificatie te maken.

Elk systeem dat periodiek herstelpunten opsomt, leidt uiteindelijk iets af uit de afwezigheid van een snapshot: hij stond hier vorige week, hij staat er nu niet, dus hij is opgeruimd of verwijderd. Die gevolgtrekking is dragend, en zij is alleen geldig als een geslaagde lege opsomming werkelijk leeg is.

We hebben daarom gemeten wat een backupserver werkelijk antwoordt als een opsomming misgaat, want "een lege reeks" en "een fout die eruitziet als een lege reeks" moeten uit elkaar te houden zijn. Vier gevallen, allemaal gemeten tegen diezelfde draaiende 4.2-installatie:

• een lege namespace antwoordt 200 met een lege reeks;
• een namespace die niet bestaat antwoordt 400 met een niet-gevonden-fout en niet met een lege lijst;
• een datastore die het token niet mag inzien antwoordt 403;
• een ongeldig token antwoordt 401.

Drie van die vier moeten specifieke fouten worden in plaats van resultaten. Mag ook maar één daarvan je afstemmingslogica bereiken als "de opsomming is gelukt en er staat niets", dan markeert één tikfout in de naam van een namespace de hele backuphistorie van een klant als verdwenen. Het faalbeeld is geen storing. Het is een scherm dat stilletjes ophoudt te vermelden dat er backups zijn.

Dit is dezelfde soort val als een hypervisor die 200 antwoordt voordat het werk begonnen is: de antwoordcode is prima, en het is niet het antwoord op je vraag.

De inloggegevens horen niets kapot te kunnen maken

De nuttigste beveiligingsbeslissing hier is ook de saaiste.

Het token dat een klant voor een backupdoel aanmaakt moet snapshots en de status van de datastore kunnen lezen. Het hoeft niets te verwijderen, te vergeten, op te ruimen of te verifiëren. Dat zijn losse handelingen die horen bij wie de opslag bezit, op zijn eigen schema, met zijn eigen identiteit.

We hebben de integratie gebouwd zonder ook maar één schrijvend commando, waardoor de bewering structureel is in plaats van een streven, en daarna hebben we het van de andere kant gecontroleerd: met een token dat alleen inzagerechten heeft, antwoordt een verwijdering op een snapshot 403. Dat is de vorm om op te mikken. Een alleen-lezenintegratie waarvan de inloggegevens kunnen opruimen is een alleen-lezenintegratie tot precies het moment waarop iemand een lus schrijft die er één naast zit.

Er is een keerzijde die hostingaanbieders in de andere richting fout doen. Verwijdert je platform een server, dan is de bewaarvraag een beslissing die de klant moet nemen en geen standaardwaarde die je code kiest. De laatst overgebleven kopie van iemands gegevens weghalen als bijvangst van het opruimen van een rij is iets wat echte bedrijven is overkomen.

Wat een hersteltest moet zijn, als je er een bouwt

Bewijs drie is waar het werk zit, en het is de moeite waard de randvoorwaarden op te schrijven voordat je de code schrijft, want de meeste ervan gaan over het niet veroorzaken van een incident met je eigen test.

Een hersteltest heeft een afgezonderde plek nodig om naar terug te zetten: een netwerk zonder route naar productie, tijdelijke nummers, tijdelijke adressen, tijdelijke hardwareadressen. Nooit het productieadres, en nooit het hardwareadres uit productie, want een dubbel adres op een levend netwerk is een storing die je zelf veroorzaakte terwijl je controleerde of je van een storing kon herstellen. Hij heeft strikte quota nodig, want de grootste machine van een vloot terugzetten in een testpool is een capaciteitsgebeurtenis. Hij heeft een deadline en een gegarandeerde opruiming nodig, aangezien de machine soms niet opkomt en iets hem dan toch moet weghalen. En hij moet geen meldingen versturen, want een monitoringalarm van een testkopie die zich voordoet als het echte systeem maakt iemand wakker.

Hij heeft ook een uitgesproken voltooiingsbeleid nodig, en daar verdient het geheel zijn naam. Opgestart is één niveau. Bereikbaar is een ander. Een gastagent die antwoordt is er weer een. Bestandssystemen aangekoppeld is er weer een. Een applicatie die een door de klant bepaalde gezondheidscontrole beantwoordt is het niveau dat overeenkomt met wat een klant bedoelt met "herstelbaar". Kies er één, leg naast het resultaat vast welke je koos, en laat een lager niveau nooit getoond worden met het etiket van een hoger niveau.

Pas dan mag een server "herstel bewezen" laten zien, en dan hoort dat de datum te dragen, het precieze herstelpunt, de omgeving waarin het draaide, de controles die slaagden en hoe lang het bewijs bewaard blijft. Alles daaronder maakt van die woorden versiering.

Wat we zouden opschrijven

1. 01Noem de drie bewijzen apart in je schema, voordat je ze alle drie hebt. Bij ons zijn het losse kolommen en een tabel die nog niet bestaat, en dat leest makkelijker dan één kolom met een verontschuldigend commentaar.
2. 02Sla "onbekend" op als een echte waarde. Elke standaardwaarde die niet "onbekend" is, is een leugen over minstens één van je rijen.
3. 03Laat een lege opsomming bewijzen dat hij leeg is, en maak van elk ander antwoord een aparte fout voordat het iets bereikt dat afstemt.
4. 04Geef de integratie inloggegevens die niet kunnen verwijderen, en toets daarna van buitenaf dat ze het niet kunnen.
5. 05Schrijf op wat "herstel" voor jou zou moeten betekenen, op welk voltooiingsniveau, voordat iemand er een groen vinkje naast zet.

Onze eigen stand, ronduit gezegd: de eerste twee bewijzen zijn gebouwd en gemeten, en we hebben geen hersteltest. De backupfunctie zit achter een schakelaar en is niet te koop. Dat is het verschil tussen een plan en een bewering, en het is hetzelfde verschil waar dit hele artikel over gaat.

De integratie achter deze metingen is gebouwd voor Provibr. De verwante timingvraag, wat er gebeurt als een backup langer duurt dan de deadline die je hem gaf, staat in een timeout is geen stopknop; de containerkant van backups op Proxmox staat in VM of container op Proxmox.