Vad är RTO och RPO? Praktisk guide för svenska företag

RTO (Recovery Time Objective) är den maximala tid en organisation accepterar att ett system är otillgängligt efter en incident. RPO (Recovery Point Objective) är den maximala mängd data, mätt i tid, som får gå förlorad. Tillsammans definierar de hur ambitiös backup och disaster recovery behöver vara per system.

Definition och sammanhang

RTO och RPO används för att översätta affärskrav till tekniska val. Ett ekonomisystem som måste vara igång inom en timme efter ett haveri har RTO = 1 timme. Om systemet samtidigt inte tål att förlora mer än 15 minuters transaktioner är RPO = 15 minuter. Dessa två tal styr sedan vilken backup-frekvens, replikering och DR-arkitektur som krävs.

Skillnaden i praktiken

Så sätter du realistiska mål

Börja med en Business Impact Analysis där varje system bedöms efter ekonomisk, regulatorisk och rykteskonsekvens vid avbrott. Sortera systemen i tre nivåer: kritiska (verksamheten stannar), viktiga (produktivitet sjunker) och normala (lågt direkt påverkan).

Sätt sedan RTO och RPO per nivå. Var realistisk, ju lägre värden, desto högre kostnad. En RTO på fem minuter kan vara tio gånger dyrare än fyra timmar för samma system.

Kostnad och teknikval per nivå

Mycket korta RTO och RPO (minuter) kräver synkron replikering till varm sekundärmiljö, ofta multi-region eller multi-zone. Måttliga värden (timmar) klarar asynkron replikering eller frekvent snapshot. Längre värden (dygn) löses kostnadseffektivt med klassisk backup till objektlagring.

Så hjälper Opsio

Opsio gör BIA, definierar RTO och RPO per system och bygger den DR-arkitektur som krävs för era mål, inte mer och inte mindre. Läs mer i pelaren Backup och disaster recovery för svenska företag eller besök vår tjänstesida för backup och DR. För en kostnadsfri RTO/RPO-genomgång, kontakta oss. Se även vår guide till disaster recovery.

Vanliga frågor

Kan RTO och RPO vara samma värde?

Ja, men det är ovanligt. Oftast är RPO kortare än RTO eftersom kontinuerlig replikering är billigare än automatiserad failover. Det viktiga är att båda värden är medvetet valda baserat på affärskonsekvens, inte teknik.

Vad händer om vi sätter för låga värden?

Kostnaden ökar snabbt. En RTO på 15 minuter kan kräva hot-standby med löpande synkronisering, vilket är betydligt dyrare än en 4-timmars RTO med en automatiserad återställning från snapshot.

Måste alla system ha samma RTO och RPO?

Nej, tvärtom. En av huvudpoängerna med BIA är att skilja på system. Att tillämpa en strikt RTO på allt blir snabbt orimligt dyrt. Differentiering ger samma skydd där det behövs, till lägre total kostnad.

Vem ska sätta RTO och RPO?

Affärssidan, inte IT. IT levererar mot mål, men det är ledning och verksamhet som vet hur länge en process tål avbrott. IT:s roll är att översätta målen till teknik och visa kostnaderna för olika nivåer.

Hur ofta bör målen omprövas?

Minst årligen, samt vid större organisations- eller systemförändringar. Nya regulatoriska krav, ny kundkrav eller förändrade affärsprocesser kan flytta gränserna.