De restoretest: het enige bewijs dat je niet kunt verzinnen

In elke leveranciersvragenlijst die op dit moment rondgaat staat een vraag over back-ups. Meestal drie zelfs: hoe vaak, hoe lang bewaard, en waar staan ze.

Op alle drie kun je binnen een minuut antwoord geven. Dagelijks, dertig dagen, in een datacenter in Nederland. Klaar.

Dan volgt de vierde vraag, en die is van een andere orde: wanneer heb je voor het laatst getest of je die back-up daadwerkelijk kunt terugzetten?

Daar valt het bij bijna iedereen stil. En precies daarom is dat het antwoord waarmee je het verschil maakt.

Waarom deze vraag anders is dan de andere

Beleid is een belofte over de toekomst. Je kunt het opschrijven zonder dat er iets gebeurd is, je kunt het van een voorbeelddocument overnemen, en niemand kan aan de tekst zien of het klopt.

Een uitgevoerde herstelproef is een gebeurtenis in het verleden. Er is een datum. Er is iemand die het gedaan heeft. Er is een doorlooptijd, en die is bijna nooit rond, want herstel duurt zelden precies twee uur. En er is een uitkomst, meestal met een kanttekening erin, want de eerste keer gaat er altijd iets net anders dan verwacht.

Dat maakt het onvervalsbaar. Iemand die dit soort documenten vaker leest, ziet in drie seconden het verschil tussen een verzonnen regel en een echt verslag. Het verzonnen verslag is namelijk te netjes.

En het is ook nog eens het onderdeel dat er inhoudelijk het meest toe doet. Een back-up die nooit is teruggezet, is geen back-up maar een aanname.

Wat er in de praktijk misgaat

De klassieker is dat de back-up prima draait en dat het terugzetten pas op het slechtste moment wordt uitgeprobeerd. Dit zijn de dingen die dan naar boven komen, en het zijn er meer dan je denkt.

• De database zit er niet bij. De bestanden staan er, de site komt terug, en hij is leeg. Dit is de meest voorkomende.
• De back-up staat op dezelfde server. Prima bij een verkeerde update, waardeloos bij ransomware of een uitgevallen machine.
• Niemand weet hoe het moet. Er is één iemand die het kan en die is met vakantie of niet meer in dienst.
• Het duurt veel langer dan gedacht. Iedereen zegt "een paar uur". In de praktijk kan het downloaden alleen al een halve dag duren.
• De back-up is stilletjes gestopt. Een schijf vol, een verlopen wachtwoord, een gewijzigd pad. En omdat er geen melding op stond, staat het groene vinkje in het dashboard er nog steeds bij van drie maanden geleden.
• Er zat al malware in. Je zet terug van vier weken geleden en de backdoor komt gewoon mee.

Geen van deze zes merk je door naar je back-upschema te kijken. Alle zes merk je binnen een dagdeel als je één keer echt terugzet.

Hoe je het doet

Reken op een halve dag voor de eerste keer. Daarna is het twee uur.

Stap 1. Kies wat je terugzet en waarheen

Kies het systeem dat je het hardst nodig hebt. Voor de meeste bedrijven is dat de website of de bestandsopslag, en bij een webshop is het de webshop.

Zet terug naar een aparte omgeving, niet over de productie heen. Een staging-omgeving bij je hostingpartij, een tijdelijke subdomein of een lokale machine. Nooit over het origineel, want dan test je niet je back-up maar je zenuwen.

Stap 2. Doe het zonder hulp van degene die het altijd doet

Dit voelt onlogisch maar het is de kern van de test. Als alleen jouw vaste beheerder het kan, is de back-up afhankelijk van één persoon. Laat iemand anders het doen aan de hand van de instructie, of doe het zelf.

Waar het misgaat, weet je meteen wat je aan die instructie moet verbeteren.

Stap 3. Klok de tijd

Noteer wanneer je begint en wanneer het systeem werkt. Niet ongeveer, maar echt. Dat getal is je RTO in de praktijk, en dat is het getal dat in de vragenlijst gevraagd wordt.

Reken erop dat het langer is dan je dacht. Dat is geen slecht nieuws, dat is informatie.

Stap 4. Controleer of het echt compleet is

