RTO en RPO: van back-up naar een herstelplan dat werkt

Bijna elk bedrijf heeft back-ups. Veel minder bedrijven hebben een herstelplan. Dat verschil merk je pas op het moment dat het ertoe doet: als de server het begeeft, als een medewerker een map van drie jaar wist, of als ransomware je bestanden versleutelt en je binnen een uur moet weten wat je doet.

Een back-up is een kopie. Een herstelplan is het antwoord op de vraag: hoe zijn we morgen weer aan het werk? Dat antwoord bestaat uit meer dan software. Het gaat over volgorde, over hoeveel tijd en hoeveel data je kunt missen — in vakjargon je RTO en RPO — over wie wat doet, en over de vraag of iemand het weleens geprobeerd heeft.

In dit artikel maken we van je back-up een plan. Over de techniek van back-uppen zelf schreven we eerder in veilige back-ups: de best practices en een back-up alleen is niet genoeg.

RTO en RPO: twee getallen die je plan bepalen

Voordat je iets inricht, bepaal je per systeem twee dingen. Ze klinken technisch, maar het zijn vooral bedrijfskeuzes.

Hoeveel tijd mag herstel kosten? (RTO)

De recovery time objective is de maximale tijd dat een systeem plat mag liggen. Voor je e-mail is dat misschien twee uur. Voor het archief van 2019 mag dat gerust een week zijn. Hoe korter de RTO, hoe duurder de oplossing — dus stel hem niet overal op nul.

Hoeveel gegevens mag je kwijtraken? (RPO)

De recovery point objective is hoeveel werk je opnieuw mag doen. Draai je één keer per nacht een back-up, dan is je RPO 24 uur: bij een storing om vier uur ’s middags ben je een werkdag kwijt. Voor een boekhouding is dat vaak acceptabel, voor een orderadministratie meestal niet.

Maak een simpele tabel: systeem, RTO, RPO, wie is de eigenaar. Vijf regels is genoeg om te beginnen. Je zult merken dat de discussie erover meer oplevert dan de tabel zelf, omdat je ontdekt dat niemand hetzelfde beeld had.

Wat er in een herstelplan hoort

Een volgorde

Bij een grote storing kun je niet alles tegelijk. Bepaal vooraf wat er als eerste terug moet: meestal identiteit en e-mail, dan het systeem waar je omzet doorheen loopt, dan de rest. Zet die volgorde op papier, want in het moment zelf wint het hardste geluid.

Rollen en contactgegevens

Wie neemt de leiding, wie belt de klanten, wie praat met de leverancier, wie doet de melding bij de Autoriteit Persoonsgegevens als er persoonsgegevens bij betrokken zijn? Zet daar namen en telefoonnummers bij, geen functies. En bewaar die lijst ergens die niet zelf plat kan liggen — een uitdraai in de kast is niet ouderwets, die is verstandig.

Waar de sleutels liggen

Wachtwoorden van beheerdersaccounts, de herstelsleutel van je schijfversleuteling, de licenties, de contactpersoon bij je leveranciers. Als die alleen in het systeem staan dat je probeert te herstellen, heb je een probleem.

Een communicatieregel

Spreek af wat je klanten vertelt en wanneer. Niets zeggen kost meer vertrouwen dan eerlijk melden dat je een storing hebt en dat je om 16.00 uur een update geeft. Zie ook de valkuilen bij het afhandelen van een datalek.

Snel en veilig: waarom hybride meestal wint

Cloudback-ups zijn ideaal tegen lokale rampen: brand, waterschade, een gestolen server. Maar honderden gigabytes terugzetten over een internetverbinding kost tijd. Een lokale kopie op een NAS of externe schijf herstelt veel sneller.

De combinatie is daarom in de praktijk het handigst: dagelijks naar de cloud voor de bescherming buiten de deur, en periodiek naar een lokale, versleutelde kopie voor de snelheid. Dat sluit aan op de 3-2-1-regel: drie kopieën, twee soorten opslag, één buiten de deur.

Twee aandachtspunten. Een lokale back-up die permanent aan het netwerk hangt, wordt door ransomware gewoon meegenomen — zorg dat er een kopie is die niet zomaar te wijzigen of te wissen valt. En vergeet niet dat de prullenbak en versiegeschiedenis van je clouddienst geen back-up zijn; lees waarom in waar gaan verwijderde bestanden naartoe en ransomware in SaaS-omgevingen.

Testen is het hele punt

Een back-up die nooit is teruggezet, is een aanname. De meest voorkomende ontdekkingen bij een eerste herstelproef: één belangrijke map viel buiten de selectie, het herstel duurt drie keer zo lang als gedacht, of niemand weet meer waar de licentiesleutel is.

