Deze week ontdekte ik dat één van mijn eigen veiligheidsregels al zeven updates lang uitgeschakeld staat — en dat ik die schakelaar zelf heb geschreven. Niet letterlijk, maar het komt erop neer: de controle die mijn systeem netjes moest houden, vuurde op een voorwaarde die op mijn machine altijd waar is. Dus heeft hij nooit gedraaid.
De opzet: vóór elke update maakt mijn agent-stack een kleine “quick snapshot” van de kwetsbare delen — config, secrets, auth, cron-jobs, kanban-status. Een minimale herstelset voor het geval een update iets sloopt. De code die dat doet is expliciet over retentie: bewaar precies één pre-update snapshot.
Op schijf stonden er zeven. Teruggaand tot begin augustus. Samen ongeveer 4,75 GB.
De bescherming die niets beschermde
Het opruimstapje heeft één uitzondering, en als je hem leest klinkt hij volkomen redelijk: als een database niet kon worden meegenomen, of is overgeslagen vanwege de grootte, verwijder dan de oudere snapshot niet — die is misschien de enige herstelbare kopie. Dat is een echte zorg en een goed instinct.
Alleen: mijn hoofddatabase is altíjd groter dan de limiet. Niet soms. Altijd. Dus de vlag “overgeslagen vanwege grootte” staat altijd aan, het opruimen wordt altijd overgeslagen, en “bewaar één” is stilletjes “bewaar alles” geworden. De regel die me in een uitzonderingsgeval moest redden, schakelde zichzelf uit in het normale geval.
Wat me overtuigde dat mijn meting klopte, was een controle in dezelfde map: daar staan mijn database-snapshots, en díe roteren wél netjes — precies drie bestanden, één per rotatie-interval. Mijn telmethode was dus in orde. Het gat zat echt in de controle, niet in mijn instrument.
Het gaat nooit alleen om schijfruimte
4,75 GB is niets op een schijf met 60 GB vrij. Op ruimte alleen had ik het laten liggen. Twee dingen deden me stoppen:
Eén: die mappen reizen mee. Ze zitten in mijn dagelijkse back-upset, dus elke nacht worden ze opnieuw gekopieerd en opgeslagen. De rommel blijft niet lokaal.
Twee: er zitten secrets in. Zeven kopieën van mijn omgevingsbestand en mijn auth-bestand, met credentials erin, die bij elke back-upcyclus meeliftten. Dat is geen opruimdetail meer.
En het was de derde retentie-bevinding in drie dagen, allemaal dezelfde familie: een drempel die weggooit wat hij moest bewaren, een snapshot-rotatie die door zijn eigen timeout werd gekild, en nu een “bewaar één”-regel die accumuleert. Stuk voor stuk een bescherming die in zijn tegendeel was geklapt.
Wat ik verander
Niet “even een opruimscript erbij”. Dat verstopt de fout en laat de slechte controle staan. De eerlijke fix is smal: hang het opruimen alleen op écht mislukte opnames, niet op bestanden die bewust zijn overgeslagen door een groottelimiet die ik zelf heb gekozen. Een bewuste overslag is geen onvolledige snapshot. En daarna verifiëren — na de volgende update moet er één snapshot-map op die plank staan, geen acht.
Als je iets lang genoeg draait, ga je op een gegeven moment niet meer vragen “werkt mijn automatisering?”, maar iets anders: welke van mijn veiligheidsregels staat op dit moment uit zonder dat iemand het weet? Want het faalpatroon is stil. Niets geeft een fout. Niets alarmeert. De map groeit gewoon door, zeven updates lang.
Ik ben oprecht benieuwd: heb jij ooit een eigen veiligheidsmechanisme gevonden dat door zijn eigen uitzondering effectief uitgeschakeld was? En wat was er nodig voordat je het doorhad? Laat het weten in de comments — ik lees alles.
Wat vond je van dit bericht?
