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å:
- Du tror, I har Disaster Recovery — men har I i virkeligheden bare backup?
- Sådan designer du en disaster recovery plan i tre trin
- Få styr på jeres RPO
Hvad er DR?
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.
Forskellen mellem B&R og DR:
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.
- Backup & Recovery relaterer sig til daglig drift: Sten fra Salg sletter vigtige kundedata. I genskaber dem.
- Disaster Recovery relaterer sig til deciderede nedbrud eller udfald: Strømmen går i jeres datacenter (eller på jeres servere specifikt). I kører videre fra et andet center.
Med det på plads, kan vi kigge på, hvordan en DRP fungerer i praksis.
Sådan fungerer en Disaster Recovery Plan
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.:
Eksempel
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:
-
- Hvilke systemer og data er mest kritiske for vores virksomhed?
- Hvilke sårbarheder eksisterer i vores nuværende IT-infrastruktur?
- Er vores backup-løsninger tilstrækkeligt sikret mod tab og kompromittering?
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.
-
- Hvad er de økonomiske og operationelle konsekvenser af et nedbrud/udfald?
- Er de potentielle risici afbalanceret mod omkostningerne ved at implementere yderligere backup?
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.
Disaster Recovery-politikker:
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.
- RTO: Recovery Time Objective er et begreb, der dækker over målet for maksimal nedetid. En virksomhed, der leverer finansielle tjenester, kan have et RTO på for eksempel 2 timer for sine online banktjenester. Det betyder, at tjenesterne skal være genoprettet og operationelle inden for 2 timer efter en afbrydelse.
- RPO: Recovery Point Objective er et begreb, der dækker over målet for maksimalt datatab. Hvis virksomheden har et mål om, at der maksimalt må tabes 30 minutters data på kunderne, så vil de altså have en RPO på 30 minutter for de workloads, som håndterer dataene.
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
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?
- Er alle workloads inkluderet i vores Disaster Recovery Plan?
- Er vores netværk designet til at håndtere en fuld eller delvis Disaster Recovery Plan?
- Hvad er vores fall back-plan?
- Hvor længe kan vi tolerere nedetid? (RTO)
- Hvor meget data kan vi tillade os at miste? (RPO)
- Hvordan aktiveres vores Disaster Recovery Plan?
Udvidet
Udvidet politik – nogle systemer er superkritiske: Spørg dig selv: Hvor tilgængelige skal specifikke systemer og data som minimum altid være?
- Skal det her specifikke workload have Disaster Recovery aktiveret?
- Hvis ja:
- kan vi udføre fuld / delvis netværksoverførsel, eller skal vi ændre IP'er?
- hvordan håndterer vi failbacks?
- hvor længe kan vi tolerere nedetid? (RTO)
- hvor meget data kan vi tillade os at miste? (RPO)
- hvordan aktiverer vi politikken?
Konklusion
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.
Vi hjælper dig
Er du nysgerrig på at høre mere? Så er vi klar til at snakke. Klik på linket herunder for at blive kontaktet.
