Varför organisationer lämnar intern DR bakom sig

Traditionell intern katastrofåterställning kräver kapitalinvesteringar i hårdvara, specialiserad personal som håller sekundär infrastruktur aktuell, och löpande underhåll av system som ni hoppas aldrig ska behöva aktiveras. Det är en svår ekvation att få ihop.

De vanligaste problemen med intern DR

• Kompetensbrist: Att hålla en parallell miljö uppdaterad kräver samma ändringshantering som produktionsmiljön. De flesta driftsteam har redan fullt upp.
• Testunderskott: Intern DR testas sällan tillräckligt ofta. När väl failover behövs upptäcks konfigurationsavvikelser som gör återställningen opålitlig.
• Kostnadsasymmetri: Hårdvaran åldras, licenser löper, och budgeten för "infrastruktur som kanske aldrig används" är svår att försvara internt.
• Geografisk sårbarhet: Ett enda datacenter – oavsett hur redundant det är internt – skyddar inte mot regionala störningar som strömavbrott, naturkatastrofer eller nätverksavbrott.

Övergången till molnbaserad DRaaS speglar en bredare trend som Flexeras State of the Cloud-rapport konsekvent bekräftar: organisationer flyttar allt fler kritiska funktioner till opex-baserade molnmodeller, och katastrofåterställning är inget undantag.

DRaaS kontra intern DR: en jämförelse

Hur en DRaaS-lösning fungerar i praktiken

1. Initial bedömning och prioritering

Allt börjar med en Business Impact Analysis (BIA). Vilka system är affärskritiska? Vad är acceptabel RTO och RPO per arbetsbelastning? Vilka beroenden finns mellan tjänster?

Hos Opsio genomför vi denna bedömning tillsammans med kundens tekniska team och verksamhetsansvariga. Det är avgörande att affärssidan är involverad – det är de som vet vilka processer som genererar intäkter och vilka som kan tolerera en timmes avbrott.

2. Replikering och konfiguration

Arbetsbelastningar replikeras kontinuerligt till molnbaserade målmiljöer. För kunder med krav på svensk datahemvist innebär det typiskt replikering till AWS eu-north-1 (Stockholm) eller Azure Sweden Central, med sekundär replikering till en annan EU-region för geografisk redundans.

Replikeringen omfattar:

• Virtuella maskiner och containeriserade tjänster
• Databasreplikering (synkron eller asynkron beroende på RPO-krav)
• Nätverkskonfigurationer, brandväggsregler och DNS-poster
• Krypterings- och åtkomstpolicyer

3. Automatiserad failover och orkestrering

Vid en incident – detekterad via 24/7-övervakning i vårt SOC/NOC – triggas failover antingen automatiskt eller manuellt beroende på incidenttyp. Runbooks definierar exakt startordning: identitetshantering först, sedan databaser, applikationsservrar och slutligen lastbalanserare och DNS-ompekning.

4. Failback och normalisering

Efter att grundorsaken åtgärdats i primärmiljön synkroniseras data tillbaka och trafiken flyttas hem. Denna fas underskattas ofta men är lika kritisk som failover – en misslyckad failback kan orsaka dataförlust eller inkonsistens.

Managerade molntjänster

Regelefterlevnad: NIS2, GDPR och svenska krav

NIS2-direktivet

NIS2, som implementerades i EU-medlemsstaterna under 2024, utvidgar kraven på verksamhetskontinuitet och incidenthantering till fler sektorer. Organisationer som omfattas måste kunna påvisa:

• Dokumenterade och testade planer för katastrofåterställning
• Rapportering av allvarliga incidenter inom 24 timmar
• Ledningens personliga ansvar för cybersäkerhetsåtgärder

Sanktionerna är kännbara – upp till 10 miljoner euro eller 2 % av global omsättning för väsentliga entiteter.

GDPR och datahemvist

Artikel 32 i GDPR kräver att personuppgiftsansvariga implementerar "förmåga att återställa tillgängligheten och åtkomsten till personuppgifter i rimlig tid vid en fysisk eller teknisk incident." DRaaS med replikering inom EU uppfyller detta krav – förutsatt att leverantören inte replikerar data till tredje land utan lämpliga skyddsåtgärder.

Integritetsskyddsmyndigheten (IMY) har i sina tillsynsbeslut upprepade gånger betonat vikten av att organisationer kan påvisa tekniska och organisatoriska åtgärder för att säkerställa datatillgänglighet.

Molnsäkerhet

Fem misstag vi ser organisationer göra med DRaaS

1. Aldrig testa failover på riktigt

Den vanligaste bristen. Ni betalar för DRaaS men har aldrig verifierat att det faktiskt fungerar med er nuvarande miljö. Testa varannan månad – minst.

2. Felaktiga RTO/RPO-antaganden

"Vi behöver RTO på noll" säger verksamheten. I verkligheten innebär det synkron replikering, som kostar mångdubbelt. Rätt approach är att differentiera: affärskritiska system får aggressiva mål, stödsystem kan tolerera längre återställningstider.

3. Glömma nätverket

