RTO en RPO bij disaster recovery: definities, voorbeelden en hoe u ze bepaalt

RTO (recovery time objective) is de langste tijd dat een systeem na een verstoring uit de lucht mag zijn. RPO (recovery point objective) is de meeste data die u zich kunt veroorloven te verliezen, gemeten als tijd sinds de laatste bruikbare kopie. Een RTO van 4 uur en een RPO van 15 minuten betekent: binnen 4 uur weer online, met hooguit 15 minuten dataverlies.

Belangrijkste punten

• RTO kijkt vooruit vanaf de storing (hoe lang tot de dienst terug is). RPO kijkt achteruit (hoe oud is de laatste goede kopie van de data).
• Beide zijn bedrijfsbeslissingen. Bepaal ze per systeem met een business impact analysis en kies daarna de technologie die ze haalt.
• De back-upfrequentie begrenst uw RPO: bij back-ups om de 4 uur is het dataverlies in het slechtste geval ongeveer 4 uur.
• Lagere doelen kosten meer. Een RTO/RPO van bijna nul vraagt om replicatie en standby-capaciteit op een tweede locatie.
• Doelen op papier betekenen weinig zolang een test de werkelijke hersteltijd en het werkelijke dataverlies niet heeft gemeten.

Wat is RTO bij disaster recovery?

RTO is de maximaal aanvaardbare tijd tussen het uitvallen van een dienst en het terugkeren ervan. AWS definieert het in de whitepaper Disaster Recovery of Workloads on AWS als "de maximaal aanvaardbare vertraging tussen de onderbreking van de dienst en het herstel van de dienst" (eigen vertaling). NIST benadert het vanuit het bedrijf: de tijd die een systeem in herstel mag zijn "voordat dit een negatieve invloed heeft op de missie of de missie-/bedrijfsprocessen van de organisatie" (eigen vertaling).

RTO omvat het hele herstel, niet alleen de technische restore. Detectie, het besluit om het DR-plan in werking te stellen, het terugzetten van data, het valideren van de applicatie en het omschakelen van gebruikers tellen allemaal mee. Teams die alleen de restore timen, halen hun RTO bij een echte calamiteit meestal niet.

Wat is RPO bij disaster recovery?

RPO is het maximaal aanvaardbare dataverlies, uitgedrukt in tijd. AWS noemt het "de maximaal aanvaardbare tijd sinds het laatste herstelpunt van de data" (eigen vertaling). Is uw RPO 1 uur, dan moet u na een storing data kunnen terugzetten die niet ouder is dan 1 uur.

RPO wordt bepaald door hoe vaak u data kopieert. Nachtelijke back-ups geven een RPO van ongeveer 24 uur in het slechtste geval. Back-ups van databaselogs om de 15 minuten geven grofweg 15 minuten. Continue replicatie kan dit tot bijna nul terugbrengen, met een kanttekening die verderop staat: replicatie kopieert ook corruptie en verwijderingen.

RTO versus RPO: het verschil in een oogopslag

Uitgewerkte voorbeelden

Voorbeeld 1: een ordersysteem. Een webwinkel kiest een RTO van 4 uur en een RPO van 15 minuten. De database valt om 10:00 uit. De winkel moet om 14:00 weer orders kunnen aannemen en hooguit de orders tussen 09:45 en 10:00 mogen ontbreken. Nachtelijke back-ups halen dit niet. De winkel heeft back-ups van transactielogs of replicatie minstens elke 15 minuten nodig, plus een gescripte manier om de applicatielaag binnen 4 uur opnieuw op te bouwen.

Voorbeeld 2: een back-upschema controleren. Een financieel systeem wordt elke 6 uur geback-upt en een volledige restore duurt 3 uur. Vraagt het bedrijf om een RPO van 1 uur en een RTO van 2 uur, dan mislukken beide doelen: het dataverlies is in het slechtste geval ongeveer 6 uur en de restore alleen overschrijdt al de RTO. De oplossing is frequentere back-ups plus een snellere herstelmethode, of een bedrijfsbesluit om ruimere doelen te accepteren.

Voorbeeld 3: een portfolio indelen in niveaus. De meeste bedrijven groeperen systemen in niveaus in plaats van doelen een voor een te stellen. De cijfers hieronder zijn ter illustratie, geen standaard.

De kolom met strategieën volgt de vier benaderingen in de AWS-whitepaper, waarin back-up en restore herstel in uren levert en multi-site active/active vrijwel in realtime. In onze gids over het disaster recovery-plan leest u elke strategie en hoe u kiest.

Hoe verhouden RTO en RPO zich tot de maximaal tolereerbare downtime?

Maximum tolerable downtime (MTD) is hoe lang een bedrijfsproces verstoord mag zijn voordat de schade ernstig wordt. NIST SP 800-34 legt uit dat de RTO "normaal gesproken korter moet zijn dan de MTD" (eigen vertaling), omdat medewerkers nadat de systemen terug zijn nog tijd nodig hebben om achterstanden weg te werken en verloren data opnieuw in te voeren. RPO maakt geen deel uit van MTD. Het beschrijft hoeveel data het proces kan missen (NIST SP 800-34 Rev. 1).

In de praktijk: kan het orderproces 8 uur zonder systemen en kost het inhalen 2 uur, dan moet de IT-RTO 6 uur of minder zijn.

