Disaster recovery in 2026: RTO versus RPO, de vier DR-strategieën en wat EU DORA vereist

De meeste engineeringorganisaties hebben een disaster-recoveryplan. Veel minder organisaties hebben er een dat de afgelopen twaalf maanden van begin tot eind is uitgevoerd tegen data op productieschaal. Dat gat is duur: in de outage-analyse van het Uptime Institute over 2025 gaf 54% van de operators aan dat hun meest recente grote storing meer dan $100.000 kostte, en 20% kwam boven de $1 miljoen uit (Data Center Knowledge, 2025). Voor financiële entiteiten in de EU is een ongetest plan niet langer alleen een risico maar een compliancebevinding, omdat de Digital Operational Resilience Act back-up-, herstel- en testverplichtingen nu wettelijk vastlegt. Hieronder de vragen die engineeringleiders daadwerkelijk stellen over DR, met antwoorden die een audit doorstaan.

Rijen serverracks in een datacenter, het soort fysieke capaciteit dat een disaster-recoverystrategie op een tweede locatie moet kunnen vervangen. — Foto: Carl Lender from Sunrise, USA / CC BY 2.0, via Wikimedia Commons

Wat is het verschil tussen RTO en RPO?

Recovery Time Objective (RTO) is de maximaal aanvaardbare tijd tussen een verstoring en het herstel van de dienst. Recovery Point Objective (RPO) is het maximaal aanvaardbare dataverlies, uitgedrukt in tijd: een RPO van 15 minuten betekent dat je hooguit de laatste 15 minuten aan writes kwijtraakt. RTO gaat over beschikbaarheid, RPO over data. Het zijn onafhankelijke knoppen: continue log shipping naar een cold standby levert een RPO van seconden en een RTO van uren op.

Het praktische gevolg is dat RTO en RPO per bedrijfsfunctie moeten worden vastgesteld, niet per bedrijf. Een betaalautorisatiepad en een intern rapportagedashboard verdienen niet dezelfde doelen, en betalen voor één algemeen doel is precies hoe DR-budgetten opgaan aan systemen die niemand een dag zou missen. Het AWS Well-Architected Framework is daar duidelijk over: implementeer geen strategie die strenger is dan nodig, want dat brengt onnodige kosten met zich mee (AWS Well-Architected, REL13-BP02).

Wat zijn de vier disaster-recoverystrategieën?

De sector is uitgekomen op vier patronen, gerangschikt naar oplopende kosten en complexiteit en dalende RTO en RPO. De doelbereiken zijn de waarden die AWS publiceert; de patronen gelden net zo goed voor Azure, GCP of twee colocatielocaties.

Backup and restore (RPO in uren, RTO binnen 24 uur). Data wordt geback-upt en naar de herstellocatie gekopieerd; bij een ramp bouw je de infrastructuur opnieuw op, deploy je de code opnieuw en zet je de data terug. Point-in-time recovery kan de RPO in sommige gevallen terugbrengen tot ongeveer vijf minuten. Infrastructure as code houdt de RTO hier realistisch.
Pilot light (RPO in minuten, RTO in tientallen minuten). Data wordt continu gerepliceerd en de datalaag staat altijd aan op de herstellocatie, maar compute draait niet. Herstel betekent applicatieservers provisionen en opschalen.
Warm standby (RPO in seconden, RTO in minuten). Een verkleinde maar volledig functionele kopie van de workload draait permanent op de herstellocatie en kan direct verkeer verwerken, met beperkte capaciteit. Op volle grootte heet dit hot standby.
Multi-site active/active (RPO bijna nul, RTO mogelijk nul). De workload bedient verkeer vanaf meerdere locaties tegelijk. Dit is operationeel de meest complexe optie, vooral omdat gelijktijdige writes naar hetzelfde record in twee regio's voorkomen of verzoend moeten worden.

Het verschil tussen pilot light en warm standby zorgt vaak voor verwarring. De toets is eenvoudig: kan de herstellocatie een request verwerken zonder dat iemand eerst actie onderneemt? Zo niet, dan is het pilot light. Twee ontwerpdetails zijn belangrijker dan het label. Ten eerste moet failover zoveel mogelijk steunen op data plane-operaties (DNS-healthchecks, routing controls), niet op control plane-calls zoals het aanmaken of vergroten van resources, wat AWS tijdens herstel als anti-patroon aanmerkt. Hoe verder de standby al is opgeschaald, hoe minder je van de control plane afhangt. Ten tweede: als je opschaling afhangt van beschikbare capaciteit in de herstelregio, reserveer die dan; een pilot light die tijdens een regionaal incident geen instances krijgt, is geen strategie.

Is replicatie hetzelfde als een back-up?

Nee, en dit is het meest voorkomende gat dat we zien in verder volwassen omgevingen. Replicatie kopieert getrouw alles wat op de primaire omgeving gebeurt, inclusief een mislukte migratie, een per ongeluk uitgevoerde DROP TABLE of encryptie door ransomware. AWS merkt op dat datareplicatie niet beschermt tegen corruptie of vernietiging van data, tenzij het ontwerp ook point-in-time recovery of versiebeheer bevat (AWS Well-Architected, REL13-BP02).

