Backups: niet of het misgaat, maar wanneer

Eigenlijk zit er een ongemakkelijke kant aan alles zelf draaien. Zolang je spullen bij Google of Apple staan, is er ergens een team dat ’s nachts voor je back-upt zonder dat je het merkt. Doe je het zelf, dan is dat team… jij. En de dag dat de schijf in mijn Pi ermee ophoudt — niet of, maar wanneer — is er niemand anders die mijn mail, mijn foto’s, mijn wachtwoorden en al die zorgvuldig opgebouwde configuratie terugzet. Dat besef is precies de keerzijde van soevereiniteit: je hebt de controle, dus je hebt ook de verantwoordelijkheid.

Tijd dus om eerlijk op te schrijven hoe ik dat geregeld heb. Niet omdat het af is — een backup is nooit af — maar omdat het opschrijven me dwingt om de hiaten te zien.

De vraag achter de vraag

Lang dacht ik bij “backup” aan één ding: een kopie. Gewoon: een tweede schijf, en klaar. Maar gaandeweg merkte ik dat die ene kopie drie heel verschillende dingen moet kunnen.

Hij moet je redden als je per ongeluk zelf iets weggooit. Hij moet je redden als de hardware stuk gaat. En hij moet je redden als je hele huis er niet meer is — brand, diefstal, een blikseminslag die de halve meterkast meeneemt. Dat zijn drie verschillende rampen, en één kopie op één plek dekt er hooguit één van.

Daar komt de bekende vuistregel uit backup-land vandaan: 3-2-1. Drie kopieën van je data, op twee verschillende soorten opslag, waarvan één buitenshuis. Niet als een wet, maar als een manier om te controleren of je echt gedekt bent. Of dat je jezelf iets wijsmaakt.

Laag één: dichtbij, voor de dagelijkse ongelukken

De eerste laag draait gewoon thuis. Elke nacht maakt mijn Pi een kopie van alles wat ertoe doet — de Nextcloud-data, de muziek, de configuratie van alle diensten — naar een aparte schijf.

Daarvoor gebruik ik Borg, en dat doet twee dingen slim. Het eerste: het bewaart niet elke nacht een complete nieuwe kopie, maar alleen wat er veranderd is. Een nachtelijke backup van honderden gigabytes kost daardoor maar een paar minuten en een paar megabytes, want de rest stond er gisteren al. Incrementeel heet dat. Het tweede: elke backup is tóch een compleet terugzetbaar moment. Ik kan teruggaan naar “gisteren”, naar “vorige week dinsdag”, naar een willekeurige nacht — en steeds krijg ik de hele boel terug zoals die er toen bij stond, niet een halve.

Dat is precies wat je wilt voor het meest voorkomende ongeluk: niet de brand, maar het per ongeluk overschrijven of weggooien van iets dat je een week later pas mist.

Laag twee: ver weg, voor de echte ramp

Een backup die naast het origineel staat, is geen backup tegen brand. Als de Pi en de backup-schijf in dezelfde woning liggen, neemt één ongeluk ze allebei mee.

Dus gaat diezelfde Borg-backup óók, elke ochtend, naar een opslagplek ver hier vandaan — een gehuurde schijfruimte bij Hetzner op hun locatie in Finland. Versleuteld, zodat wat daar staat alleen voor mij leesbaar is, en via een beveiligde verbinding zodat er onderweg niemand meekijkt. Het mooie van diezelfde Borg-aanpak: ook hier reist alleen het verschil mee, dus die dagelijkse rit over het internet is licht.

Nu pas klopt het plaatje een beetje. Het origineel op de Pi. Een kopie op de tweede schijf thuis. Een kopie in Finland. Drie kopieën, twee plekken, één ver weg. De vuistregel klopt als een bus.

En toen ontdekte ik een hiaat

Hier zou het verhaal kunnen stoppen, en een halfjaar lang dacht ik ook dat het rond was. Tot ik dit voorjaar samen met Claude eens van een afstand naar mijn eigen setup keek, en er iets aan het licht kwam dat geen enkele schijf-backup dekt.