Terugkomen is niet hetzelfde als compleet zijn. Loop af:

• Staat de laatste data erin, of ben je een dag kwijt?
• Werken de onderdelen die van buiten komen: e-mail, betalingen, koppelingen met andere systemen?
• Zijn de gebruikers en rechten er nog?
• Kloppen de bestanden die niet in de database zitten, zoals uploads en documenten?

Stap 5. Schrijf het op, en wel meteen

Dit is de stap die iedereen overslaat en het is de stap waar de waarde zit. Doe het dezelfde dag, want over twee weken weet je de details niet meer.

Het verslag, op een half A4

Meer hoeft het niet te zijn. Dit is de opzet:

• Datum en tijd van de test
• Wie hem heeft uitgevoerd
• Wat er is teruggezet, en van welke datum was die back-up
• Waarheen, dus in welke omgeving
• Doorlooptijd van start tot werkend
• Uitkomst: geslaagd, geslaagd met kanttekeningen, of niet geslaagd
• Wat er niet goed ging en wat je eraan doet
• Datum van de volgende test

Dat laatste punt is belangrijker dan het lijkt. Een verslag zonder vervolgdatum is een eenmalige actie. Een verslag met een vervolgdatum is een proces, en dat is wat er gevraagd wordt.

En laat de kanttekeningen erin staan

Serieus. Als het herstel drie uur duurde in plaats van de geschatte één, schrijf dat op. Als de e-mailkoppeling opnieuw ingesteld moest worden, schrijf dat op.

Een verslag waarin alles in één keer goed ging, leest als een verslag dat niet is uitgevoerd. Een verslag met twee eerlijke kanttekeningen en een actie erachter, leest als een bedrijf dat het serieus neemt. Dat is niet alleen eerlijker, het is ook overtuigender.

Hoe vaak

Voor de meeste mkb-bedrijven is één keer per jaar de ondergrens en elk kwartaal comfortabel. Doe hem in elk geval opnieuw na een grote wijziging: een verhuizing, een nieuw systeem, een andere hostingpartij.

Zet hem in de agenda met een herinnering, want dit is bij uitstek het soort werk dat blijft liggen zolang alles goed gaat.

Waar het verslag overal van pas komt

Je maakt het één keer en gebruikt het op minstens vier plekken:

• In de vragenlijst van je opdrachtgever, bij het blok over continuïteit
• In je map met bewijsstukken, als het sterkste document erin
• Bij je verzekeraar, want cyberverzekeraars vragen hier tegenwoordig naar
• Bij jezelf, want je weet nu wat je RTO werkelijk is in plaats van wat je hoopte

En het is meteen het antwoord op de vervelendste vervolgvraag die een auditor kan stellen, namelijk: kunt u dat aantonen.

Wat als je het uitbesteedt

Draait je site of server bij een hostingpartij, dan is de back-up meestal hun werk. Prima, maar dat betekent niet dat de test daarmee ook geregeld is.

Vraag om drie dingen:

1. De datum en uitkomst van hun laatste herstelproef.
2. Of jouw omgeving daarin zat, of alleen het platform in het algemeen.
3. Wat de doorlooptijd was.

Krijg je daar geen antwoord op, dan weet je iets belangrijks. Niet per se dat het slecht geregeld is, maar wel dat het niet gemeten is. En dan kun jij het in elk geval voor je eigen omgeving een keer laten uitvoeren.

Meer over de praktische kant staat in het stuk over back-ups testen bij WordPress.

Hoe wij het doen

Wij zetten voor onze klanten periodiek een back-up terug in een aparte omgeving en leggen de datum, de doorlooptijd en de uitkomst vast. Klanten met een onderhoudscontract krijgen dat verslag toegestuurd, zodat het klaarligt op het moment dat een opdrachtgever ernaar vraagt.

Het is geen ingewikkelde dienst en het is ook geen hoogstandje. Het is gewoon het ene onderdeel waarvan we vinden dat je het niet op je blauwe ogen moet geloven, van niemand, en van ons ook niet.

Wil je weten wanneer wij voor jouw omgeving voor het laatst een herstel hebben gedraaid? Vraag het op, dan sturen we het toe.