RTO en RPO

Er zijn twee momenten waarop organisaties plotseling héél geïnteresseerd raken in back-ups en herstel:

1. tijdens een audit, en
2. tijdens een incident.

Tijdens audits zegt men dingen als “continuïteit”, “business impact” en “herstelbaarheid” met de rustige stem van iemand die nog nooit heeft meegemaakt dat de database zichzelf in een rokende kuil veranderde. Tijdens incidenten zegt men vooral: “HOE SNEL KAN DIT TERUG?!” in een toonhoogte die normaal alleen voorkomt bij mensen die een kind kwijtraken in het donkere enge beesten bos.

En precies in dat spanningsveld wonen RTO en RPO.

• RTO (Recovery Time Objective): hoe snel moet het weer werken?
• RPO (Recovery Point Objective): hoeveel data mag je kwijt zijn? (oftewel: tot welk moment terug in de tijd is acceptabel?)

Het zijn de enige twee vragen die, als je ze vooraf goed beantwoordt, een incident veranderen van “chaos met management” naar “chaos met plan”.

Waarom “per systeem” zo belangrijk is

De klassieker is dit: een organisatie heeft één RTO/RPO. Voor alles. Voor iedere applicatie. Alsof je zegt: “In dit huis is de maximale acceptabele temperatuur 21 graden.” Ja. Maar in de sauna, de koelkast en de oven is dat niet handig.

Niet elk systeem is even belangrijk, en belangrijker: niet elk systeem is even herstelbaar binnen dezelfde tijd. Sommige dingen kun je in een uur terugzetten. Andere dingen kosten een weekend, drie engineers, een ritueel met oude documentatie en een offer aan de goden van legacy.

Als je geen RTO/RPO per systeem vastlegt, krijg je in een incident steevast dit gesprek:

• “Wat is de prioriteit?”
• “Alles.”
• “Oké, maar wat eerst?”
• “Alles, maar dan eerst.”
• “Met welke RTO?”
• “Snel.”
• “Met welke RPO?”
• “Niks kwijt!”
• “Prima, dan had u eigenlijk gisteren al moeten beginnen.”

RTO/RPO per systeem is dus geen bureaucratie. Het is het verschil tussen keuzes en paniek.

Wat je ermee wint (behalve minder adrenaline)

1) Je voorkomt dat je kroonjuwelen dezelfde behandeling krijgen als het intranet

Als je alles gelijk behandelt, eindig je met het beschermen van onbelangrijke dingen alsof het staatsgeheimen zijn, en het behandelen van essentiële systemen alsof het “wel meevalt”.

RTO/RPO dwingt je om te zeggen:

• “Dit systeem betaalt de rekeningen.”
• “Dit systeem is irritant maar niet fataal.”
• “Dit systeem kan een week uit en niemand merkt het, behalve die ene collega die het gebouwd heeft in 2014.”

2) Je kunt eindelijk back-ups, replicatie en architectuur zinnig ontwerpen

RTO/RPO zijn niet alleen doelen; ze zijn ontwerpkeuzes.

• Wil je RTO van 15 minuten? Dan heb je waarschijnlijk HA, replicatie, automation nodig.
• Wil je RPO van bijna nul? Dan heb je near-real-time replicatie nodig, plus een plan tegen corrupte data die vrolijk meerepliceert.

Als je dat niet vooraf bepaalt, is je “strategie” vooral: hopen dat restore snel genoeg is.

3) Je kunt prioriteren tijdens herstel

Bij een incident is tijd het duurste product ter wereld. Als je dan niet weet welke systemen het eerst terug moeten, ga je vanzelf het hardst schreeuwende team bedienen. Dat is een slechte strategie, maar het voelt heel democratisch.

RTO/RPO maakt herstel volgordelijk en rationeel:

• eerst identity / access
• dan core infra
• dan kritieke business apps
• dan de rest

Hoe je het doet (zonder dat het een Excel-kerkhof wordt)

Stap 1: Maak een systeembibliotheek die niet liegt

Je hebt een lijst nodig van systemen (apps, databases, infra-componenten, SaaS). Maar vooral: met eigenaarschap en afhankelijkheden.

Want RTO/RPO zonder dependencies is alsof je zegt: “De auto moet binnen 1 uur rijden,” terwijl de motor in een ander land staat.