Mijn bestanden waren veilig, maar mijn beslissingen niet.

Een voorbeeld maakt het duidelijk. Ergens in mijn configuratie stond een instelling op een bepaalde waarde. Waarom? Dat wist ik niet meer. Ik had het maanden eerder zo gezet, vast met een goede reden, maar die reden was nergens opgeschreven. Mijn backup kon de configuratie perfect terugzetten — maar niet uitleggen waaróm hij was zoals hij was. En een instelling die je niet begrijpt, durf je ook niet te veranderen.

Ik bleek dat onbewust te compenseren met een rommelige gewoonte: voordat ik iets aanpaste, maakte ik snel een kopie van het bestand met een datum erachter. Net zo’n kopietje, en nog eentje. Op een gegeven moment lagen er tientallen van die kopieën te slingeren in mijn mappen — allemaal stille getuigen van “hier heb ik ooit iets veranderd”, maar zonder een woord over wát of waaróm. Het was een soort geheugen, maar dan van het slechtste soort: veel ruis, geen verhaal.

Laag drie: geheugen voor verandering

De oplossing bleek een techniek waar ik via programmeurs en ontwikkelaars wel eens van had gehoord, maar nooit op mijn eigen infrastructuur had losgelaten: Git. De ‘meeste’ van die mensen kennen en gebruiken het als de motor onder GitHub. Maar in de kern doet het iets simpels en handigs: het bewaart niet alleen wat er veranderde, maar laat je bij elke verandering een briefje achterlaten over het waarom.

Dat klinkt als een detail, maar het verschil is enorm. Want in plaats van twintig naamloze kopietjes heb ik nu één nette tijdlijn: op deze en die dag heb ik dit aangepast, en dit was de reden. Wil ik terug naar hoe het gisteren was, dan kan dat. Maar belangrijker: ik kan teruglézen waaróm iets is zoals het is. De rommelige kopietjes konden allemaal weg.

En er kwam een tweede gewoonte bij die me bijna nog meer waard is. Voor de echt belangrijke keuzes — waarom dít model en niet dat, waarom déze opzet — laat ik Claude nu steeds een kort logboek bijhouden van wat ‘we’ gedaan hebben. Geen technisch document, maar gewoon het besluit, met de redenering eronder. Zodat ik over een jaar niet naar mijn eigen setup staar met de vraag “waarom had ik dat in codesnaam ook weer gedaan?!”.

Dit is de laag die in geen enkele 3-2-1-regel staat, en die ik toch niet meer zou willen missen. Een gewone backup beschermt je tegen het verliezen van je spullen. Deze beschermt je tegen het verliezen van je begrip van je spullen. En eerlijk: dat tweede is veel belangrijker dan ik dacht.

Wat ik ervan geleerd heb

Een backup is geen ding dat je een keer aanzet en dan vergeet. Het is een gewoonte, en gewoontes slijten — ik betrap mezelf er nog steeds op dat ik na een drukke week vergeten ben iets vast te leggen. Daar ben ik niet streng over naar mezelf, wel oplettend.

Wat voor mij telt is dit: ik kan vannacht de stekker uit mijn Pi trekken, hem in de fik steken (ga ik niet doen!) en morgen begin ik niet bij nul. Mijn data heb ik zo terug, zelfs van twee plekken. En misschien net zo belangrijk — ik weet straks nog steeds waaróm alles staat zoals het staat. Dat tweede is het stukje dat ik dit jaar pas echt geleerd heb, en het is precies het stukje dat het verschil maakt tussen een kopie en een geheugen.

Want het is niet of het een keer misgaat, maar wanneer. En dan wil je niet alleen je bestanden terug, maar ook de besluiten van jezelf van een halfjaar geleden, toen je nog wist hoe het zat.

–JB

Gebruikte onderdelen: BorgBackup voor de versleutelde, incrementele backups (lokaal + offsite naar Hetzner), Git voor het versiebeheer van alle configuratie, en een logboek met de hand voor de beslissingen eronder. Allemaal open en zelf in beheer — lokaal als het kan, online als het moet.