RTO en RPO bepalen

1. Som bedrijfsprocessen en hun afhankelijkheden op. Koppel elk proces aan de applicaties, databases, identiteitsdiensten en derden die het nodig heeft.
2. Schat de impact van downtime en dataverlies in de tijd. Omzet, contractuele boetes, regelgevende blootstelling, veiligheid en reputatie. AWS wijst erop dat de impact van timing kan afhangen: een storing in de salarisadministratie vlak voor betaaldag weegt veel zwaarder dan vlak erna.
3. Stel per niveau doelen voor en laat de bedrijfseigenaar ze goedkeuren. IT hoort ze niet alleen te kiezen.
4. Prijs de opties. AWS adviseert dat een herstelstrategie die meer kost dan de storing waartegen ze beschermt, "niet moet worden ingevoerd tenzij er een secundaire drijfveer is, zoals wettelijke eisen" (eigen vertaling).
5. Ontwerp en test. Bouw de mechanismen voor back-up, replicatie en failover, voer dan een test uit en leg de gehaalde hersteltijd en het gehaalde herstelpunt vast.
6. Herzie jaarlijks en na grote wijzigingen. Systemen schuiven tussen niveaus naarmate het bedrijf verandert.

Welke technologieën halen welke doelen?

• Geplande back-ups en snapshots passen bij een RPO van uren. Ze beschermen goed tegen corruptie en verwijdering, omdat elke kopie een vast tijdstip is.
• Point-in-time recovery (back-ups van databaselogs) brengt de RPO voor databases terug tot minuten.
• Asynchrone replicatie naar een andere regio geeft een RPO van seconden tot minuten, afhankelijk van de replicatievertraging.
• Synchrone replicatie over Availability Zones geeft een RPO dicht bij nul, ten koste van schrijflatentie. De Azure Well-Architected-richtlijnen voor disaster recovery van Microsoft stellen synchrone replicatie over zones voor bij data met hoge prioriteit en asynchrone replicatie over regio's voor data met lagere prioriteit.
• Standby-omgevingen en automatisering (pilot light, warm standby, infrastructure as code, gescripte DNS-failover) verlagen de RTO.

Pas op voor de replicatiefuik. AWS merkt op dat continue replicatie "mogelijk niet beschermt tegen rampen zoals datacorruptie of kwaadaardige aanvallen" (eigen vertaling), zoals point-in-time back-ups dat wel doen. Een database die door ransomware is versleuteld, repliceert even snel als een gezonde. Bewaar dus point-in-time kopieën naast de replica's.

Hoe bewijst u dat u uw doelen haalt?

Meet, ga niet uit van aannames. Noteer bij elke DR-test wanneer de storing begon, wanneer het plan in werking werd gesteld, wanneer de dienst terugkeerde en het tijdstip van de laatst herstelde transactie. Daaruit volgen uw gehaalde RTO en RPO. De richtlijnen van Microsoft raden een mix aan van tabletop-oefeningen, dry runs in niet-productie en oefeningen op productieniveau. Volg de resultaten in de tijd en pak eerst de traagste stap aan.

Hoe Opsio helpt

Opsio houdt business impact-workshops, stelt samen met uw bedrijfseigenaren RTO/RPO per niveau vast en bouwt en test het bijpassende herstelontwerp op AWS en Azure via de cloud disaster recovery-dienst. Voor het SaaS-wervingsplatform WorkBuster was een aanpak met bijna nul downtime een harde eis toen Opsio het platform naar AWS verhuisde. Het ontwerp gebruikt een multi-AZ, hoogbeschikbare MySQL-database op Amazon RDS, met de infrastructuur vastgelegd in CloudFormation-templates.

Veelgestelde vragen

Wat is het verschil tussen RTO en RPO?

RTO is hoe lang een systeem na een verstoring niet beschikbaar mag zijn. RPO is hoeveel data, gemeten in tijd, u zich kunt veroorloven te verliezen. RTO gaat over downtime, RPO over dataverlies.

Wat is een goede RTO en RPO?

Er is geen universeel getal. Een betalingssysteem heeft voor beide misschien minuten nodig, terwijl een intern rapportagetool 24 uur kan accepteren. Leid doelen af uit de kosten van downtime en dataverlies per bedrijfsproces en controleer daarna wat het kost om ze te halen.

Kan RPO nul zijn?

Bijna nul wel, met synchrone replicatie of multi-site active/active-ontwerpen. Echt nul dataverlies is over regio's heen moeilijk te garanderen vanwege afstand en latentie, en replicatie alleen beschermt niet tegen corruptie.

Is RTO hetzelfde als een SLA?

Nee. Een SLA is een belofte aan klanten over beschikbaarheid of reactietijd. RTO is een intern hersteldoel voor een rampscenario. Uw RTO hoort uw SLA's te ondersteunen, maar ze worden anders gemeten.

Hoe vaak moeten hersteldoelen worden herzien?

Minstens één keer per jaar en na grote wijzigingen in systemen, leveranciers of het bedrijf. Meet ze opnieuw bij elke DR-test, want de gehaalde waarden tellen.

Meer uit onze kennisbank: Hoe SLA berekenen in Azure? Formules en voorbeelden uit de echte wereld