Leverantörer av katastrofåterställning (DRaaS) i Sverige
Head of Innovation
Digital Transformation, AI, IoT, Machine Learning, and Cloud Technologies. Nearly 15 years driving innovation
Leverantörer av katastrofåterställning (DRaaS) i Sverige
En DRaaS-leverantör (Disaster Recovery as a Service) tar ansvar för att era kritiska system kan återställas inom definierad tid efter en incident — oavsett om det handlar om ransomware, hårdvaruhaveri eller ett datacenter som tappar ström. Skillnaden mot traditionell backup är fundamental: DRaaS orkestrerar hela återstarten, inte bara dataåterställningen. För svenska organisationer som omfattas av NIS2 är en testad DR-plan inte längre valfri — den är regulatoriskt förväntad.
Viktiga slutsatser
- DRaaS minskar återställningstiden från dagar till minuter — men bara om RTO och RPO är definierade och testade
- NIS2-direktivet ställer explicita krav på incidenthantering och kontinuitetsplanering för väsentliga och viktiga entiteter
- Molnbaserad katastrofåterställning med replikering till eu-north-1 (Stockholm) eller Sweden Central ger datalokalitet och låg latens
- En DRaaS-leverantör utan regelbundna failover-tester levererar en falsk trygghet
- FinOps-principer bör styra DRaaS-dimensionering — överprovisioning av standby-miljöer är ett vanligt kostnadsläckage
Vad DRaaS faktiskt innebär — och vad det inte är
Begreppet "disaster recovery" missförstås ofta. Många organisationer tror att de har DR för att de kör nattlig backup till en annan site. Det är ungefär som att tro att man har brandskydd för att man äger en brandsläckare. Backup skyddar data. DRaaS skyddar verksamheten.
En komplett DRaaS-lösning omfattar tre lager:
1. Datareplikering — kontinuerlig eller nära-realtid kopiering av data till en sekundär plats. Beroende på RPO-krav kan detta vara synkron replikering (noll dataförlust) eller asynkron (sekunder till minuter av potentiell förlust).
2. Infrastrukturorkestrering — förmågan att starta upp hela miljön (servrar, nätverk, lastbalanserare, DNS) i rätt ordning på den sekundära siten. Det här är vad som skiljer DRaaS från backup.
3. Automatiserad eller semi-automatiserad failover — när en incident detekteras kan trafiken styras om utan att någon behöver logga in och klicka sig igenom en checklista klockan tre på natten.
Från Opsios NOC i Karlstad ser vi mönstret tydligt: organisationer som investerat i dyra replikeringslösningar men aldrig testat failover-processen. När det väl smäller tar det lika lång tid som utan DRaaS — för att ingen vet vilka steg som krävs.
Vill ni ha expertstöd med leverantörer av katastrofåterställning (draas) i sverige?
Våra molnarkitekter hjälper er med leverantörer av katastrofåterställning (draas) i sverige — från strategi till implementation. Boka ett kostnadsfritt 30-minuters rådgivningssamtal utan förpliktelse.
RTO och RPO — de två siffrorna som styr allt
All DRaaS-dimensionering utgår från två nyckeltal:
| Begrepp | Definition | Typiskt spann | Kostnadspåverkan |
|---|---|---|---|
| RTO (Recovery Time Objective) | Maximal acceptabel tid från incident till att systemet är tillgängligt igen | 15 min – 24 h | Kortare RTO = dyrare (hot standby, aktiv-aktiv) |
| RPO (Recovery Point Objective) | Maximal acceptabel dataförlust mätt i tid | 0 – 24 h | Kortare RPO = dyrare (synkron replikering, CDP) |
| RCO (Recovery Cost Objective) | Vad organisationen är beredd att betala för att uppnå RTO/RPO | Varierar | Styr arkitekturvalet |
Misstaget vi ser oftast: organisationer sätter RTO till "så kort som möjligt" utan att kvantifiera kostnaden för driftstopp. Om en timmes stillestånd kostar 500 000 SEK i förlorad omsättning, och en DRaaS-lösning med RTO under en timme kostar 40 000 SEK/månad, är kalkylen enkel. Men utan den affärskonsekvensanalysen (BIA) saknar RTO/RPO-värdena förankring.
Så ser den svenska marknaden ut 2026
Den svenska DRaaS-marknaden har mognat påtagligt de senaste två åren, drivet av tre krafter:
NIS2 och regulatorisk press
NIS2-direktivet, som medlemsstaterna implementerar i nationell lag, ställer tydliga krav på att väsentliga och viktiga entiteter ska ha åtgärder för driftskontinuitet och krishantering. Sverige har genom Myndigheten för samhällsskydd och beredskap (MSB) och sektorsspecifika tillsynsmyndigheter fått utökade befogenheter att granska organisationers förmåga att hantera IT-incidenter. En organisation utan dokumenterad och testad DR-plan exponerar sig för både operativ risk och regulatorisk sanktion.
Molnregioner i Norden
Att både AWS (eu-north-1 i Stockholm) och Azure (Sweden Central i Gävle/Sandviken) har fullskaliga regioner i Sverige har eliminerat det historiska argumentet mot molnbaserad DR — nämligen datalokalitet. Det är nu fullt möjligt att replikera affärskritiska system inom Sverige, med all data lagrad på svensk mark, och samtidigt ha en sekundär failover-site i en annan nordisk region (till exempel eu-west-1 i Irland eller Azure Norway East) för geografisk redundans.
Ransomware-hotbilden
Vi behöver inte citera statistik för att konstatera det uppenbara: ransomware-angrepp mot svenska organisationer har ökat i frekvens och sofistikering. Det som gör DRaaS särskilt relevant är att moderna ransomware ofta riktar sig specifikt mot backup-infrastruktur. En DRaaS-lösning med isolerade (air-gapped) kopior och immutable storage erbjuder ett skydd som traditionell backup inte kan matcha.
Arkitekturmönster för DRaaS i molnet
Det finns inte ett enda rätt sätt att implementera DRaaS. Valet av arkitektur beror på RTO/RPO-krav, budget och komplexitet. Här är de tre vanligaste mönstren vi implementerar hos Opsio:
Pilot Light
En minimal version av produktionsmiljön körs kontinuerligt i den sekundära regionen — typiskt bara databaser och konfiguration. Vid incident startas resten av infrastrukturen upp från fördefinierade templates (Terraform, CloudFormation). RTO: 1–4 timmar. Kostnadseffektivt, men kräver väl orkestrerad uppstart.
Warm Standby
En nedskalad men funktionell kopia av produktionsmiljön körs kontinuerligt. Vid failover skalas den upp till full kapacitet. RTO: 15–60 minuter. Dyrare än Pilot Light men snabbare och mindre riskfyllt vid faktisk incident.
Aktiv-aktiv (Multi-site)
Trafiken fördelas kontinuerligt över två eller fler regioner. Om en region faller bort tar de andra över. RTO: nära noll. Kräver applikationsarkitektur som stödjer det (stateless tjänster, distribuerad databas). Avsevärt dyrare, men motiverat för verksamhetskritiska system.
| Mönster | RTO | RPO | Relativ kostnad | Komplexitet |
|---|---|---|---|---|
| Backup & Restore | 6–24 h | 1–24 h | Låg | Låg |
| Pilot Light | 1–4 h | Minuter | Medel | Medel |
| Warm Standby | 15–60 min | Sekunder–minuter | Hög | Hög |
| Aktiv-aktiv | < 5 min | Nära noll | Mycket hög | Mycket hög |
AWS Well-Architected Frameworks Reliability Pillar och Azures Architecture Center beskriver dessa mönster i detalj och är utmärkta utgångspunkter för arkitekturbeslut.
Vad du bör kräva av en DRaaS-leverantör
Baserat på vad Opsios SOC/NOC-team ser i daglig drift, och de incidenter vi hanterat åt kunder, finns det fem icke-förhandlingsbara krav:
1. Regelbundna, verifierade failover-tester
En DR-plan som aldrig testats är en hypotes, inte en plan. Kräv att leverantören genomför minst kvartalsvis orkestrerade failover-tester med dokumenterade resultat. Opsio kör dessa tester tillsammans med kunden och mäter faktisk RTO mot avtalat mål. Avvikelser utlöser åtgärdsplaner.
2. Immutable backups och air-gapped kopior
Med ransomware som aktivt riktar sig mot backup-infrastruktur behöver DRaaS-lösningen inkludera kopior som inte kan modifieras eller raderas — varken av angripare eller av misstag. AWS S3 Object Lock och Azure Immutable Blob Storage är två tekniska implementationer av detta.
3. Tydliga SLA:er med ekonomisk konsekvens
Ett SLA utan vite vid överträdelse är ett marknadsföringsdokument. Kräv definierade RTO- och RPO-mål med tydlig ekonomisk kompensation om leverantören inte levererar.
4. Nordisk datalokalitet
För organisationer som hanterar personuppgifter under GDPR eller sektorspecifik reglering: verifiera att all DR-data lagras inom EU/EES, och helst inom Sverige. Fråga specifikt vilka regioner som används för replikering och failover.
5. Integration med er befintliga infrastruktur och IaC
DRaaS som kräver manuella steg för att synka med er produktionsmiljö blir snabbt inaktuell. Lösningen bör integreras med ert Infrastructure as Code-flöde (Terraform, Pulumi, CloudFormation) så att förändringar i produktion automatiskt reflekteras i DR-miljön.
DRaaS-kostnader och FinOps-perspektiv
Ett av de vanligaste misstagen vi ser är DRaaS-miljöer som dimensioneras en gång och sedan aldrig justeras. Flexeras State of the Cloud har konsekvent visat att kostnadshantering är den främsta utmaningen för molnanvändare — och DRaaS-miljöer är inget undantag.
Konkreta åtgärder:
- Tagga DRaaS-resurser separat i er FinOps-rapportering. Annars drunknar de i den totala molnkostnaden och ingen ifrågasätter om de är rätt dimensionerade.
- Använd Reserved Instances eller Savings Plans för Warm Standby-resurser som körs kontinuerligt. Att betala on-demand för en databasinstans som alltid är igång är onödigt dyrt.
- Granska kvartalsvis om RTO/RPO-kraven fortfarande matchar verksamhetens behov. En tjänst som avvecklats behöver inte längre en Warm Standby-kopia.
- Automatisera nedskalning av Pilot Light-resurser under icke-kritiska perioder om er riskprofil tillåter det.
Molnmigrering och DRaaS — parallella spår
Många organisationer upptäcker behovet av DRaaS mitt i en molnmigrering. Det är logiskt: när man flyttar från on-premise till molnet är det ett naturligt tillfälle att designa in katastrofåterställning från start, snarare än att försöka boltra fast det efteråt.
Opsios migrationsteam designar DR-arkitekturen parallellt med migrationsplanen. Det innebär att varje arbetsbelastning som migreras till molnet redan har en definierad RTO/RPO, en replikeringsstrategi och en testad failover-procedur innan den tas i produktion. Det kostar marginellt mer under migreringen men sparar enorma summor jämfört med att retroaktivt implementera DRaaS.
Opsios perspektiv: vad vi ser i produktion
Vi driver 24/7 SOC/NOC från Karlstad och Bangalore, och hanterar DRaaS för kunder över AWS, Azure och GCP. Tre observationer från verkligheten:
DNS-failover underskattas. Många har fungerande infrastruktur-failover men har missat att DNS-poster pekar på den primära siten med lång TTL. Resultat: infrastrukturen är uppe i DR-regionen, men ingen trafik når dit. Vi konfigurerar alltid Route 53 Health Checks (AWS) eller Azure Traffic Manager med korta TTL:er som del av DRaaS-implementationen.
Applikationstillstånd är den svåraste biten. Att replikera en databas är välförstått. Men moderna applikationer har tillstånd i cacher, meddelandeköer, sessionshantering och lokala filsystem. DRaaS som bara fokuserar på databas-failover ger en miljö som startar men inte fungerar korrekt.
Dokumentation ruttnar. En DR-runbook som skrevs för 18 månader sedan och aldrig uppdaterats är farligare än ingen runbook alls — den ger falsk trygghet. Vi automatiserar runbooks som kod (Ansible, AWS Systems Manager) och kör dem i varje test. Om koden fungerar vet vi att processen fungerar.
Vanliga frågor
Vad är skillnaden mellan backup och DRaaS?
Backup kopierar data till en annan plats. DRaaS är en komplett tjänst som även inkluderar infrastruktur, automatisk failover och orkestrering så att hela miljön kan startas upp i en sekundär site — inte bara att filer finns sparade. Backup skyddar data, DRaaS skyddar verksamheten.
Vilka RTO- och RPO-värden är rimliga för svenska medelstora företag?
Det beror helt på verksamhetens kritikalitet. Affärskritiska system som e-handel eller produktionsstyrning siktar ofta på RTO under 1 timme och RPO under 15 minuter. Stödsystem kan ha RTO på 4–8 timmar. Nyckeln är att definiera värdena utifrån affärskonsekvensanalys (BIA), inte gissning.
Ställer NIS2 krav på katastrofåterställning?
Ja. NIS2-direktivet kräver att väsentliga och viktiga entiteter har åtgärder för incidenthantering, driftskontinuitet och krishantering. Avsaknad av testad DR-plan kan leda till sanktioner. Sveriges implementering via MSB och sektorsspecifika tillsynsmyndigheter förstärker detta ytterligare.
Kan vi använda en svensk molnregion för DRaaS?
Absolut. Både AWS (eu-north-1 i Stockholm) och Azure (Sweden Central) erbjuder fullvärdiga tjänster för katastrofåterställning med data som stannar inom Sveriges gränser. Det förenklar GDPR-efterlevnad och eliminerar frågor om tredjelandsöverföringar.
Hur ofta bör vi testa vår DR-plan?
Minst kvartalsvis för affärskritiska system, halvårsvis för övriga. Testerna bör inkludera faktisk failover — inte bara dokumentgranskning. Mät faktisk RTO och jämför mot avtalade mål. Avvikelser är inte misslyckanden — de är värdefull data som driver förbättring.
Relaterade artiklar
Om författaren
Head of Innovation at Opsio
Digital Transformation, AI, IoT, Machine Learning, and Cloud Technologies. Nearly 15 years driving innovation
Editorial standards: This article was written by a certified practitioner and peer-reviewed by our engineering team. We update content quarterly to ensure technical accuracy. Opsio maintains editorial independence — we recommend solutions based on technical merit, not commercial relationships.
