Hur man skapar en plan för katastrofåterställning (Disaster Recovery Plan)

Plan för katastrofåterställning Banner

I informationstekniska termer är en katastrof varje typ av händelse som stör nätverket, äventyrar data eller gör att den normala verksamheten saktar ner eller upphör. En katastrofåterställningsplan (DRP) skapas för att hantera riskerna och möjligheterna med dessa typer av händelser och för att minimera den skada de orsakar.

Vanliga katastrofer som ingår i en DRP är bland annat:

Skadlig aktivitet/cyberattacker.

Skadliga aktörer, skadlig kod, virus och hot från insiders kan lätt orsaka dyra driftstopp och dataförluster. Eftersom cyberattacker blir allt vanligare månad för månad tenderar DRP:er att fokusera mycket på detta riskområde. 

Strömavbrott.

Verksamheten måste kunna gå vidare även vid avbrott, särskilt om de är långvariga och kaotiska, vilket är fallet efter många naturkatastrofer. 

Fel på utrustningen.

Även om ditt IT-team arbetar hårt för att hålla allting igång är det viktigt att ha planer för omkoppling om något skulle gå fel.

Undantagstillstånd.

Före 2022 hade många organisationer inga bestämmelser för en global pandemi i sin katastrofplanering, vilket visar varför det är klokt att planera för de mest uppenbara scenarierna, och inte bara för de mest uppenbara. 

Din katastrofåterställningsplan bör faktiskt vara ganska omfattande och inte bara omfatta scenarier som du tror är mycket sannolika att inträffa.

I den här artikeln ska vi undersöka detta och andra viktig fakta om katastrofåterställningsplanering. 

Den här artikeln kommer att omfatta följande:

  • Vad är en plan för katastrofåterställning (DRP)?
  • Fyra typer av IT-katastrofåterställningar
  • De viktigaste delarna av en DRP
  • Steg för att skapa en plan för katastrofåterställning (DRP)?

Vad är en plan för katastrofåterställning (DRP)?

En katastrofåterställningsplan för IT är ett formaliserat dokument som en organisation skapar för att kodifiera policyer och förfaranden som svar på en katastrof. Den fokuserar på sektorer som är relevanta för IT, t.ex. att hålla nätverket och VoIP-telefonsystemen online eller att skydda känsliga data med hjälp av säkerhetskopieringspolicyer. DRP är en del av organisationens kontinuitetsplan (BCP) och måste också testas och uppdateras regelbundet för att säkerställa att IT-teamet kan lyckas med återställningsarbetet oavsett vilken typ av katastrof det rör sig om. 

DRP anses vara viktiga eftersom de minimerar riskexponering, minskar störningar och säkerställer ekonomisk stabilitet. En väl utformad och robust plan kan också minska försäkringspremier och potentiellt ansvar samt säkerställa att din organisation uppfyller lagstadgade krav. De potentiella besparingarna kan vara chockerande när man väl har fastställt hur stor ekonomisk risk man faktiskt löper utan en katastrofåterställningsplan. 

För att avgöra hur mycket en katastrof kan kosta din organisation behöver du bara tänka på kostnaden för systemavbrott och förlorade data. Hur många försäljningar skulle gå förlorade om webbplatsen eller telefonsystemet var nere i flera dagar? Hur många fakturerbara timmar skulle gå förlorade om en veckas dokument raderades av misstag? För företag med mer än ett fåtal personer kan dessa siffror växa exponentiellt mycket snabbt.

Fyra typer av katastrofåterställningar

Fildelning är ett utmärkt produktivitetsverktyg, men det vi verkligen vill veta är säkerhet och trygghet. Detta är området för säkerhetskopiering av data och filåterställning. 

1) Katastrofåterställning av datacenter

Den här typen av katastrofåterställning omfattar hela byggnaden där datorsystemet är inrymt – datacentret. Det omfattar alla funktioner och verktyg i byggnaden, t.ex. fysisk säkerhet, supportpersonal, reservkraft, HVAC, verktyg och brandbekämpning som måste vara tillförlitliga och fungera. Det kan också inkludera redundanser som håller systemen igång vid isolerade avbrott. Planeringen av denna typ av DR kan vara mycket kostsam eftersom den omfattar många fysiska och platsbaserade kostnader och underhåll. 

2) Molnbaserad katastrofåterställning

