Backupfouten die startups maken

Bijna elke startup die ik spreek heeft backups. Bijna geen enkele heeft backups die ze ooit hebben getest. In dat gat zit het echte risico.

Een backup is niet iets dat je hebt. Het is iets dat je kunt terugzetten. Tot je daadwerkelijk hebt teruggezet, heb je geen backup, maar een hoopvolle kopie van wat bestanden. De meeste fouten hieronder komen voort uit het verwarren van die twee.

Dit artikel loopt langs de backupfouten die ik het vaakst zie, kadert ze rond het simpele 3-2-1-idee, en geeft je een manier om te ontdekken of je backups echt zijn, voordat de dag komt dat je ze nodig hebt.

Nooit een restore testen

Dit is de grote, en hij ligt onder alle andere. Een backup die nooit is teruggezet is een aanname, geen vangnet.

Restores mislukken om saaie redenen. Het backupbestand is corrupt. Het formaat is veranderd en de nieuwe tooling kan de oude dump niet lezen. Een vereiste extensie ontbreekt. De inloggegevens in de backup kloppen nergens meer mee. Niets daarvan valt op terwijl de backups elke nacht rustig draaien. Alles daarvan valt op op de ene ochtend dat je ze echt nodig hebt.

De oplossing is een restore-oefening: pak een recente backup, zet die terug in een wegwerpomgeving, en controleer of de applicatie opstart en de data er is. Doe het nu één keer. Zet daarna een herinnering in de agenda om het elk kwartaal te herhalen. De eerste oefening vindt bijna altijd iets.

Backups bij dezelfde provider en in dezelfde regio

Als je database bij één cloudprovider draait en je backups in hetzelfde account staan, in dezelfde regio, ben je tegen één ding beschermd: het per ongeluk verwijderen van een rij. Je bent niet beschermd tegen een geblokkeerd account, een factuurgeschil, een storing in de regio, of een gehackte login die bij allebei kan.

Dit is de kern van het 3-2-1-idee, zonder het jargon: bewaar minstens drie kopieën van je data, op twee verschillende soorten opslag, met één kopie ergens helemaal anders. Dat “ergens anders” is het deel dat startups overslaan. Een offsite kopie bij een andere provider, of op zijn minst een ander account en een andere regio, is wat een slechte dag verandert in een vervelende dag.

Nog beter is een immutable kopie, eentje die een bepaalde periode niet verwijderd of overschreven kan worden, ook niet door iemand met volledige toegang. Als ransomware of een boze login bij je backups kan, waren het nooit echt backups.

Wel de database, niets anders

De database krijgt alle aandacht. De rest van het systeem krijgt geen, en de rest van het systeem is vaak juist wat je niet kunt herbouwen.

Drie dingen vallen er meestal tussendoor:

Uploads en gebruikersbestanden. Afbeeldingen, documenten, exports, alles dat buiten de database wordt bewaard. Als die op een schijf of bucket staan die niet in je backupbereik zit, wijst een teruggezette database naar bestanden die niet meer bestaan.

Secrets en configuratie. API-sleutels, environment variables, certificaten, precies de config die de app laat draaien. Zet de data terug zonder deze, en je hebt een database waar niemand verbinding mee kan maken.

Infrastructuurdefinitie. Hoe de servers waren ingericht. Als dat alleen in iemands hoofd zit, hangt je hersteltijd af van of die persoon beschikbaar is en het zich herinnert.

Een handige test: stel je voor dat het hele account morgen weg is. Maak een lijst van alles wat je nodig zou hebben om het draaiende product te herbouwen. Controleer dan dat elk item ergens buiten dat account is geback-upt.

Geen gedocumenteerde restoreprocedure

Zelfs een perfecte backup is traag in gebruik als niemand weet hoe. Tijdens een storing is het slechtst denkbare moment om voor het eerst de stappen uit te zoeken, onder druk, mogelijk zonder de ene persoon die alles heeft opgezet.

Een restoreprocedure hoeft niet uitgebreid te zijn. Eén pagina: waar de backups staan, hoe je erbij komt, de exacte commando’s om terug te zetten, wat je daarna controleert, en wie je belt. Geschreven zodat iemand anders dan jij het kan volgen. Als maar één persoon het systeem kan terugzetten, is je echte hersteltijd “hoe lang het duurt tot die persoon opneemt”.

Aannemen dat de managed provider het regelt

Managed databases en platforms maken vaak wel backups. Dat is oprecht handig, en het is ook waar veel vals vertrouwen vandaan komt.

Lees wat ze daadwerkelijk beloven. Veel bewaren backups maar zeven dagen, wat niet helpt bij een probleem dat je pas in week drie ontdekt. Veel kunnen je niet beschermen als je eigen account wordt geblokkeerd of gehackt, de backups staan in hetzelfde account. En bijna geen enkele backupt je uploads, secrets of configuratie, alleen de database die ze beheren.

“De provider regelt het” is een redelijk startpunt en een gevaarlijk eindpunt. Weet precies wat gedekt is, en neem de gaten daarna zelf in handen.

RPO en RTO in gewone taal

Twee begrippen die het waard zijn om te kennen, omdat ze een vage zorg veranderen in een beslissing.

RPO, recovery point objective: hoeveel data kun je je veroorloven te verliezen? Als je één keer per nacht backupt, is je RPO tot een dag, je kunt alles sinds de laatste backup kwijtraken. Als een dag aan verloren data onacceptabel is, heb je vaker backups nodig.

RTO, recovery time objective: hoe lang kun je je veroorloven plat te liggen tijdens het terugzetten? Ongeteste backups en ongedocumenteerde procedures maken dit getal stilletjes veel groter dan founders aannemen.

Je hebt geen agressieve doelen nodig. Je hebt eerlijke nodig. Bepaal waarmee je kunt leven, en bouw dan backups die dat ook echt halen.

Een simpele manier om te checken

Voor founders die één regel willen om naar te handelen:

Een backup die je niet hebt teruggezet is geen backup. Zet er één terug in een schone omgeving, met de database, de uploads, de secrets en de config, en pas dan weet je wat je hebt.

De launch-check voordat je live gaat behandelt hetzelfde instinct van de andere kant: bevestig dat de dingen die klanten beschermen echt werken, voordat je er op de harde manier achter komt.

---

Loop je hier tegenaan?

Vertel me waar je mee zit, per mail of in een gratis gesprek. Samen bepalen we de slimste volgende stap.

Vertel me over je situatie → · Mail direct: hello@yourstartup.expert