Voor elk systeem wil je minimaal:

• eigenaar (business + technisch)
• functie (wat doet het)
• afhankelijkheden (identity, netwerk, database, externe APIs, leveranciers)
• data-classificatie (gevoeligheid)
• “kroonjuweel”-status (ja/nee)

Stap 2: Bepaal impact in mensentaal, niet in compliance-taal

De beste manier om RTO te bepalen is niet: “Wat willen we?” maar:
“Wat kost het ons per uur als dit uit ligt?”

Impact-dimensies:

• omzetverlies / productiestop
• wettelijke verplichtingen (meldingen, bewaartermijnen)
• veiligheid (fysiek/operationeel)
• reputatie / klantvertrouwen
• interne productiviteit

Vraag het zo:

• Na 15 minuten uitval: wat gebeurt er?
• Na 1 uur: wat gebeurt er?
• Na 1 dag: wat gebeurt er?
• Na 1 week: wat gebeurt er?

Mensen kunnen tijd beter voelen dan abstracte “hoog/midden/laag”.

Stap 3: Vertaal impact naar klassen (tiers)

Je hoeft niet voor 200 systemen unieke tijden te verzinnen. Maak tiers. Bijvoorbeeld:

• Tier 0 (kritiek): RTO 1 uur, RPO 15 min
• Tier 1 (hoog): RTO 4 uur, RPO 1 uur
• Tier 2 (medium): RTO 24 uur, RPO 8 uur
• Tier 3 (laag): RTO 3–7 dagen, RPO 24 uur+

De exacte waarden verschillen per organisatie, maar het principe blijft: dwing keuzes af.

Stap 4: Check de haalbaarheid met techniek (de realiteitscontrole)

Nu komt het moment waarop IT zegt: “Leuk, maar dat kan niet.” Dat is niet dwarsliggen; dat is natuurkunde.

Voor elk tier check je:

• huidige backup-frequentie en type (full/incremental/snapshots)
• restore-tijd (realistisch, inclusief mensen, approvals, keys, network)
• data-volume (terugzetten van 20 TB duurt)
• afhankelijkheden (SSO down = alles down)
• cloud/on-prem beperkingen

En dan gebeurt het volwassen ding: je past óf je doelen aan, óf je investeert om ze te halen.

Stap 5: Leg vast hoe je het haalt (strategie per tier)

Voor elk tier kies je passende maatregelen:

Voor lage RTO/RPO (kritiek):

• redundantie / HA / failover
• replicatie (maar let op corrupte data)
• automation en runbooks
• gescheiden backups (immutable/offline)
• getest herstel op vaste cadence

Voor hogere RTO/RPO (minder kritisch):

• reguliere backups met restore-procedure
• minder frequente tests
• focus op databehoud boven snelheid

Belangrijk: RPO ≠ backup alleen. Soms is RPO vooral een dataprocesvraag (transacties, queueing, integraties).

Stap 6: Testen alsof je het meent (want anders is het fantasie)

RTO/RPO bestaan pas als je ze test. Niet “we hebben het geprobeerd”. Echt testen:

• voer restores uit (in isolatie)
• meet tijd: van “we besluiten te herstellen” tot “service draait”
• meet dataverlies: tot waar terug
• documenteer blokkades (keys, accounts, netwerkroutes, permissions)
• verbeter runbooks

En ja, dit is precies het moment waarop je ontdekt dat de back-up “succesvol” was, maar de restore faalt omdat niemand nog weet waar de encryptiesleutel staat. Verrassend vaak.

Stap 7: Herzie regelmatig (want systemen veranderen)

Nieuwe releases, nieuwe dataflows, nieuwe SaaS, nieuwe afhankelijkheden. RTO/RPO verouderen sneller dan je denkt. Herzie minimaal jaarlijks, en zeker bij grote veranderingen.

De valkuilen (waar iedereen intrapt)

• Alles Tier 0 maken: dan is niets Tier 0. En je budget sterft.
• RPO = 0 roepen: dat betekent vaak “we begrijpen niet wat dit kost.”
• Geen dependencies: je herstelt app A, maar identity is stuk, dus… succes.
• Back-ups testen vergeten: de klassieke: “We hebben backups.” Tot je ze nodig hebt.
• Hoe en in welke keten hangt het: Huh! keten?