Detta innebär att all börda för installation och underhåll av webbplatsen flyttas över till molnleverantören genom att deras datacenter används genom ett licensavtal eller kontrakt. Även om detta avsevärt minskar komplexiteten och kostnaderna för slutanvändaren är det mer begränsat än att helt äga ett datacenter. I de flesta fall är kostnadsbesparingarna med säkerhetskopiering och återställning i molnet uppväger vida de friheter som offras genom att inte ha ett eget datacenter.

3) Virtualisering katastrofåterställning

Virtualisering är mycket populärt, särskilt i en tid då virtuella maskiner blir allt vanligare på grund av förändringar i arbetsstyrkan. Detta tillvägagångssätt innebär att man inte behöver rekonstruera en fysisk server i händelse av en katastrof, vilket gör det mycket lättare att nå målen för återställningstiden (RTO) genom att placera en virtuell server i reservkapacitet eller i molnet.

4) Katastrofåterställning som en tjänst

Disaster Recovery as a Service (DRaaS) är ett utlokaliserat sätt att säkra IT-katastrofåterhämtning med hjälp av en rad olika tillvägagångssätt. DRaaS kan tillhandahållas via molnet eller som en plats-till-plats-tjänst. Leverantörerna kan bygga om och skicka servrar till en kund som en del av en serverutbytestjänst, eller så kan de använda molnet för att växla om program, organisera återkoppling till ombyggda servrar och återansluta användare via VPN eller Remote Desktop Protocol.

Viktiga delar av en katastrofåterställningsplan

Nedan följer några viktiga delar som bör ingå i planeringen av katastrofåterställning. 

  • Bedömning av verksamhetens konsekvenser

En bedömning av verksamhetskonsekvenserna bör göras innan DRP skapas. Denna omfattande bedömning utvärderar företagets kritiska system och hur man prioriterar återställandet av dessa system.

  • Mål för återhämtningspunkt (RPO) och mål för återhämtningstid (RTO)

Ett RPO fastställer den acceptabla mängden data som ett företag kan riskera att förlora och används för att definiera frekvenser för säkerhetskopiering. RTO innebär att man beräknar och sätter upp mål för hur lång tid det kommer att ta att återställa ett system efter en katastrof.

  • Lagringsplats utanför anläggningen

Backupservrar, hårdvara och annat material som behövs för katastrofåterställningsprocessen bör lagras på en plats som ligger utanför huvudkontoret. Hur långt bort eller på hur många olika platser beror på vilka katastrofscenarier du planerar för. Om den primära anläggningen till exempel ligger i ett område som är utsatt för översvämningar kan det hända att den externa anläggningen måste ligga hundratals kilometer bort. 

Läs vår guide för backup-lösningar för att lära dig mer om hur du kan använda molnbaserade lösningar för säkerhetskopiering och återställning av data för att tillgodose detta behov.

  • Kommunikationsplan

En DRP bör underlätta snabb och enkel kommunikation mellan alla anställda och tjänsteleverantörer som är nödvändiga för återhämtningsprocessen. Den bör också fastställa och definiera rollerna och ansvaret för alla under en katastrof.

  • Tydlig och direkt instruktion

De bästa DRP:erna är indelade i checklistor som kan användas så att användarna inte behöver läsa igenom hundratals sidor när de reagerar på en omedelbar fara. 

Nio steg för att skapa en plan för katastrofåterställning

Alla företag behöver en plan för katastrofåterställning som är lika unik som dess datakrav. För att fastställa det bästa tillvägagångssättet för ditt företag måste du väga värdet av dina data, system och applikationer mot den risk som din organisation har råd att ta. När du skapar en katastrofåterställningsplan ska du se till att följande steg ingår:  

1) Få ett engagemang i hela organisationen

Alla i organisationen måste känna till och kunna stödja och genomföra återhämtningsplanen. Korrekt planering börjar i toppen, eftersom ledningen/ägarskapet själva måste stödja och vara involverade i utvecklingen av processen för katastrofåterställningsplanering och se till att tillräckliga resurser ges till uppgiften. 

2) Skapa en planeringskommitté

En grupp av intressenter bör organiseras för att övervaka utvecklingen och genomförandet av katastrofåterställningsplanen. Planeringskommittén bör bestå av representanter från alla funktionella områden i organisationen samt nyckelpersoner från relevanta sektorer som IT och verksamhetsledning.

3) Utföra en riskanalys och en analys av affärseffekter

DRP-kommittén bör förbereda både en riskanalys och en analys av verksamhetens konsekvenser för att fastställa utgångspunkter för planeringen. Dessa utvärderingar bör omfatta en rad olika katastrofer, inklusive naturliga, tekniska och mänskliga hot. Varje sektor inom organisationen bör analyseras för att fastställa det potentiella hotet och konsekvenserna av sannolika katastrofscenarier. 

Problemet med denna funktion är att vanliga utpressningstrojaner och krypteringsattacker vanligtvis byter namn på och krypterar filer på offrets hårddiskar. Detta görs avsiktligt för att kringgå versionshistoriken och papperskorgen så att det inte är lätt att återställa filerna. 

4) Prioritera verksamheten

Varje avdelnings kritiska behov bör utvärderas inom områden som personal, data/dokumentation, politik, tjänster och behandlingssystem.

Det är viktigt att fastställa hur länge en avdelning maximalt kan fungera utan varje kritiskt system. Planeringskommittén bör också fastställa kritiska behov för varje avdelning för att bättre kunna prioritera återhämtning och fördelning av nödresurser. All verksamhet bör rangordnas som väsentlig, viktig eller icke väsentlig beroende på hur prioriterad den är.

5) Kodifiera återhämtningsstrategier

Praktiska alternativ för förlorade eller nedlagda IT-resurser i händelse av en katastrof bör undersökas och utvärderas. Det är viktigt att ta hänsyn till alla normala aspekter av verksamheten när man väljer dessa reservdatorer eller redundanser. 

Den här delen av planen innehåller vanligtvis detaljerad information om inköp och underhåll av verktyg och resurser för nödsituationer (t.ex. lösningar för säkerhetskopiering och återställning av data) samt om personal och andra överväganden som krävs för att hålla dem i beredskap.

6) Utför datainsamling

Viktiga uppgifter bör samlas in och lagras. Rekommenderad datainsamling kan omfatta följande:

Dokumentation om säkerhetskopiering och återställning

  • Viktiga telefonnummer
  • Inventering av hårdvara för kommunikation
  • Intern dokumentation 
  • Loggar för förvaltning av tillgångar 
  • Försäkringar
  • Inventering av nätverkshårdvara
  • Kontaktlista för huvudleverantörer
  • Checklista för anmälan
  • Inventering av lagringslokaler utanför anläggningen

7) Organisera och dokumentera en skriftlig plan

Planen bör innehålla alla detaljerade förfaranden som ska användas före, under och efter en katastrof. Detta inkluderar en policy för underhåll och uppdatering av planen för att återspegla alla betydande förändringar inom organisationen, samt en regelbunden granskningsprocess.

För att underlätta distributionen är DRP:erna vanligtvis strukturerade i grupper och har delegerat ansvarsområden. Ledningsgruppen är särskilt viktig eftersom den samordnar återhämtningsprocessen. 

Det bör finnas grupper som ansvarar för viktiga funktioner, t.ex:

  • Administrativa funktioner
  • Anläggningar och verksamhet
  • Försörjningskedja och logistik
  • Användarstöd/kundtjänst
  • Backup av datorer och IT
  • Återställande av tjänster

8) Testa planen

Alla beredskapsplaner bör testas och utvärderas regelbundet. Förfaranden för att klara dessa tester bör dokumenteras noggrant. Utan testning är det omöjligt att veta om alla aspekter av ett nödsituationsscenario har behandlats i DRP:n förrän det är för sent. 

Ett första test ger återkoppling om eventuella ytterligare steg som kan behöva inkluderas, ändringar av förfaranden som inte är effektiva och andra justeringar för att förbättra effektiviteten. Testerna kan bestå av checklistor, simuleringar eller verkliga strömavbrott. Naturligtvis är det bäst att göra dessa tester utanför arbetstid för att minimera störningar i organisationen.

9) Godkännande och genomförande

När katastrofåterställningsplanen har utarbetats och testats grundligt bör planen godkännas av organisationens ledning.

