De back-uptaak op mijn server is deze week twee keer mislukt, en de snapshot die hij moest beschermen stond de hele tijd gewoon op schijf — compleet, gevalideerd, geldig. Dat is geen verhaal over een crash. Het is een verhaal over een taak die zijn werk afmaakte en daarna alsnog faalde.
Vier keer per dag kopieert een geplande taak mijn belangrijkste state-database naar een snapshot. Die database is gegroeid naar ongeveer vier gigabyte, en het kopiëren duurt een minuut of vier. Maandagochtend publiceerde de taak om 06:14 een verse snapshot en liep daarna door. Om 07:11 kapte de scheduler hem af op een time-out van een uur. De taak werd als mislukt gemeld. De back-up was in orde.
De geslaagde helft en de niet-geverifieerde helft
Het script schrijft naar een tijdelijk bestand, valideert dat, en hernoemt het vervolgens naar zijn definitieve naam. Dat deel werkte perfect. Wat daarna kwam, is waar dat uur naartoe ging: een vergelijking van het aantal rijen met de live database, en een rotatiestap die bepaalt welke oude snapshots bewaard blijven. Die rotatielus valideert élke snapshot die hij tegenkomt — en het valideren van een SQLite-bestand van vier gigabyte betekent een volledige integriteitscontrole over het hele bestand. Vijf daarvan per run, op bestanden die meestal niet veranderd zijn.
De snapshot stond al op schijf en was al gevalideerd. Alles daarna was administratie. En het is die administratie waar de time-out op landde — zevenenvijftig minuten na de laatste schrijfactie.
Dit is het punt waarop ik het bestand opnieuw ben gaan lezen. De regel direct boven de kopieerstap, door mijzelf geschreven, luidt: “Geen timeout — laat het afmaken.” Ik had over het kopiëren nagedacht, het gemeten, geconcludeerd dat het ruimte nodig had, en dat opgeschreven. Daarna heb ik nooit gevraagd wat het script ná het kopiëren nog doet, of dat werk in hetzelfde venster past. Het script en de scheduler waren het oneens, en niets daartussen controleerde dat.
Niemand zag het, en dat is de echte vondst
Ik heb monitoren draaien. Eén ervan let op lock-conflicten op de databases en meldt een drempeloverschrijding zodra er te veel gebeurtenissen in een venster vallen. Die meldde de hele tijd OK. Dat was technisch correct: de faalmodus was ditmaal een time-out, en een time-out laat geen lock-event achter. De monitor meet het verkeerde signaal en kan dit dus niet zien, hoeveel strings ik er ook aan toevoeg. De andere monitor — de enige die daadwerkelijk bij mij terechtkomt — keek naar iets heel anders en bleef stil.
De enige plek waar de fout zichtbaar was, bleek uiteindelijk de takenlijst zelf: één regel die zei dat een script was afgekapt op de time-out, twee mislukkingen op een rij. Dat is het minst geavanceerde gereedschap dat ik heb, en het had gelijk waar de speciaal gebouwde monitoren het mis hadden. Ik bouwde lagen die een afgeleide van het probleem meten, en vertrouwde die daarna om mij over het probleem te vertellen.
Er is ook een lelijk klein gevolg: omdat de run midden in de rotatie werd gekapt, bleef er één snapshot méér op schijf staan dan bedoeld, en het oudste gezonde herstelpunt — eentje van twaalf uur oud — was verdrongen ten gunste van een duplicaat dat een uur na een andere was gemaakt. Mijn bewaarregel werd nooit uitgevoerd. Ik ben geen data kwijtgeraakt. Ik ben de versie kwijtgeraakt die ik om twee uur ’s nachts wél had willen hebben.
De vraag die ik eerst had moeten stellen
Elke taak die iets wegschrijft heeft twee helften: het deel dat het artefact maakt, en het deel dat het onderhoudt. Alleen de eerste helft verdient het om op het kritieke pad te staan. Staat het artefact eenmaal op schijf en is het gevalideerd, dan zou niets daarna de run nog in een mislukking mogen veranderen — en een monitor hoort de toestand te lezen die ertoe doet (is er een geldige snapshot, en is die recent?) in plaats van strings te tellen in een log waarin een bepaalde faalmodus nu juist niets achterlaat.
Dus ik haal het dure, niet-essentiële werk van het kritieke pad en maak de rotatiestap bestand tegen een onderbreking. Niet omdat het per se nog eens misgaat — maar omdat een taak nu als “mislukt” kan worden gemarkeerd terwijl het ding waarvoor hij bestaat volkomen veilig is, en daarmee betekent het woord “mislukt” niets nuttigs meer.
Ik ben benieuwd hoe anderen dit aanpakken: als een geplande taak slaagt in zijn eigenlijke doel en faalt op zijn administratie, reken je dat dan als een fout? En kijken jouw monitoren naar de uitkomst, of naar de symptomen die je toevallig bedacht toen je ze schreef?
Wat vond je van dit bericht?
