Alt for få virksomheder har en plan for, hvordan de kommer op at køre igen ved et nedbrud. Men planen er én ting. Den tekniske løsning en anden. Her er vores bud på, hvordan du designer en DR-plan og -løsning i tre trin.
Men først —
Forestil dig, at du sidder i lufthavnen. Du har ferie. Poolen er kun en flyvetur væk. Du nyder din kulsorte rejsekaffe. Men pludselig summer din telefon. Du har en dårlig mavefornemmelse, men tager opkaldet:
Det er jeres CEO.
”Hey. Den er helt gal med vores IT! Alle vores systemer er nede – vi kan intet foretage os. Hvad sker der? Hvad gør vi?"
Du må være svar skyldig, indtil du har snakket med jeres cloud-leverandør. Du afslutter hurtigt samtalen og ringer dem op.
“Vi er nede. Vi skal op og køre igen – helst i går. Hvornår er vi klar igen?”
”Vi gør vores bedste, men der kan gå dage — måske uger — før vi er oppe at køre igen”, lyder det undskyldende i den anden ende.
Kort pause …
Du har spildt kaffe på dine sko.
Jeres data er væk.
Hvad gør du nu?
Okay, risikoen for, at hele jeres datacenter går ned — eller I bliver rendt over ende af hackere — er temmelig lille. Men den er bestemt tilstede. Og derfor er det noget skidt at mangle en plan for, hvordan I kommer op at køre igen, hvis sol, måne og hjerner skulle stå skævt.
Altså en Disaster Recovery Plan — som er noget helt andet end backup.
Planen i sig selv er ikke den faktiske tekniske løsning, altså infrastrukturen, men infrastrukturen (eller DR-løsningen) kan være en del af jeres plan.
Lad os dykke ned i, hvordan du designer en plan i tre trin.
“Min erfaring siger mig at 9 ud af 10 små og mellemstore virksomheder i Danmark ikke har nogen som helst Disaster Recovery plan. Alt for mange sætter deres lid til, at deres leverandør nok har styr på den slags, men virkeligheden er, at hvis man ikke har prøvet at lave en Disaster Recovery-test, så har man absolut ingen forudsætning for at vide, om man overhovedet kan få virksomhedens IT genetableret inden for en acceptabel tidsramme.”
Kasper Hartvig Hansen, Technical Account Manager hos ScanNet
Læs også: Hvad er en disaster recovery plan — og hvad er den ikke?
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, hvor I har indtænkt en DR-løsning som en del af jeres plan.
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 det og fortsætte driften af jeres kritiske systemer, selv hvis jeres production site skulle blive ramt af en meteor.an køre videre som normalt.
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.
Før I kan definere jeres Disaster Recovery politikker er der to analyser, som I bør basere dem på:
1. 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:2. 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.
Så, 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?
Har I superkritiske workflows, som tolererer 0 nedetid? Så kan I vælge at beskytte dem bedre end mindre kritiske workflows.
Nu ved du, at der er tre ting, I skal have styr på, før I designer jeres Disaster Recovery Plan:
Så langt, så godt.
Nu er det tid til at udfylde nogle skemaer med jeres tanker, så I ved, hvad I har at arbejde med.
Vores skabelon til DRP består af tre elementer.
Herunder er eksempler på kortlægning af bekymringer, krav og funktioner.
Trin 1 er er en kortlægning af de trusler, I har vurderet som sandsynlige, og som I derfor ønsker at bolstre jer mod. Her ser du et udpluk af potentielle bekymringer, du kunne have, som jeres DRP skal kunne håndtere.
Bekymringsmatrix
|
Eksempler på dine bekymringer |
Mininimumsanbefalinger |
|
Jeg er bekymret for nedetid på vores primære site og vi kan ikke acceptere at være offline i dagevis. Fra det øjeblik jeg iværksætter failover, til tingene kører "normalt" igen (forudsat grundig forberedelse), skal vores samlede nedetid være under 4 timer.
|
Replikér workloads fra enten Backup eller Produktion til en separat AZ. Kilden til replikationen er produktionsmiljøet. |
|
Jeg er bekymret for tabet af en AZ. Jeg kan ikke være offline i dagevis. Fra det øjeblik, jeg vælger at fejlovere, til tingene kører "normalt" igen (forudsat tilstrækkelig forberedelse), bør det være under 4 timer.
RPO matcher min Backup & Recovery RPO. |
Repliker workloads fra enten Backup eller Produktion til en separat AZ. Kilden til replikationen kan enten være produktionsmiljøet eller backup'en. |
|
Jeg er bekymret for tabet af en AZ. Jeg kan ikke være offline i flere dage. Fra det øjeblik jeg vælger at failover, til tingene kører igen (forudsat tilstrækkelig forberedelse), bør det være under 24 timer. Fuld genopretning af workloads med "normal" ydeevne er inden for dage. RPO matcher min Backup & Recovery RPO |
Gem backup på "Backup med høj performance". Boot fra backup til DR-siteti tilfælde af en katastrofe. Gendan i baggrunden. |
|
Jeg vil gerne kunne performe failover/failback af individuelle sub-miljøer uden ændret IP-adressering. |
Source Network skal opbygges og designes baseret på dette. |
|
Jeg ønsker at have en global failover/failback-politik. Hvis noget flytter sig, flytter alt sig. |
Ingen krav til source network-miljøet. |
|
Jeg er bekymret for tabet af en AZ, men min virksomhed kan overleve i op til 7 dage, før mine tjenester kan genoprettes. |
Sørg for at have konfigurerede backups. |
Her er et udpluk af de krav, du kunne have til RPO og RTO (som defineret i jeres politikker) - per workflow eller over en bred kam for alle jeres workflows ud fra de samme mål.
Kravsmatrix
|
Krav |
Minimumsanbefalinger |
Noter |
|
= 24-timers RPO |
Snapshot-baseret replikation med Source fra Backup |
|
|
=> 12-timers RPO |
Snapshot-baseret replikation med Source fra Backup / VAIO/CDP-baseret med Source fra Production |
Afhænger af Backup & Recovery RPO. |
|
< 12-timers RPO |
VAIO/CDP-baseret med Source fra Production |
|
|
< 30-minutters RTO med Background Restore |
Dedikeret Disaster Recovery-miljø + Backup med høj performance |
Fra det tidspunkt, hvor DR-politikken aktiveres. |
|
< 30-minutters RTO uden Restore |
Dedikeret Disaster Recovery-miljø + SAN Storage |
Immutable backup kan komme med ekstra licensomkostninger. |
Når I har styr på krav og bekymringer, så kan I (sammen med jeres cloud-leverandør) kortlægge hvilke IT-funktioner, der kunne være relevante for jer.
Her er et udpluk af funktioner. I kolonnen til venstre ser du produktet. Til højre ser du en beskrivelse af produktet og dets funktion .
Funktionsmatrix:
|
Produkt |
Beskrivelse |
|
Firewall |
En virtuel firewall er allerede opsat og konfigureret med minimale ændringer, der er nødvendige for at gå i reel produktion. |
|
Server med indbygget storage |
Én (eller flere) selvstændige servere med lokal lagring er klar til at køre workloadet, hvis det er nødvendigt. Workloadet kan enten allerede være til stede på serveren i en lukket tilstand eller kan gendannes fra backup, når det er nødvendigt. |
|
Server med SAN storage |
Én (eller flere) selvstændige servere med SAN-lagring af data som er klar til at køre, hvis det er nødvendigt. Data kan enten allerede være til stede på SAN i en lukket tilstand eller kan gendannes fra backup, når det er nødvendigt. |
|
Cluster = internt forbundne virtuelle maskiner eller servere |
En konfigureret cluster er klar til at køre workloadet, hvis det er nødvendigt. Workloads kan enten allerede være til stede på værten i en lukket tilstand eller kan gendannes fra backup, når det er nødvendigt.
|
|
Replikation – fra Backup |
Replikation til en anden AZ (Availibilty zone) baseret på den seneste nuværende backup af produktions-AZ'en. Dette begrænser RPO for katastrofeberedskab til RPO for backup og gendannelse. |
|
Replikation – Fra Produktion (Snapshot) |
Replikation til en anden zone eller et andet datacenter baseret på den seneste backup af produktions-AZ'en. Det begrænser naturligvis dine muligheder for at minimere nedetid. |
|
Replikation – Fra Production (VAIO CDP) |
Kontinuerlig Replikation til en anden AZ baseret på den seneste aktuelle produktionsstatus for produktions-AZ'en. Her opnår du minimal nedetid, da data replikeres kontinuerligt. Løsningen har ingen eller minimal indvirkning på workloadet, men kræver yderligere ressourcer fra infrastrukturen. Du må forvente øget forbrug af ressourcer (CPU og RAM) |
Del 3: Test, test, test
Planer er fine at have — men hvis I ikke efterprøver dem, er de formentlig ligeså værdiløse som en paraply i en orkan . Planen skal afprøves i sin helhed, mindst én gang. Og så kan I årligt afprøve tilfældige delelementer af planen.
For det er i virkeligheden ret “nemt” at replikere alle jeres data —men ikke nødvendigvis nemt at få det hele til at virke igen.
Der er også en firewall-konfiguration (og andet). der skal virke på DR-sitet.
Så selvom der er en god sandsynlighed for at komme online igen, hvis bare I har alle jeres data, så er det hamrende træls at finde ud af, at Í havde glemt at patche firewallen på DR-sitet, så den backupkonfiguration (som I faktisk har husket at tage) ikke kan gendannes, før I har udført 27 firewall-updates ...
Hvis I udfører regelmæssige tests, kan I dokumentere alle de manuelle processer, der skal til for at det hele virker.
Tip: det kan passende være et årligt punkt på bestyrelsesmødet, at I gennemgår resultatet af DR-testen og vurderer, om I er tilfredse med jeres faktiske restore-tid.
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. Det er op til jer (og jeres pengepung og risikovillighed) at definere I jeres Disaster Recovery-politikker.
I ScanNet skelner vi mellem en baseline-politik eller en udvidet politik. Ved en Baseline politik skærer I alle workloads over samme kam med ét mål for maksimal nedetid og maksimalt datatab, Ved en udvidet politik definerer i maksimal nedetid og maksimalt datatab per workload.
Overvejer du, om I skal have Disaster Recovery? Så kan vi hjælpe. Vi tilbyder nemlig Disaster Recovery as a Service.
Vi snakker meget gerne jeres situation i gennem og kommer med vores anbefalinger, hvis du har lyst.