Du bruger Recovery Point Objective (RPO) til at definere den mængde data i sekunder, minutter, timer eller dage, som I maksimalt kan tåle at miste i tilfælde af et udfald eller nedbrud på jeres servere.
RPO bruges både i en virksomheds Business Continuity Plan, Backup & Recovery Plan og Disaster Recovery Plan. Og derfor bør du død og pine vide, hvordan man arbejder med det, hvis du er ansvarlig for jeres IT eller sidder i ledergruppen i din virksomhed.
- Men hvordan ser eksempler på RPO ud?
- Hvorfor skal den ikke bare altid være lig med 0?
- Og hvordan arbejder du med at finde jeres RPO?
Lad os hoppe direkte ned i det —
1. Eksempel 1 på RPO
2. Eksempel 2 på RPO
3. Hvorfor skal RPO'en ikke bare altid være 0 minutter?
4. Processen for at finde RPO
5. RPO og Disaster Recovery
6. Hvad skal jeres RPO være?
7. Eksempler på forskellige RPO-mål
8. Konklusion på RPO
Eksempel 1 på RPO
Forestil dig, ar du arbejder i en bank. I håndterer vigtige transaktioner for tusindvis af kunder. Knud og Dorthe henne på hjørnet. Store, lokale virksomheder, som er afhængige af et pålideligt cashflow. Og alt der i mellem.
Hvad ville der ske, hvis I ikke kunne tilgå transaktioner i en uge?
Det ville være skidt. For jer, jovist, men også for kunderne.
Til gengæld ville det gøre knapt så meget, hvis menuen i kantinen var utilgængelig på intranettet i en uges tid.
Så her vil jeres RPO på det ene system, som håndterer transaktioner, være mindre end 1 sekund, mens det på det andet vil være for eksempel 7 dage.
Dét er essensen af RPO.
Man kan også sige, at RPO’en er et mål for maksimalt datatab målt i tid. Eller — en intern aftale i din virksomhed for, hvor mange minutters data I kan tåle at miste ved et nedbrud, før det bliver kritisk for forretningen.
Eksempel 2 på RPO
En virksomhed har som en del af deres Business Continuity Plan defineret en RPO på 60 minutter. Det vil sige, at Backups skal tages minimum én gang hver time, så de kan genskabe alle data, som er mere end en time gamle.
Det betyder også, at virksomheden accepterer at miste data, som er lagret inden for den seneste time.
Så hvorfor skal RPO’en ikke bare altid være 0 minutter?
Det svarer lidt til at spørge, hvorfor din livsforsikringssum ikke bare skal være 20 mio. kr.
Fordi det koster.
Jo tættere på 0 minutter jeres RPO kommer, desto højere bliver omkostningerne til at drive det. Derfor er det en proces mellem de IT-ansvarlige, den øvrige ledelse, andre stakeholders og cloud-leverandøren at iterere en løsning på plads, hvor I er dækket godt nok — uden at være dækket for godt.
For så vælter business casen.
Og som du ved, er pengene er i forvejen små i mange IT-afdelinger. Så derfor handler det om at prioritere mellem jeres systemer.
Processen: I kan ikke finde RPO uden først at lave en risikovurdering og konsekvensanalyse
På strategisk niveau ville jeres arbejde med RPO se sådan her ud, hvis man skærer det helt ind til lårbenet:
1. Lav en risikovurdering og en BIA (Business Impact Analysis)
2. Sæt overordnede mål for RPO og RTO i jeres BCP (Business Continuity Plan)
3. Sæt separate RPO- og RTO-mål for:
-
- Backup & Recovery
- Disaster Recovery
Lad os for nu antage, at I har lavet jeres risikovurderinger og konsekvensanalyser —
Nu skal I undersøge, om jeres RPO-mål faktisk er realistiske.
Og det kræver ofte en del iterationer, hvor I pitcher jeres umiddelbare mål for RPO til jeres cloud-leverandør (så som os i ScanNet), som så vejleder og udregner priser ud fra de mål.
Sådan ser processen nogenlunde ud:
1. Sæt RPO-mål
I vælger et RPO-mål, som I føler er fornuftigt på baggrund af jeres analyser.
2. Undersøg priser og løsningsmodeller med Cloud-leverandør
Nu kan I så sammen med jeres Cloud-leverandør undersøge, om det kan lade sig gøre, og hvad det i så fald vil koste og kræve rent administrativt.
3. Forhold jer til budgettet
Når I så har alle de informationer, kan I forholde jer til, om budgettet rækker til det. Det kan være, at prisen bliver så høj, at business casen ryger.
4. Sæt nyt/nye og mere budgetrealistisk(e) RPO-mål (hvis nødvendigt)
Tag informationen med tilbage til ledelsen og find et nyt RPO-mål, I kan leve med.
5. Sænk RPO-mål eller split data yderligere op (hvis nødvendigt)
Nu kan I enten sænke jeres RPO-mål eller splitte jeres data yderligere op, så nogle systemer får en højere RPO og den samlede pris derfor falder.
Eksempel på RPO-proces: Disaster Recovery
En af vores store kunder — som vi har haft en lang og grundig dialog med — ønskede Disaster Recovery i tillæg til deres VDC-løsninger.
Vi snakkede scenarier for en Disaster Recovery-plan igennem, og her blev spørgsmålet om RPO en længere proces, fordi deres interne sikkerhedsorganisations krav var tårnhøje (som de ganske rigtigt bør være).
Men de høje krav gjorde også, at prisen blev alt for høj. Faktisk blev prisen for at drive et Disaster Recovery Site med den ønskede RPO 3-4 gange højere end deres nuværende pris for at drive deres production sites.
Det går selvfølgelig ikke.
Ligesom det ikke kan betale sig at betale i dyre domme for at få en livsforsikringssum på 20 mio. kr., hvis du og din partner sidder i et hus til 3 mio. kr.
Derfor var det vores opgave at bidrage til at finde et passende RPO-mål, som var inden for budget. Og så var det altså tilbage på tegnebrættet og iterere en løsning på plads, indtil vi i fællesskab fandt den gyldne middelvej.
Tip: Jo skarpere I selv er tidligt i processen, desto hurtigere kan jeres cloud-leverandør komme med et overslag, så I kan forventningsafstemme internt.
Bliv klogere på Disaster Recovery: Sådan designer du en Disaster Recovery i 3 trin
Hvad skal jeres RPO så være?
Det er umuligt at svare på, hvad lige præcis jeres RPO skal være. For det afhænger af så mange ting.
Jeres RPO skal sættes efter, hvor kritisk det vil være for jeres forretning at miste specifikke data. Kedeligt og ukonkret svar. Men det er umuligt at sætte på formel.
I har helt sikkert systemer, som er mere kritiske end andre. Og de systemer skal have en lavere RPO, fordi I her kun kan tåle lidt eller ingen datatab.
- Kritiske systemer = lav RPO
- Mindre kritiske systemer = højere RPO
Men om RPO’en skal være lige præcis 0 minutter eller 7 dage, det kan kun I svare på. Og det kræver lidt forarbejde.
Spørgsmål, som I kan stille jer selv for at finde frem til jeres RPO:
Det letteste ville være at definere en RPO på 0 minutter for hele molevitten. Men det holder ikke (med mindre alle jeres data er forretningskritiske). Det er alt for dyrt at holde kørende.
Derfor skal du stille de er her spørgsmål:
- Hvor mange minutter/timers data kan vi tolerere at tabe?
-
- På system 3, 4, 5 ... 99 osv?
- Hvad er de økonomiske konsekvenser ved datatab?
- Er der forskel på, hvor kritiske vores systemer er?
- Hvad er sandsynligheden for en hændelse? (risikovurdering)
- Er der noget compliance, vi skal tage højde for?
- Hvilke backup-funktioner har vi til rådighed?
- Hvor risikovillige er vi?
Eksempler på forskellige RPO-mål til forskellige use cases
I sidste ende er den "korrekte RPO" altid en individuel vurdering, men her er en række eksempler, der illustrerer, hvordan I kunne gå til opgaven.
Generelt: I bliver nødt til at forholde jer til hver enkelt server i virksomheden og finde ud af, hvad den laver. Overraskende mange virksomheder har servere, som de reelt ikke ved, hvad laver. Så skal I kigge på, hvor kritisk serveren er for forretningen, hvad konsekvensen af datatab er, og hvor hyppigt dataene ændrer sig.
Som hovedregel skal I altid være særligt opmærksomme på fil-og databaseservere, da de typisk indeholder kritiske data.
Mange applikationsservere behandler udelukkende data, der for eksempel ligger i en database på databaseserveren, og kan måske nøjes med en RPO på 24 timer eller mere.
Men jo grundigere I går til analysen, desto mindre er risikoen for ubehagelige overraskelser, når uheldet er ude.
Hjemmeside: De fleste virksomhedshjemmesider er relativt statiske. Indholdet skifter sjældent — og hvis det gør, er det ofte nyhedsindlæg eller blogartikler, som selvfølgelig kan give marketing en hovedpine at genskabe, men næppe er direkte forretningskritiske. En RPO på 7 dage ville derfor ikke være utænkelig.
Webshop: Har I en webshop, er det vigtigt at forstå, hvordan den fungerer, og hvilke muligheder I har, når I vælger jeres RPO.
Hvis shoppen er en SaaS-løsning, er der måske ingen eller meget få muligheder for at påvirke RPO’en af jeres shop.
Her kan I i stedet kontakte leverandøren og bede om deres RPO. Den information kan I så bruge til at vurdere, om RPO'en er tilfredsstillende, eller om I skal overveje at skifte leverandør.
Hvis shoppen derimod er “jeres egen”, skal I først forholde jer til, hvordan den fungerer rent teknisk.
Nogle shops er mest af alt en front for et ERP-system. Det vil sige, at varekataloget og ordrerne reelt blot læses fra/afleveres til ERP-systemet, hvor selve databehandlingen sker.
I så fald indeholder shoppen måske slet ikke dynamiske data – og RPO’en kan godt være 7 dage (som med hjemmesiden).
Hvis webshoppen til gengæld er et alt-i-ét system, hvor varekatalog, ordrehistorik og kundedatabase ligger ét sted, så bliver det pludselig kritisk at være skarp som en japansk kokkekniv på RPO’en.
Én ting er de indgående ordrer. Ofte sendes der ordrebekræftelser, som kan bruges til at genskabe dem. Men hvad med status på selve ordrerne?
Hvis shoppen er den eneste kilde til viden om, hvorvidt en ordre er afsendt eller ej, så kan det være kritisk at miste selv et par timers data.
En RPO på 15 til 30 min ville formentlig give god mening i det tilfælde.
Ofte kan det, heldigvis, løses med en in-guest backup af databasen, som kører hyppigt. Men kan det ikke lade sig gøre, kan I overveje at indføre nogle arbejdsgange (for eksempel på papir — gisp!), så I kan tåle et lidt længere datatab.
Filserver: Rigtig mange virksomheder har en filserver, men det er meget forskelligt, hvordan sådan nogen servere bruges. Derfor skal I først forholde jer til, hvordan I bruger jeres filserver.
Hvis jeres filserver er “stedet hvor dokumenter går hen for at dø” — og altså primært et sted, hvor medarbejdere smider dokumenter, de ikke længere bruger (i stedet for at slette dem) — kan I måske godt argumentere for en RPO på 24 timer, eller endda lidt mere, så længe der er tale om data, hvor man kan tåle et lille tab.
Hvis filserveren til gengæld har mange daglige ændringer, for eksempel medarbejdere der løbende sidder og skriver i dokumenter og excel-ark, bør I sigte efter en markant lavere RPO på måske 2 eller 4 timer (eventuelt mindre, hvis dokumenterne er meget kritiske).
Konklusion på RPO
RPO er et mål for, hvor meget data I maksimalt kan tåle at tabe. I kan sætte et overordnet mål eller bryde det ned per server. Og igen bryde det ned for jeres daglige backups af production sitet og igen andre RPO-mål for jeres Disaster Recovery Site.
Før I kan bestemme jeres Recovery Point Object, skal I som en del af jeres Business Continuity Plan lave en risikovurdering og en konsekvensanalyse, så I ved, hvor meget data, I har råd til at miste, hvis uheldet er ude.
Herefter kan I snakke med jeres Cloud-leverandør om, hvad der rent faktisk er muligt. En lav RPO kan være dyr. En høj RPO kan være forretningsfatal.
Find den gyldne middelvej sammen med jeres cloud-leverandør.
Vi hjælper dig
Har du spørgsmål, eller skal vi hjælpe dig med at finde den helt rigtige løsning til dit behov?
Kontakt vores salgsafdeling på:
