Er Disaster Recovery en god idé? Det kan du tro. En (amerikansk) undersøgelse af Uptime Institute viser nemlig, at 93% af virksomheder, som må undvære deres data i op til 10 dage, går konkurs inden for et år. Det kan I heldigvis undgå med en god Disaster Recovery Plan (DRP).
Herunder får du vores bud på, hvad jeres Disaster Recovery Plan bør indeholde, og hvordan du designer en i tre trin.
1. Nedbrud sker (så meget koster de jer)
2. Hvad er en Disaster Recovery Plan – og hvad er den ikke?
Backup er ikke det samme som Disaster Recovery
Sådan fungerer en Disaster Recovery Plan
3. Hvad består en Disaster Recovery Plan af?
4. Skabelon i 3 trin: Sådan designer du en Disaster Recovery Plan
6. Disaster Recovery as a Service
Lad os sige, at du sidder i lufthavnen. Du har ferie, og poolen er kun en flyvetur væk. Du nyder din kulsorte kaffe fra Espresso House, og pludselig summer din telefon. Højere end den plejer. Du har en dårlig mavefornemmele, men tager den alligevel.
Der er panik i den anden ende. ”Den er helt gal!” bliver der nærmest råbt. "Alle vores systemer er nede – vi kan intet foretage os.”
Dårlig timing. I har ikke råd til nedetid. Du ringer straks til jeres cloud-udbyder. “Vi skal have vores systemer op at køre igen – helst i går!”
Din direktør forsøger at ringe til dig.
”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, og feriehumøret er væk — ligesom jeres data.
Hvad gør du nu?
Nu er hele virksomheden lammet, og du sidder der — 5 minutter i boarding — uden mulighed for at aktivere jeres Disaster Recovery Plan. For I har ingen. Og det kan altså blive en rigtig dyr omgang.
For nedbrud — eller bare et simpelt udfald på jeres servere — koster kassen.
Vi kan sige så meget, at hvis vi selv oplevede nedbrud eller udfald på ét datacenter, så ville det koste os ca. 22.000 kr. i timen.
Det er ikke småpenge.
Og nedbrud (eller udfald) sker jævnligt, uden at I kan gøre så meget ved det.
Det kan være på grund af:
Listen af potentielle årsager til nedbrud og udfald er lang.
Her er nogle tal fra Uptime Institute, som helt sikkert er MEGET amerikanske og næppe repræsentative for Danmark, men som vi alligevel synes peger på en tankevækkende tendens.
Statistik om nedbrud i datacentre (kilde) .
Uanset om I er mere eller mindre sårbare, så er det værd at overveje, om I — ligesom du forsikrer din bil, dit hus og dig selv — skal forsikre jer mod potentielt kritiske nedbrud/udfald og datatab.
Men hvad er en DRP så, og hvordan kan den redde jeres IT i praksis?
Lad os kigge på det.
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.
Dårlige nyheder —
Det kan de ikke.
Så lad os lige slå det fast med syvtommersøm: Backup er ikke nok i tilfælde af nedbrud eller udfald.
Forskellen mellem B&R og DR er, at:
Myth busted.
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 det og fortsætte driften af jeres kritiske systemer, selv hvis jeres production site skulle blive ramt af en meteor.
*Funktionerne på jeres Disaster Recovery site kan være en 1:1-kopi af funktionerne på jeres production site
Som udgangspunkt anbefaler vi vores kunder at kopiere produktionsmiljøet 1:1, fordi de så kan 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.
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 Plan, 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.
Hvordan I ønsker at være beskyttet, definerer I selv i jeres Disaster Recovery-politikker.
Dem kommer vi til om lidt.
De skal nemlig udarbejdes på baggrund af jeres analysearbejde, som er vi kan betegne som del 1 af i alt 3 dele.
Del 1: ANALYSE
Før I kan definere jeres Disaster Recovery politikker er der to analyser, som I bør basere dem på:
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 beskytte dem bedre end mindre kritiske workflows.
Del 2: Praksis
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.
En undersøgelse fra Veeam viser, at 82% af virksomheder ved, at de ikke kan leve op egne krav om RPO og RTO. Vores gæt er, at 9/10 danske virksomheder slet ikke kender deres krav.
Kender du jeres?
Skabelonen ovenfor er et godt sted at starte, når du skal kende den. Men vi tager selvfølgelig også gerne en uforpligtende snak med dig.
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.
↓
Book en snak om Disaster Recovery i vores kalender her
I dette blogindlæg gennemgår vi de væsentligste hovedtræk fra den nye persondataforordning (også kaldet GDPR), som træder i kraft den 25. maj 2018....
Læs vores praktiske guide i Hjemmesideprogrammet. Lær, hvordan du laver din egen hjemmeside. Det er nemt og hurtigt. Download en demo og kom online i...
Office 365 er fantastisk, men giver dig ikke rigtig backup af dine data. Har du brug for andre grunde til at få Office 365 Backup?
