Vi oplever mange – både IT-folk og C-suites – som tror, at deres systemer sagtens kan genskabes ved nedbrud, fordi virksomheden har en effektiv backup-plan.
Det kan de ikke nødvendigvis. Så lad os lige slå det fast med syvtommersøm: Backup er ikke altid nok ved et nedbrud eller udfald. Derfor har I brug for en DR-plan.
Så her er, hvad en disaster recovery plan er — og hvad den ikke er.
Backup er ikke nok i tilfælde af nedbrud eller udfald.
Læs også:
Disaster recovery er jeres IT-forsikring. En måde at sikre, at I altid kan køre videre, selv hvis jeres produktionsmiljø skulle blive ramt af en meteor.
Det kan i princippet være en 1:1 replikation er jeres produktionsmiljø, som bare kører på et andet site, og som hverken er fysisk eller virtuelt forbundet med jeres produktionsmiljø.
Når I får brug for det, så kan I tænde for miljøet og køre videre.
Det hele giver mening, når du kigger i det her cheatsheet, hvor vi har kortlagt forskellene mellem backup, disaster recovery og availibility.
Disaster recovery er altså ikke bare et andet ord for backup. De er to forskellige ting med mange overlap. Men de er ikke ens, selvom mange forveksler dem.
Med det på plads, kan vi kigge på, hvordan en DRP fungerer i praksis.
Helt lavpraktisk kan en DRP være så simpel, at ved et nedbrud, så styrter Hans Jørgen ned i Elgiganten og køber en ny PC, som han kan arbejde videre fra.
Men det er næppe nok i jeres tilfælde. Så lad os i stedet fokusere på, hvordan en DRP fungerer i større skala, hvor I er afhængige af et eksternt datacenter. Altså som DraaS — Disaster Recovery as a Service.
Her består DRP'en ofte af en række IT-funktioner, som holder jer kørende på et dedikeret Disaster Recovery Site, hvis jeres Production site skulle gå ned.
Disaster Recovery sitet kører parallelt med jeres production site på en anden fysisk lokation, bare på lavt blus og til en brøkdel af prisen.
Når I får brug for det, kan I aktivere DR-sitet og fortsætte driften af jeres kritiske systemer, selv hvis jeres production site skulle blive ramt af en meteor.
Som udgangspunkt anbefaler vi vores kunder at kopiere produktionsmiljøet 1:1, fordi de så kan køre videre som normalt. Men det er ikke altid optimalt på grund af prisen.
Men det kan også være, at I har defineret nogle systemer, som er superkritiske. Så kritiske, at hvis de går ned, så lukker virksomheden i værste tilfælde. De systemer kan I vælge at beskytte mere end andre.
Samtidig kan det gå hen og blive alt for dyrt. Jo tættere jeres RPO og RTO kommer på 0, desto dyrere er det nemlig at holde jeres Disaster Recovery-løsning kørende. Og så handler det om at prioritere eller splitte jeres data yderligere op.:
Lad os sige, at en dansk bank skulle lægge en Disaster Recovery Plan.
De har mange IT-systemer — men langt fra alle er lige kritiske. Nogle er til gengæld så kritiske, at hvis de går ned, så lukker banken. Det kunne være systemer, som indeholder data om konti, kunder, pengebeholdninger og transaktioner.
Derimod er deres interne intranet mindre vigtigt. Hvis det går ned, kan medarbejderne ikke melde sig til julefrokosten, og Hanne fra HR må håndtere de sure miner i en rum tid. Det går nok (selvom det er synd for Hanne).
Banken beslutter derfor at beskytte deres kernebankplatform med en Disaster Recovery-løsning, der lover 0 minutters datatab og 0 minutters nedetid. Intranettet beskyttes med en enklere løsning med daglige backups og maksimal nedetid på 72 timer.
På den måde sikrer banken, at de kan køre videre under en krise — men ikke bruger flere penge på løsningen end nødvendigt.
Hvad består en Disaster Recovery Plan af?
Hvis det ikke er nok, at Hans Jørgen smutter i Elgiganten efter en ny computer, så består en disaster recovery plan typisk af en beskrivelse af de interne rolle og ansvarsområder under et nedbrud. Hvem gør hvad? Og så også en teknisk løsning, som får jer opat køre igen.
Den tekniske løsning skal designes på baggrund af jeres disaster recovery politikker, hvor I i ledelsen definerer jeres RPO og RTO. Og før I kan det, skal I lave en risikovurdering og en business impact analyse.
Risikovurdering: I kan forsikre jeres IT til op over skorstenen. Men det koster også derefter. Derfor bør I lave en risikovurdering af potentielle trusler og en vurdering af, hvor sandsynlige de er, inden I definerer jeres DR-politikker:
Business Impact Analyse (BIA): Baseret på risikovurderingen kan I så analysere de potentielle konsekvenser af et nedbrud.
Hvis system 1 er utilgængeligt, skal I så lukke hele forretningen, mens I sagtens kan undvære system 2 i en rum tid? Så skal system 1 måske køre videre med 0 minutters nedetid og 0 minutters datatab, mens system 2 kan tolerere væsentligt mere. Ligesom i eksemplet med banken.
Tænk over, om I har nogle særligt kritiske systemer, som I overhovedet ikke kan undvære, mens der er andre, som er mindre kritiske — og definér så i jeres politikker, hvor meget nedetid og datatab, I kan tolerere per system.
Jeres Disaster Recovery-politikker afgør, hvilke produkter/services I i sidste ende har brug for, for at kunne opretholde et fornuftigt niveau af drift og data i tilfælde af nedbrud.
Produkter kunne for eksempel være:
Hvilke produkter, I helt konkret har brug for, afhænger af de mål for maksimal nedetid (RTO) og datatab (RPO), som I har defineret i jeres politikker.
Med styr på risikoanalyse, BIA, RPO og RTO kan du nu udarbejde jeres politikker. Vi skelner i ScanNet mellem to typer af politikker — en baseline og en udvidet politik.
Baseline-politik bruges, hvis alle systemer er lige (u)kritiske: Spørg jer selv: Hvad er vores baseline (minimumskrav) til Disaster Recovery på ethvert tidspunkt?
Udvidet politik – nogle systemer er superkritiske: Spørg dig selv: Hvor tilgængelige skal specifikke systemer og data som minimum altid være?
En god Disaster Recovery Plan kan redde jeres IT – og i yderste potens jeres virksomhed – i tilfælde af nedbrud eller udfald. DRP’en består konkret af en række IT-systemer, som kører parallelt med jeres produktionssystemer, men på lavt blus. Ved nedbrud aktiveres de på fuldt blus, så I kan køre videre som "normalt".
I kan vælge at kopiere jeres production site 1:1. Men I kan også håndplukke, hvilke workloads der skal være dækket af Disaster Recovery – og hvad den maksimale nedetid (RTO) og det maksimale datatab (RPO) må være per workload.
Er du nysgerrig på at høre mere? Så er vi klar til at snakke. Klik på linket herunder for at blive kontaktet.