Servrarna replikeras – men DNS, VPN-tunnlar, brandväggsregler och lastbalanserare hänger inte med. Failover fungerar tekniskt, men ingen kan nå tjänsterna.

4. Ignorera failback-processen

Failover testas. Failback glöms bort. När primärmiljön är fixad saknas en plan för att synkronisera tillbaka data utan förlust.

5. Välja leverantör enbart på pris

Den billigaste DRaaS-lösningen saknar ofta automatiserad orkestrering, testar inte proaktivt och har begränsad support utanför kontorstid. Vid en kris klockan 03:00 spelar prisskillnaden på några tusen kronor i månaden ingen roll.

Hur ni väljer rätt DRaaS-leverantör

Checklista för utvärdering

• Certifieringar: SOC 2 Type II, ISO 27001 – verifiera att de gäller DRaaS-tjänsten specifikt, inte bara leverantörens övriga verksamhet
• Datahemvist: Replikering till datacenter inom EU, med möjlighet till svensk primärnod
• SLA med tandlösa formuleringar? Kräv definierade RTO/RPO-garantier med kompensationsklausuler
• Testrutiner: Hur ofta genomförs failover-tester? Deltar ni som kund? Dokumenteras resultaten?
• 24/7 SOC/NOC: Incidenter respekterar inte kontorstid. Verifiera att leverantören har dygnet-runt-bemanning – inte bara jour
• Multi-cloud-kapacitet: Om ni kör arbetsbelastningar på flera molnplattformar behöver DRaaS-leverantören stödja samtliga
• Exitstrategi: Vad händer om ni vill byta leverantör? Hur exporteras data och konfigurationer?

Molnmigrering

Hybridmodellen: det bästa av två världar

De organisationer som lyckas bäst med outsourcad katastrofåterställning behåller strategisk styrning internt och lägger operativ drift hos leverantören. Konkret innebär det:

• Internt: DR-policy, prioriteringsordning, affärskonsekvensanalys, deltagande i failover-tester, incidentbeslut
• Hos leverantören: Infrastruktur, replikering, övervakning, automatiserad failover, löpande underhåll och uppdatering av DR-miljön

Denna modell ger kontroll utan den operativa bördan. Från Opsios perspektiv ser vi att kunder med engagerade interna DR-ägare – oftast en kombination av IT-chef och verksamhetsansvarig – får ut mest värde av DRaaS. De ställer rätt krav, deltar i tester och ifrågasätter antaganden.

Cloud FinOps

Opsios perspektiv: vad vi ser i produktion

Vårt SOC/NOC i Karlstad och Bangalore hanterar DR-scenarion åt kunder varje månad. Några observationer:

• Ransomware är den vanligaste triggern för faktisk failover, inte hårdvarufel. Immutable backups och air-gapped replikering är inte förhandlingsbart.
• DNS-propagering är den underskattade flaskhalsen. Automatiserad DNS-failover med låg TTL bör vara standard.
• Kommunikationsplaner saknas oftast. Vem kontaktar kunder? Vem informerar ledningen? Det tekniska fungerar, men organisationen vet inte vad de ska göra.

Managerad DevOps

Vanliga frågor

Vad är skillnaden mellan DRaaS och vanlig backup?

Backup kopierar data till en separat plats. DRaaS går steget längre och replikerar hela miljön – servrar, nätverk, applikationer och konfigurationer – med automatiserad failover. Vid ett avbrott startar DRaaS en komplett speglad miljö, medan en backup kräver manuell återbyggnad av infrastrukturen innan data kan återställas.

Hur snabbt kan vi vara igång igen med DRaaS?

Med en välkonfigurerad DRaaS-lösning och kontinuerlig replikering kan RTO ligga under 15 minuter för kritiska arbetsbelastningar. Den faktiska tiden beror på komplexiteten i miljön, hur replikeringen är uppsatt och om failover-processen testats regelbundet.

Behöver vi fortfarande intern DR-kompetens om vi outsourcar?

Ja, men rollen förändras. Interna team bör äga DR-policyn, definiera prioritetsordning för applikationer och delta i failover-tester. Den operativa bördan – infrastruktur, övervakning och exekvering – ligger hos leverantören. Utan intern styrning riskerar ni att DR-planen inte speglar faktiska affärsbehov.

Hur påverkar NIS2 kraven på katastrofåterställning?

NIS2-direktivet kräver att organisationer inom omfattade sektorer har dokumenterade och testade planer för incidenthantering och verksamhetskontinuitet. Brister kan leda till sanktioner på upp till 10 miljoner euro eller 2 % av global omsättning. Ledningen bär personligt ansvar.

Vad bör vi tänka på vid val av DRaaS-leverantör med svensk datahemvist?

Kontrollera att leverantören erbjuder replikering till datacenter inom EU – helst med nod i Sverige (t.ex. AWS eu-north-1 Stockholm eller Azure Sweden Central). Granska certifieringar (SOC 2, ISO 27001), kräv dokumenterade SLA:er med definierad RTO/RPO, och verifiera att de genomför regelbundna failover-tester med er, inte bara internt.