Hvor mange minutters data kan I tåle at miste, hvis jeres IT-crasher? Her dykker vi ned i eksempler på RPO-scenarier, og hvordan I finder frem til jeres RPO.
Recovery Time Objective er et mål for, hvor meget data (i minutter), I maksimalt kan tåle at miste, hvis uheldet skulle være ude.
RPO'en bruges både i forbindelse med backup og disaster recovery. Jeres daglige backups kan have én (eller flere forskellige) RPO'er. Og jeres disaster recovery kan have en helt trejde.
I har helt sikkert systemer, som er mere kritiske end andre. Og de systemer skal have en lavere RPO.
Kritiske systemer = lav RPO
Mindre kritiske systemer = højere RPO
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.
For at finde jeres RPO bør I I først lave en risikovurdering og en BIA (Business Impact Analysis)
Spørgsmål, som I kan stille jer selv:
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:
Din livsforsikringssum er med garanti ikke 20 mio. kr.
For det giver ikke mening. Det er alt for dyrt. Og det samme kan siges om RPO'en som kun bliver dyrere jo tættere, I kommer på nul minutter.
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.
I kan blandt andet vælge at sætte forskellige RPO'er for forskellige systemer eller splitte jeres data yderligere op.
Forestil dig, ar du arbejder i en bank, som håndterer vigtige transaktioner for tusindvis af kunder. Hvad ville der ske, hvis I ikke kunne tilgå transaktioner i en uge?
Det ville være skidt.
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 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.
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.
Derfor var det vores opgave at bidrage til processen og i fællesskab 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.
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
Du tror I har DR, men har I i virkeligheden bare backup`?
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.
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.
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.
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 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.
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).
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.
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å: