RPO och RTO – de två talen som styr allt

Varje DR-beslut kokar ner till två nyckeltal:

RPO (Recovery Point Objective) – Hur mycket data har du råd att förlora? RPO = 0 innebär synkron replikering och noll dataförlust. RPO = 1 timme innebär att du accepterar upp till en timmes förlust, typiskt via asynkron replikering.

RTO (Recovery Time Objective) – Hur snabbt måste tjänsterna vara tillbaka? RTO = 15 minuter kräver en varm standby-miljö som redan är igång. RTO = 4 timmar tillåter en kallare modell med automatisk provisionering vid failover.

Felet vi ser mest? Att verksamheten definierar RPO/RTO i en workshop, men att arkitekturen sedan designas utan att faktiskt validera att dessa mål uppnås. Kvartalsvis testning – med mätt RPO och RTO – är det enda sättet att veta.

DR-nivåer: kostnad kontra återställningstid

De flesta organisationer behöver inte multi-site active/active för hela sin miljö. En smart DRaaS-strategi tillämpar olika nivåer på olika system: active/active för betalflödet, pilotljus för internverktygen, backup & restore för arkivdata. Cloud FinOps

Molnbaserad DR-arkitektur i praktiken

AWS Elastic Disaster Recovery

AWS EDR (tidigare CloudEndure) replikerar på blocknivå från on-prem-servrar eller andra moln till AWS. I målregionen – exempelvis eu-north-1 (Stockholm) – upprätthålls ett lättvikts-staging-område med minimala instanstyper. Vid failover provisioneras fulla instanser automatiskt. Det innebär att den löpande kostnaden begränsas till replikering och lagring, medan compute-kostnaden främst uppstår vid test och faktisk katastrof.

Ur driftsperspektiv är den största utmaningen vi ser med EDR inte failovern i sig – det fungerar bra. Problemet är att många kunder glömmer bort failback-planen: hur du migrerar tillbaka till primärmiljön efter att krisen är över. Utan en dokumenterad och testad failback-process kan du fastna i DR-regionen längre än planerat, med oväntade kostnader som följd.

Azure Site Recovery

Azure Site Recovery (ASR) replikerar virtuella maskiner mellan Azure-regioner eller från on-prem till Azure. Styrkan ligger i orkestrerade återställningsplaner med sekvenserad failover: databaser startar först, sedan applikationsservrar, sedan webbservrar. Den sekvensen är avgörande – utan den får du applikationsfel trots att alla VM:ar tekniskt sett är uppe.

ASR:s test failover skapar en helt isolerad kopia av miljön, vilket innebär att du kan köra fullständiga DR-övningar utan att påverka produktion. Det är en av de mest underutnyttjade funktionerna vi ser: verktyget finns, men organisationer kör ändå inte tester. Molnsäkerhet

DR-testning: det som skiljer teori från verklighet

En obeprövad DR-plan är inte en plan – det är en förhoppning. Här är Opsios principer för DR-testning, baserade på tusentals övningar vi genomfört:

Testa kvartalsvis som minimum. Infrastruktur är levande. Nya tjänster läggs till, nätverksregler ändras, beroenden uppdateras. En DR-plan som var korrekt för sex månader sedan kan ha signifikanta gap idag.

Automatisera testprocessen. Både AWS EDR och Azure ASR stöder programmatisk testfailover. Genom att integrera DR-tester i CI/CD-pipelines kan du köra dem oftare utan manuell overhead. Managerad DevOps

Testa hela stacken, inte bara VM-start. En lyckad DR-övning innebär inte bara att virtuella maskiner startar i rätt ordning. Den innebär att applikationen svarar på anrop, att databaskopplingarna fungerar, att DNS-cutover sker korrekt och att slutanvändare faktiskt kan logga in. Vi har sett DR-tester där alla VM:ar var uppe inom RTO men applikationen ändå var otillgänglig på grund av en missat certifikat.

Dokumentera och iterera. Varje övning genererar insikter. Fånga dem strukturerat: vad fungerade, vad tog längre tid än förväntat, vilka manuella steg kan automatiseras. Den dokumentationen är också direkt relevant för NIS2-efterlevnad.

NIS2 och regulatoriska krav på driftkontinuitet

NIS2-direktivet, som trädde i kraft i oktober 2024, ställer explicita krav på att väsentliga och viktiga entiteter implementerar åtgärder för driftkontinuitet och krishantering. Artikel 21 specificerar bland annat "backup-hantering och katastrofåterställning" som en obligatorisk säkerhetsåtgärd.

För svenska organisationer som faller under NIS2:s tillämpningsområde innebär det i praktiken att:

• DR-förmågan måste vara dokumenterad och testad, inte bara planerad
• Rapporteringskrav vid incidenter kräver att du kan visa din återställningsförmåga
• Ledningen bär personligt ansvar för att dessa åtgärder finns på plats

DRaaS adresserar dessa krav direkt genom automatiserad replikering, schemalagda tester med rapportering och dokumenterade återställningsprocedurer. Managerade molntjänster

Hur Opsio levererar DRaaS

Vi ser DRaaS som en driftförmåga, inte ett engångsprojekt. Vår leveransmodell omfattar:

DR-arkitekturdesign – Vi kartlägger RPO/RTO-krav per system tillsammans med verksamheten och designar en DR-lösning som balanserar skyddsnivå mot kostnad. Inte alla system förtjänar active/active.

Implementation – Replikering konfigureras, failover-automatisering sätts upp och runbooks dokumenteras. Vi använder Infrastructure as Code (Terraform/CloudFormation) för att säkerställa att DR-miljön är reproducerbar och versionshanterad.

Kvartalsvisa DR-övningar – Vi genomför icke-störande testfailovers, mäter faktisk RPO och RTO, och levererar detaljerad rapportering – redo att visa för revisorer och NIS2-tillsyn.

24/7 replikeringsövervakning – Vårt NOC i Karlstad och Bangalore övervakar replikeringshälsa dygnet runt. Om replikeringslagg överstiger tröskelvärden triggas larm innan det blir ett problem vid en faktisk incident. Molnmigrering

Vanliga frågor

Vad är skillnaden mellan DRaaS och vanlig backup?

Backup kopierar data vid bestämda intervall och kräver manuell återställning – ofta timmar till dagar. DRaaS replikerar hela miljöer kontinuerligt och kan automatiskt växla över till en DR-region, vilket ger återställningstider på minuter istället för dagar. Backup skyddar data; DRaaS skyddar hela driften.

Hur ofta bör vi testa vår DR-plan?

Minst kvartalsvis. Infrastruktur förändras ständigt – nya tjänster, ändrade nätverksregler, uppdaterade beroenden – och en obeprövad DR-plan är i praktiken ingen plan alls. DRaaS-plattformar erbjuder icke-störande testfailover som kan köras utan att påverka produktion.

Kräver NIS2 att vi har en DR-lösning?

NIS2-direktivet, som gäller från oktober 2024, ställer krav på att väsentliga och viktiga entiteter har åtgärder för driftkontinuitet och katastrofåterställning. Även om direktivet inte namnger DRaaS specifikt, är en testad och dokumenterad DR-förmåga en central del av efterlevnaden.

Vad kostar DRaaS jämfört med ett eget DR-datacenter?

Ett eget DR-datacenter kräver investering i hårdvara, nätverksinfrastruktur, kyla, el och personal – ofta miljontals kronor årligen. DRaaS bygger på en pay-as-you-go-modell där du betalar för replikering löpande och full kapacitet bara vid faktisk failover, vilket ger markant lägre totalkostnad.

Kan DRaaS skydda både molnbaserade och lokala system?

Ja. Både AWS Elastic Disaster Recovery och Azure Site Recovery stöder replikering från on-prem-servrar till molnet, liksom mellan molnregioner. Det gör DRaaS till en flexibel lösning oavsett var dina arbetsbelastningar körs idag.