RTO, RPO og MTTR: definering av gjenopprettingsmål

Uten spesifikke og målbare gjenopprettingsmål er det umulig å utforme egnede strategier for sikkerhetskopiering, velge riktig nivå på DR-lokasjonen eller vurdere om investeringer i gjenopprettingsteknologi er berettigede. RTO, RPO og MTTR omsetter virksomhetens krav til tilgjengelighet til presise tekniske mål. Disse målene gjør det mulig for sikkerhets- og IT-team å ha kunnskapsbaserte samtaler med ledelsen om kostnadene ved nedetid sammenlignet med kostnadene ved DR-investeringer — slik at forretningsbegrunnelser blir konkrete i stedet for abstrakte.

Mål for gjenopprettingstid (RTO) er den maksimalt akseptable tiden fra en forstyrrelse begynner, til normal tjeneste er gjenopprettet. Hvis et kritisk betalingssystem svikter kl. 10.00, og virksomheten maksimalt tåler 2 timers nedetid før den mister uakseptable inntekter eller bryter SLA-er, er RTO-en 2 timer — systemet må senest være gjenopprettet kl. 12.00. RTO styrer valg av nivå på DR-lokasjonen (hot-lokasjon for 15 minutters RTO kontra cold-lokasjon for 48 timers RTO), replikeringsfrekvens og automatisering av failover.

Mål for gjenopprettingspunkt (RPO) er det maksimalt akseptable datatapet målt i tid — hvor mye datatap som kan tolereres dersom en katastrofe inntreffer. En RPO på 1 time betyr at systemene ved gjenoppretting ikke kan inneholde data som er eldre enn 1 time før katastrofen inntraff. RPO styrer sikkerhetskopieringsfrekvensen: En RPO på 1 time krever minst sikkerhetskopiering hver time (eller kontinuerlig replikering). En RPO på 4 timer kan tåle intervaller på 4 timer mellom sikkerhetskopieringene. RPO gjelder datagjenoppretting, mens RTO gjelder gjenoppretting av tjenestetilgjengelighet.

RTO og RPO gjelder ulike sider ved gjenoppretting og må defineres uavhengig av hverandre. Et system kan ha en streng RPO (1 time, som betyr at data replikeres ofte), men en mindre streng RTO (4 timer, som betyr at det tar tid å starte DR-miljøet selv om dataene er oppdaterte). Omvendt kan et system ha en mindre streng RPO (24 timer, der daglig sikkerhetskopiering er tilstrekkelig), men en streng RTO (failover kreves innen 1 time, og derfor må et forhåndsprovisjonert DR-miljø være klart til aktivering). Begge målene kommer fra analysen av virksomhetspåvirkning.

Gjennomsnittlig tid til gjenoppretting (MTTR) er den gjennomsnittlige faktiske tiden det tar å gjenopprette en tjeneste etter en hendelse — det driftsmessige målet på gjenopprettingsytelse. Mens RTO er den maksimalt tolererbare nedetiden (målet/kravet), er MTTR det observerte gjennomsnittet (den faktiske ytelsen). Organisasjoner måler MTTR på tvers av hendelser over tid og sammenligner den med RTO for å vurdere gjenopprettingsevnen. MTTR som konsekvent overstiger RTO viser at DR-funksjonene er utilstrekkelige, og at det er behov for investeringer i automatisering, bemanning eller infrastruktur.

Gjennomsnittlig tid mellom feil (MTBF) måler systemets pålitelighet — den gjennomsnittlige tiden et system er i drift mellom feil. Høyere MTBF indikerer bedre pålitelighet. MTBF og MTTR bestemmer til sammen systemets tilgjengelighetsprosent: Tilgjengelighet = MTBF / (MTBF + MTTR). Et system med en MTBF på 2000 timer og en MTTR på 2 timer har tilgjengeligheten 2000/2002 = 99,9 %. Forståelse av MTBF gjør det enklere å forutsi når feil sannsynligvis vil oppstå og planlegge vedlikeholdsvinduer tilsvarende — maskinvare med synkende MTBF nærmer seg slutten av levetiden og bør skiftes ut proaktivt.

