RTO og RPO i katastrofegjenoppretting: definisjoner, eksempler og hvordan du setter dem

RTO (recovery time objective) er det lengste et system kan være nede etter en driftsforstyrrelse. RPO (recovery point objective) er den største datamengden du kan tåle å miste, målt som tid siden siste brukbare kopi. En RTO på 4 timer og en RPO på 15 minutter betyr: tilbake i drift innen 4 timer, med høyst 15 minutters tap av data.

Viktigste punkter

• RTO ser fremover fra nedetiden (hvor lenge til tjenesten er tilbake). RPO ser bakover (hvor gammel er den siste gode kopien av dataene).
• Begge er forretningsbeslutninger. Sett dem per system gjennom en konsekvensanalyse (BIA), og velg deretter teknologi som oppfyller dem.
• Sikkerhetskopieringsfrekvensen setter taket for RPO: med sikkerhetskopi hver 4. time er verste tilfelle for datatap omtrent 4 timer.
• Strengere mål koster mer. Nær null i RTO/RPO krever replikering og standby-kapasitet på et annet sted.
• Mål på papiret betyr lite før en test har målt faktisk gjenopprettingstid og faktisk datatap.

Hva er RTO i katastrofegjenoppretting?

RTO er den høyeste akseptable tiden mellom at en tjeneste går ned og at den er tilbake. AWS definerer det som «the maximum acceptable delay between the interruption of service and restoration of service» i whitepaperen Disaster Recovery of Workloads on AWS. NIST ser det fra forretningssiden: tiden et system kan være under gjenoppretting «before negatively impacting the organization's mission or mission/business processes».

RTO dekker hele gjenopprettingen, ikke bare den tekniske tilbakeføringen. Oppdagelse, beslutningen om å aktivere DR-planen, tilbakeføring av data, validering av applikasjonen og omkobling av brukerne teller alle mot den. Team som bare tidtar tilbakeføringen, bommer vanligvis på RTO i en reell hendelse.

Hva er RPO i katastrofegjenoppretting?

RPO er det største akseptable datatapet, uttrykt i tid. AWS kaller det «the maximum acceptable amount of time since the last data recovery point». Hvis RPO er 1 time, må du etter en feil kunne gjenopprette data som er høyst 1 time gamle.

RPO styres av hvor ofte du kopierer data. Nattlige sikkerhetskopier gir en RPO på rundt 24 timer i verste fall. Loggsikkerhetskopiering av databasen hvert 15. minutt gir omtrent 15 minutter. Kontinuerlig replikering kan bringe den nær null, med ett forbehold som omtales nedenfor: replikering kopierer også korrupsjon og sletting.

RTO og RPO: forskjellen i korte trekk

Eksempler fra praksis

Eksempel 1: et ordresystem. En nettbutikk setter en RTO på 4 timer og en RPO på 15 minutter. Databasen går ned klokken 10:00. Butikken må ta imot ordrer igjen innen 14:00, og høyst ordrene lagt inn mellom 09:45 og 10:00 kan mangle. Nattlige sikkerhetskopier klarer ikke dette; butikken trenger sikkerhetskopiering av transaksjonslogg eller replikering minst hvert 15. minutt, pluss en skriptet måte å bygge opp applikasjonslaget på innen 4 timer.

Eksempel 2: kontroll av en sikkerhetskopiplan. Et økonomisystem sikkerhetskopieres hvert 6. time, og en full tilbakeføring tar 3 timer. Hvis virksomheten ber om en RPO på 1 time og en RTO på 2 timer, svikter begge målene: verste tilfelle for datatap er omtrent 6 timer, og tilbakeføringen alene overstiger RTO. Løsningen er enten hyppigere sikkerhetskopiering og en raskere gjenopprettingsmetode, eller en forretningsbeslutning om å akseptere løsere mål.

Eksempel 3: inndeling av porteføljen i nivåer. De fleste selskaper grupperer systemer i nivåer i stedet for å sette mål ett og ett. Tallene nedenfor er illustrasjoner, ikke en standard.

Strategikolonnen følger de fire tilnærmingene i AWS-whitepaperen, der backup and restore gir gjenoppretting på timer og multi-site active/active nesten i sanntid. Vår guide til katastrofegjenopprettingsplanen forklarer hver strategi og hvordan du velger.

Hvordan henger RTO og RPO sammen med maksimalt tolerabel nedetid?

Maksimalt tolerabel nedetid (MTD) er hvor lenge en forretningsprosess kan være forstyrret før skaden blir alvorlig. NIST SP 800-34 forklarer at RTO «must normally be shorter than the MTD», fordi ansatte etter at systemene er tilbake fortsatt trenger tid til å ta igjen etterslepet og legge inn tapte data på nytt. RPO er ikke en del av MTD. Den beskriver hvor mye data prosessen tåler å miste (NIST SP 800-34 Rev. 1).

I praksis: hvis ordreprosessen kan klare seg 8 timer uten systemer, og det tar 2 timer å ta igjen etterslepet, må IT-ens RTO være 6 timer eller mindre.

Slik setter du RTO og RPO

1. List forretningsprosessene og avhengighetene deres. Koble hver prosess til applikasjonene, databasene, identitetstjenestene og tredjepartene den trenger.
2. Anslå konsekvensen av nedetid og datatap over tid. Inntekter, kontraktsmessige bøter, regulatorisk eksponering, sikkerhet og omdømme. AWS peker på at konsekvensen kan avhenge av tidspunktet: et utfall rett før lønningsdag betyr langt mer enn ett rett etter.
3. Foreslå mål per nivå og la forretningseieren godkjenne dem. IT bør ikke velge dem alene.
4. Prissett alternativene. AWS råder til at hvis gjenopprettingsstrategien koster mer enn feilen den beskytter mot, «should not be put in place unless there is a secondary driver such as regulatory requirements».
5. Design og test. Bygg mekanismene for sikkerhetskopiering, replikering og failover, kjør deretter en test og registrer faktisk oppnådd gjenopprettingstid og gjenopprettingspunkt.
6. Gjennomgå hvert år og etter større endringer. Systemer glir mellom nivåer etter hvert som virksomheten endrer seg.

Hvilke teknologier oppfyller hvilke mål?

• Planlagte sikkerhetskopier og snapshots passer for RPO på timer. De beskytter godt mot korrupsjon og sletting, fordi hver kopi er et fast tidspunkt.
• Point-in-time recovery (sikkerhetskopiering av databaselogger) bringer RPO ned til minutter for databaser.
• Asynkron replikering til en annen region gir en RPO på sekunder til minutter, avhengig av replikeringsforsinkelsen.
• Synkron replikering på tvers av tilgjengelighetssoner (Availability Zones) gir en RPO nær null, på bekostning av skriveforsinkelse. Microsofts Azure Well-Architected-veiledning om katastrofegjenoppretting foreslår synkron replikering på tvers av soner for høyt prioriterte data og asynkron replikering på tvers av regioner for lavere prioriterte data.
• Standby-miljøer og automatisering (pilot light, warm standby, infrastruktur som kode, skriptet DNS-failover) reduserer RTO.

Pass på replikeringsfellen. AWS påpeker at kontinuerlig replikering «may not protect against disaster events such as data corruption or malicious attack» like godt som point-in-time-sikkerhetskopier. En database kryptert av løsepengevirus replikeres like raskt som en frisk, så ha point-in-time-kopier ved siden av replikaene.

Slik beviser du at du oppfyller målene

Mål, ikke anta. Under hver DR-test noterer du når utfallet startet, når planen ble aktivert, når tjenesten kom tilbake og tidsstempelet for den siste gjenopprettede transaksjonen. Det gir deg oppnådd RTO og RPO. Microsofts veiledning anbefaler en blanding av bordøvelser (tabletop), tørrkjøringer i ikke-produksjon og øvelser på produksjonsnivå. Følg resultatene over tid og fiks det tregeste steget først.

Slik hjelper Opsio

Opsio gjennomfører workshoper om konsekvensanalyse, setter RTO/RPO per nivå sammen med forretningseierne dine, og bygger og tester tilhørende gjenopprettingsdesign på AWS og Azure gjennom tjenesten for katastrofegjenoppretting i skyen. For SaaS-rekrutteringsplattformen WorkBuster var en tilnærming med nær null nedetid et absolutt krav da Opsio flyttet plattformen til AWS. Designet bruker en multi-AZ, høytilgjengelig MySQL-database på Amazon RDS, med infrastrukturen definert i CloudFormation-maler.

Ofte stilte spørsmål

Hva er forskjellen på RTO og RPO?

RTO er hvor lenge et system kan være utilgjengelig etter en driftsforstyrrelse. RPO er hvor mye data, målt i tid, du kan tåle å miste. RTO handler om nedetid; RPO handler om datatap.

Hva er en god RTO og RPO?

Det finnes ikke ett fasitsvar. Et betalingssystem kan trenge minutter for begge, mens et internt rapporteringsverktøy kan akseptere 24 timer. Utled målene fra kostnaden ved nedetid og datatap for hver forretningsprosess, og sjekk deretter hva det koster å nå dem.

Kan RPO være null?

Nær null, ja, med synkron replikering eller multi-site active/active-design. Helt null datatap er vanskelig å garantere på tvers av regioner på grunn av avstand og forsinkelse, og replikering alene beskytter ikke mot korrupsjon.

Er RTO det samme som en SLA?

Nei. En SLA er et løfte til kundene om tilgjengelighet eller responstid. RTO er et internt gjenopprettingsmål for et katastrofescenario. RTO bør støtte SLA-ene dine, men de måles ulikt.

Hvor ofte bør gjenopprettingsmålene gjennomgås?

Minst én gang i året og etter større endringer i systemer, leverandører eller virksomheten. Mål dem på nytt i hver DR-test, siden det er de oppnådde verdiene som teller.