Houd het klein en regelmatig. Zet elk kwartaal één willekeurig bestand en één complete map terug, en klok hoe lang het duurde. Doe één keer per jaar een grotere oefening: doe alsof de hoofdserver of de belangrijkste clouddienst weg is en loop het draaiboek door aan tafel. Dat kost een uur en levert altijd twee verbeterpunten op.

Controleer daarnaast wekelijks de back-uplogboeken. Mislukte back-ups melden zichzelf zelden luid genoeg; stel meldingen in en wijs iemand aan die erop let.

Praktijkscenario: de back-up die wel draaide

Een productiebedrijf met 35 medewerkers krijgt ransomware binnen via een externe toegang. De back-ups draaiden keurig, elke nacht, al jaren zonder fouten. Opluchting — tot het herstel begint.

Het terugzetten van de bestandsserver over de internetverbinding blijkt 38 uur te duren. De ERP-database staat wel in de back-up, maar niemand heeft ooit getest of hij vanuit die kopie ook werkelijk start. Dat lukt uiteindelijk, na een dag bellen met de leverancier. Totale stilstand: bijna drie werkdagen, terwijl de directie had aangenomen dat het een halve dag zou zijn.

Wat het verschil had gemaakt: een lokale kopie voor snelheid, één keer per jaar een herstelproef van de database, en een expliciete afspraak over de RTO. De back-up was niet het probleem. Het ontbrekende plan was dat wel. Wat zoiets kost, lees je in de verborgen kosten van IT-uitval.

Zo pak je het aan

Stap 1. Maak een lijst van je systemen en gegevens, en zet er per regel een RTO en RPO bij. Doe dit met de mensen die met die systemen werken, niet alleen met IT.

Stap 2. Controleer of je huidige back-up die getallen haalt. Vaak niet — en dan weet je meteen waar je moet bijsturen.

Stap 3. Zorg voor een kopie buiten de deur én een kopie die niet gewijzigd kan worden.

Stap 4. Schrijf het draaiboek: volgorde, rollen, contactlijst, sleutels. Twee A4-tjes is genoeg. Print het.

Stap 5. Plan de herstelproef in de agenda, elk kwartaal. Zonder agenda-afspraak gebeurt het niet.

Stap 6. Neem het plan mee in je jaarlijkse IT-review en werk het bij als er systemen bijkomen.

Wil je breder kijken dan alleen data, bekijk dan ook hoe je je bedrijf voorbereidt op het onverwachte.

Veelgestelde vragen

Is Microsoft 365 of Google Workspace zelf al een back-up?

Nee. Beide beschermen je tegen storingen aan hun kant, met redundantie en een prullenbak met beperkte bewaartermijn. Maar tegen verwijderde of versleutelde bestanden, een vertrokken medewerker of een fout die je pas na drie maanden ontdekt, helpt dat niet. Daar heb je een aparte back-up voor nodig; zie cloudopslag veilig gebruiken.

Wat is het verschil tussen RTO en RPO?

RTO gaat over tijd, RPO over data. De RTO is hoe lang een systeem maximaal plat mag liggen voordat het je bedrijf operationeel raakt; de RPO is je maximale dataverlies — hoeveel werk je opnieuw mag doen omdat de laatste kopie te oud is. Een MKB-bedrijf zet ze per systeem naast elkaar: een RTO van vier uur en een RPO van een uur voor de orderadministratie, ruimere getallen voor het archief. Leg dat vast, want de twee samen bepalen welke oplossing je nodig hebt en wat die mag kosten.

Hoe lang moeten we back-ups bewaren?

Dat hangt af van je bewaarplicht en het type gegevens. Fiscale administratie kent in Nederland een bewaartermijn van zeven jaar; persoonsgegevens mag je juist niet langer bewaren dan nodig. Leg per soort gegeven een termijn vast en ruim de rest op.

Hoeveel opslag hebben we nodig voor back-ups?

Reken op meer dan je eerste inschatting: meerdere versies, groei en wat marge. Houd ongeveer twintig tot dertig procent vrije ruimte aan, zodat een uitschieter je back-up niet laat mislukken. Meer hierover in hoeveel opslag heb je nodig.

Moeten we dit vastleggen voor NIS2 of de AVG?

Als je onder NIS2 valt, hoort continuïteits- en herstelbeleid tot de verplichte maatregelen. Ook zonder NIS2 verwacht de AVG dat je persoonsgegevens tijdig kunt herstellen na een incident. Een gedocumenteerd, getest plan is dus niet alleen praktisch handig.

Weet je niet zeker of jullie back-up ook echt een herstel oplevert? We doen graag een keer een proef met je mee — dan weet je het in plaats van dat je het hoopt.