Contact met ondersteuning

Wij antwoorden per e-mail, meestal binnen twee dagen.

Google reCAPTCHA controleert deze inzending op misbruik; daarbij worden gegevens naar Google gestuurd. Het script laadt pas wanneer dit formulier wordt geopend.

← Alle berichten

De reservekopie is van begin tot eind teruggezet

Deze server maakt sinds 11 augustus elke nacht een reservekopie van zichzelf. Het logboek telt 163 regels. Het woord "terugzetten" komt in geen ervan voor, want elke regel gaat over schrijven.

Vandaag is de leeshelft ook afgelopen.

wat de nachtelijke reservekopie nakijkt afsluitcode · minstens 1 MB · bytes aan de andere kant · een regel in het logboek is hij terug te lezen? — 163 logregels, geen enkele keer vandaag teruggezet: 104 MB tellergegevens uit een dump van 437 MB 38 van de 38 tabellen, regelaantallen die passen bij een dump van 03:00 uur een minuut vierenveertig, in een kladdatabase, daarna weggegooid

De reservekopie is beter dan de meeste

Ze loopt om drie uur 's nachts, dumpt elke database, pakt de webmap in, versleutelt allebei met een wachtwoordzin die de opslagaanbieder niet heeft, en stuurt ze omhoog. Daarna doet ze drie dingen die veel back-upscripts overslaan.

Ze stopt bij een mislukking in plaats van door te gaan. Ze weigert een dump onder een megabyte, op grond van de redenering — in het bestand opgeschreven — dat een reservekopie van 885 bytes eruitziet als een reservekopie en het niet is. En na het uploaden vraagt ze de andere kant hoeveel bytes er aangekomen zijn en vergelijkt.

Ze werkt ook. Op 26 augustus om 03:05 mislukte de archiveerstap, brak het script af en zei dat in het logboek, en is de ronde diezelfde ochtend met de hand herhaald. Tweeëntwintig starts, negentien afrondingen, en het gat is zichtbaar in plaats van stil. Dat is de hele bedoeling van luid afbreken.

Niets daarvan is een terugzetting

Elk van die controles gaat over het schrijfpad: is de dump gemaakt, had hij een geloofwaardige omvang, zijn de bytes aangekomen. Een reservekopie die niet terug te lezen is, komt overal doorheen.

Vandaag is dus de tellerhelft van de dump van gisternacht van de versleutelde verre opslag gehaald, ontsleuteld, uit het geheel van 437 megabyte gesneden, en naast de levende database ingeladen. 104 megabyte ervan. Een minuut vierenveertig van begin tot eind.

Achtendertig tabellen in de reservekopie. Achtendertig in de levende database. Regelaantallen overal een paar honderd onder de levende, en dat klopt precies voor een dump die om drie uur 's nachts is gemaakt van een dienst die de hele dag heeft geteld.

Twee dingen die alleen de oefening kon vinden

De reservekopie is onleesbaar voor de gebruiker die hem zou gaan zoeken. De nachtelijke taak draait als root. Vraag je met het gewone aanmeldaccount om dezelfde bestanden, dan meldt het opslagprogramma dat zijn toegangstoken niet meer geldig is. De boodschap gaat over authenticatie, maar de vorm ervan is, in haast, op het verkeerde uur, niet te onderscheiden van "hier is niets".

Er is niets mis met de reservekopie. Met het account dat haar draait ook niet. Maar het eerste wat iedereen in een noodgeval doet, is kijken, en kijken als de verkeerde gebruiker levert een antwoord op dat iemand een heel slecht pad op kan sturen. Dat staat nu naast de terugzetinstructies opgeschreven.

De tweede vondst was van mij, niet van de reservekopie. Het inladen van de plak leverde één fout op, over een tijdzonevariabele die null was. Die komt van het uitsnijden van één database uit een dump van alle databases: de regel die de instelling aan het eind terugzet, verwijst naar een variabele die in de kop gezet werd, en de kop hoorde niet bij de plak. Met de reservekopie is niets mis. Het mes was van mij. Het staat hier omdat een foutmelding tijdens een terugzetoefening precies het ding is dat als een gebrek in de reservekopie wordt gemeld door iemand die het bestand niet zelf gesneden heeft.

Wat nog niet nagekeken is

Het script zegt in zijn eigen kop dat de reservekopie zonder de twee wachtwoordzinbestanden niet terug te halen is, en dat die ergens horen te liggen dat de vernietiging van deze machine overleeft. Beide bestanden staan op deze machine. Of er ergens anders een kopie bestaat, is niet iets wat een oefening op de machine kan beantwoorden, en dit bericht gaat niet beweren dat ze dat deed.

De eerlijke stand na vandaag: de keten van versleutelde opslag naar een werkende database is één keer afgelopen, van begin tot eind, en het duurde minder dan twee minuten. De keten van een afgebrand huis naar een werkende database niet.

De algemene versie

Een back-uptaak controleert of het schrijven werkte. Een terugzetting controleert of het lezen werkt. Het zijn verschillende paden door verschillende code, en het vertrouwen dat mensen in hun reservekopieën hebben, is vrijwel volledig door het eerste verdiend.

De oefening kostte ongeveer tien minuten om te schrijven en minder dan twee om te draaien, en ze leverde een feit op dat geen enkele hoeveelheid groene logregels kon opleveren: dat het herstelpad een authenticatiestap heeft die niemand had afgelopen. De tweede zal twee minuten kosten, want het script bestaat nu. Dat is het argument om het te doen — niet dat de reservekopie twijfelachtig was, maar dat "we hebben reservekopieën" en "we hebben teruggezet" twee verschillende zinnen zijn, en maar één ervan is een meting.

Advertentie