Ledningen är ansvarig för:

  • Fastställande av riktlinjer, förfaranden och ansvar för katastrofplanering samt inledande bildande av kommittén
  • Granska och godkänna beredskapsplanen årligen, samt dokumentera granskningar och tester av ansvarsskäl och för att säkerställa efterlevnad
  • Säkerställa att DRP är kompatibel med eventuella IT-leverantörer och tjänsteleverantörer

Slutsats

Att skapa en plan för katastrofåterställning kan vara avgörande för att en organisation som är beroende av teknik ska kunna överleva. Framgångsrik planering innebär att hitta katastrofåterställningslösningar som passar dina unika IT-krav och som är praktiska att hantera och testa. 

Många små och medelstora företag väljer att samarbeta med leverantörer av hanterade tjänster (MSP) för att kompensera bördan av specifik expertis, medan andra vänder sig direkt till verktyg som NinjaOne som gör det möjligt för dem att utnyttja specialbyggd teknik för att förenkla IT-katastrofåterställning. Sådana verktyg gör det extremt enkelt att ställa in säkerhetskopior, testa failovers och starta upp nya system efter en katastrof. 

Oavsett om din organisation vill behålla IT-administrationen internt eller lägga ut den på entreprenad ger NinjaOne dig möjlighet att säkerställa kontinuitet i verksamheten genom snabb växling av kritiska arbetsbelastningar till våra säkra fjärrdatacenter. I händelse av en katastrof kan du lita på omedelbar datatillgänglighet och fungerande system tack vare en molnbaserad infrastruktur som är tillräckligt motståndskraftig för att tusentals NinjaOne-användare och IT-leverantörer ska kunna lita på den. 

Oavsett vilken osäkerhet du kan råka ut för kommer NinjaOne att vara en värdefull del av din plan för katastrofåterställning (RDP). Är du redo att se fördelarna med egna ögon kan du anmäla dig till en kostnadsfri provperiod idag.

Nästa steg

För att bygga upp ett effektivt och handlingskraftigt IT-team krävs en centraliserad lösning som fungerar som ett centralt redskap för att leverera IT-tjänster. NinjaOne gör det möjligt för IT-teams att övervaka, hantera, säkra och stödja alla sina enheter, oavsett var de befinner sig, utan behovet av en komplex infrastruktur på plats.

Lär dig mer om NinjaOne endpoint-hantering, ta en live tour, eller starta en gratis provperiod av NinjaOne.

Du kanske även gillar dessa inlägg

Redo att bli en IT-ninja?

Ta reda på hur NinjaOne kan hjälpa dig att förenkla din IT-hantering.
×

Se NinjaOne i aktion!

Genom att skicka detta formulär accepterar jag NinjaOne:s integritetspolicy.

NinjaOne Villkor och bestämmelser

Genom att klicka på knappen “Jag accepterar” nedan anger du att du accepterar följande juridiska villkor samt våra användarvillkor:

  • Äganderätt: NinjaOne äger och kommer att fortsätta att äga alla rättigheter, titlar och intressen i och till manuset (inklusive upphovsrätten). NinjaOne ger dig en begränsad licens att använda skriptet i enlighet med dessa juridiska villkor.
  • Begränsning av användning: Du får endast använda skriptet för dina legitima personliga eller interna affärssyften, och du får inte dela skriptet med någon annan part.
  • Republikbildning Förbud: Du får under inga omständigheter återpublicera skriptet i något skriptbibliotek som tillhör eller kontrolleras av någon annan programvaruleverantör.
  • Friskrivning från garantiansvar: Skriptet tillhandahålls “i befintligt skick” och “som tillgängligt”, utan garanti av något slag. NinjaOne ger inga löften eller garantier om att skriptet kommer att vara fritt från defekter eller att det kommer att uppfylla dina specifika behov eller förväntningar.
  • Antagande av risk: Din användning av skriptet sker på egen risk. Du bekräftar att det finns vissa inneboende risker med att använda skriptet, och du förstår och tar på dig var och en av dessa risker.
  • Avstående och befrielse: Du kommer inte att hålla NinjaOne ansvarig för några negativa eller oavsiktliga konsekvenser till följd av din användning av skriptet, och du avstår från alla juridiska eller skäliga rättigheter eller rättsmedel som du kan ha mot NinjaOne i samband med din användning av skriptet.
  • EULA: Om du är en NinjaOne-kund omfattas din användning av skriptet av det licensavtal för slutanvändare som gäller för dig (EULA).