Aanvallers weten dit. In het onderzoek van Sophos onder bijna 3.000 organisaties die door ransomware waren getroffen, zei 94% dat aanvallers tijdens de aanval probeerden hun back-ups te compromitteren, en 57% van die pogingen slaagde. De mediane herstelkosten voor organisaties met gecompromitteerde back-ups waren $3 miljoen, tegenover $375.000 waar de back-ups intact bleven, en slechts 26% van de eerste groep was binnen een week volledig hersteld (Sophos, 2024). Het engineeringantwoord is bekend maar wordt ongelijkmatig toegepast: immutable of object-locked back-upkopieën, een apart account of aparte tenant met eigen credentials voor de back-upvault, en geen enkele identiteit die zowel productie als de back-ups kan verwijderen.

Wat vereist EU DORA voor back-up en herstel?

Voor Benelux-banken, verzekeraars, betaalinstellingen en hun kritieke ICT-leveranciers maakt de Digital Operational Resilience Act (Verordening (EU) 2022/2554, van toepassing sinds januari 2025) van deze praktijken verplichtingen (EUR-Lex). De artikelen die engineeringteams zelf zouden moeten lezen, zijn 11 en 12:

De bedrijfsimpactanalyse stuurt het ontwerp. Artikel 11, lid 5, vereist een BIA en bepaalt dat ICT-activa volledig in lijn met die analyse worden ontworpen, met name om redundantie van alle kritieke componenten te waarborgen. Dat is een wettelijke basis voor RTO en RPO per functie, geen nice-to-have.
Minstens jaarlijks testen, en na grote wijzigingen. Artikel 11, lid 6, onder a, vereist dat ICT-bedrijfscontinuïteitsplannen en respons- en herstelplannen minstens jaarlijks worden getest, en telkens wanneer ICT-systemen die kritieke of belangrijke functies ondersteunen wezenlijk veranderen.
Vastgelegde back-upscope en -frequentie. Artikel 12, lid 1, vereist back-upbeleid dat vastlegt welke data wordt geback-upt en met welke minimale frequentie, op basis van kriticiteit, plus gedocumenteerde herstelmethoden. Artikel 12, lid 2, vereist dat die herstelprocedures periodiek worden getest.
Gescheiden herstelomgevingen. Artikel 12, lid 3, vereist dat je bij herstel met eigen systemen ICT-systemen gebruikt die fysiek en logisch gescheiden zijn van het bronsysteem. Herstellen in hetzelfde gecompromitteerde account voldoet niet.
Hersteldoelen gekoppeld aan kriticiteit. Artikel 12, lid 6, vereist RTO en RPO per functie, waarbij meeweegt of het een kritieke of belangrijke functie is, en dat de afgesproken serviceniveaus ook in extreme scenario's worden gehaald.

Let op wat de verordening niet doet: ze schrijft geen strategie voor. Backup and restore kan voor een niet-kritieke functie volledig compliant zijn. Wat ze wel eist, is bewijs dat de gekozen strategie de vastgestelde doelen haalt, en dat bewijs levert alleen testen.

Hoe vaak moet je een disaster-recoveryplan testen?

Jaarlijks is de wettelijke ondergrens, niet het engineeringdoel. Teams die schoon herstellen, behandelen DR als een continu geoefende capaciteit in plaats van een jaarlijks evenement:

Geautomatiseerde hersteltests, wekelijks of maandelijks. Zet een recente back-up terug in een geïsoleerd account, draai integriteitscontroles en een smoketest en registreer de doorlooptijd tegen de RTO. Een back-up die nooit is teruggezet, is een hypothese.
Game days per kwartaal. Laat een echte dienst failoveren, bij voorkeur in productie tijdens kantooruren met een rollbackplan, en meet de werkelijke RTO en RPO. Voer daarna de failback uit; dat is meestal de moeilijkste helft, omdat de data opnieuw naar de oorspronkelijke primaire omgeving moet worden gesynchroniseerd.
Runbooks als code. Failoverstappen gescript en geversioneerd naast de infrastructuur, zodat een handmatig besluit tot failover één knop wordt in plaats van een wikipagina met 40 stappen. AWS adviseert precies dit: automatiseer de stappen, ook als het starten handmatig blijft, omdat automatische failover op basis van onbetrouwbare healthchecks zijn eigen kosten heeft.
Tests na wijzigingen. Een upgrade van de database-engine of een verhuizing naar een nieuwe regio maakt het resultaat van vorig kwartaal ongeldig.

Rapporteer de gemeten waarden, niet de ontworpen waarden. Als de doel-RTO 30 minuten is en de laatste game day 95 minuten duurde, dan is dat het getal dat het bestuur en de toezichthouder moeten zien, samen met de oplossing.

Waar begin je?

Bestaat je DR-positie vooral uit documentatie, dan is dit de volgorde met de meeste impact: voer een BIA uit en ken per functie een RTO en RPO toe; maak back-ups immutable en zet de vault achter aparte credentials; automatiseer één volledig herstel van je meest kritieke datastore in een gescheiden account en meet de tijd; kies daarna per functie de goedkoopste strategie waarvan het gemeten resultaat laat zien dat die het doel haalt. Die volgorde sluit aan bij de geest van DORA-artikelen 11 en 12 en, belangrijker, geeft je een herstel dat je daadwerkelijk hebt zien werken.