Maksimalt tolererbar nedetid (MTD) er den absolutte maksimale tiden et system kan være utilgjengelig før virksomheten påføres uopprettelig skade — tap av kunder, regulatoriske bøter eller manglende evne til å oppfylle kontraktsforpliktelser. MTD er alltid større enn eller lik RTO. Forholdet er: MTD er virksomhetens grense; RTO er IT-målet. Hvis en kontrakt tillater et SLA-brudd på 4 timer før bøter utløses, kan MTD være 4 timer. IT-teamet utformer en RTO på 1–2 timer for å ha en sikkerhetsmargin før MTD nås.

Tjenestenivåavtaler (SLA-er) definerer kontraktsfestede forpliktelser overfor kunder som direkte påvirker kravene til RTO og RPO. En SLA fra en skyleverandør som lover 99,95 % oppetid, tillater omtrent 4,4 timers nedetid per år. Brudd på SLA-en utløser tjenestekreditter eller rett til å si opp kontrakten. Interne SLA-er mellom IT og forretningsenheter fungerer på samme måte. RTO og RPO må utformes slik at den faktiske nedetiden holdes innenfor SLA-forpliktelsene, og MTTR må måles og rapporteres for å dokumentere etterlevelse.

Teknologivalg bestemmes direkte av kravene til RTO og RPO. En RTO på 15 minutter med null RPO krever active-active-klynging med synkron replikering — ingen datatap og automatisk failover. En RTO på 4 timer med RPO på 1 time kan bruke log shipping eller asynkron replikering til en varm standby. En RTO på 24 timer med RPO på 24 timer kan bruke daglige sikkerhetskopier til cold storage. Å utforme mer robusthet enn nødvendig sløser med budsjettet; å utforme mindre robusthet skaper en uakseptabel forretningsrisiko under hendelser.

Gjenopprettingsmål er bare gyldige hvis de valideres regelmessig gjennom testing. Organisasjoner bør gjennomføre gjenopprettingstester som måler faktisk MTTR og bekrefter faktisk gjenopprettingspunkt for data (hvor gamle er dataene når de gjenopprettes?). Hvis en test viser at MTTR konsekvent er 3 timer, mens RTO er 1 time, må avviket håndteres — enten ved å forbedre DR-infrastrukturen (automatisering, forhåndsprovisjonering) eller ved å justere virksomhetens forventninger gjennom en oppdatert BIA. Testfrekvensen bør samsvare med kritikaliteten: kritiske systemer hvert kvartal, andre systemer årlig.

Rapporter om RTO, RPO og MTTR må kommuniseres til interessenter i virksomheten på en måte de forstår. I stedet for «MTTR for Tier 1-systemene våre er 47 minutter» kan man si «når de mest kritiske systemene våre svikter, gjenoppretter vi tjenesten på under én time i gjennomsnitt — innenfor tidsvinduet på to timer som kontraktene våre tillater». Regelmessig rapportering bygger tillit hos interessentene og skaper en felles forståelse av organisasjonens motstandsdyktighet. Dashbordrapportering av MTTR-trender over tid viser forbedringer i programmet og underbygger behovet for budsjett til DR-investeringer.

I denne leksjonen har De lært at RTO er den maksimale tiden en tjeneste kan være utilgjengelig og styrer kravene til hastighet ved failover, at RPO er det maksimalt akseptable datatapet og styrer frekvensen for sikkerhetskopiering og replikering, og at MTTR er den målte faktiske gjennomsnittstiden for gjenoppretting, som sammenlignes med RTO for å evaluere hvor effektivt DR-programmet er. Deretter skal vi se nærmere på strategier for sikkerhetskopiering — 3-2-1-regelen og uforanderlige sikkerhetskopier som løsepengevirus ikke kan ødelegge.