Quick Answer
Snabbsvar: Disaster Recovery (DR), eller katastrofåterställning , är strukturen av processer, verktyg och planer som återställer IT-system efter en större incident – cyberattack, brand, strömavbrott, mänskligt misstag eller leverantörsfel. De två nyckelmåtten är RTO (Recovery Time Objective – hur snabbt ska systemet vara uppe igen) och RPO (Recovery Point Objective – hur mycket data får man förlora). Modern DR bygger oftast på molnbaserade strategier – pilot light, warm standby eller multi-site active/active – eftersom de ger bättre kostnad och lägre RTO än traditionella on-prem-lösningar. Svenska företag omfattas av skärpta krav: NIS2 kräver beprövade återställningsplaner, DORA sätter minimikrav för finanssektorn, och försäkringsbolag börjar vägra utbetalning utan dokumenterad och testad DR. Denna guide förklarar nyckelbegreppen, strategierna och hur ni bygger en DR som faktiskt fungerar när det behövs. Disaster Recovery – fyra strategier jämförda RTO och RPO – språket för DR-beslut RTO och RPO är bärande komponenter i varje DR-plan.
Key Topics Covered
Snabbsvar: Disaster Recovery (DR), eller katastrofåterställning, är strukturen av processer, verktyg och planer som återställer IT-system efter en större incident – cyberattack, brand, strömavbrott, mänskligt misstag eller leverantörsfel. De två nyckelmåtten är RTO (Recovery Time Objective – hur snabbt ska systemet vara uppe igen) och RPO (Recovery Point Objective – hur mycket data får man förlora). Modern DR bygger oftast på molnbaserade strategier – pilot light, warm standby eller multi-site active/active – eftersom de ger bättre kostnad och lägre RTO än traditionella on-prem-lösningar. Svenska företag omfattas av skärpta krav: NIS2 kräver beprövade återställningsplaner, DORA sätter minimikrav för finanssektorn, och försäkringsbolag börjar vägra utbetalning utan dokumenterad och testad DR. Denna guide förklarar nyckelbegreppen, strategierna och hur ni bygger en DR som faktiskt fungerar när det behövs.
RTO och RPO – språket för DR-beslut
RTO och RPO är bärande komponenter i varje DR-plan. De dikterar arkitektur, kostnad och teknikval.
- RTO (Recovery Time Objective): Maximal acceptabel tid från incident till att systemet fungerar igen. Exempel: 1 timme, 4 timmar, 24 timmar.
- RPO (Recovery Point Objective): Maximal acceptabel dataförlust. Exempel: 15 minuter, 1 timme, 24 timmar.
Båda måtten ska sättas per applikation, inte för hela IT-miljön som klump. En intern wiki har andra krav än en orderläggningstjänst som bär omsättningen.
De fyra DR-strategierna på AWS (och motsvarande på Azure/GCP)
- Backup and restore – RTO: timmar till dagar. RPO: timmar. Billigast. Lagrar backups, återställer manuellt vid incident.
- Pilot light – RTO: 10 minuter till några timmar. RPO: minuter. Kärnkomponenter (databas-replika, kritiska konfigurationer) hålls igång, resten aktiveras vid failover.
- Warm standby – RTO: minuter. RPO: sekunder till minuter. En nedskalad men fullt fungerande kopia körs löpande, skalas upp vid failover.
- Multi-site active/active – RTO: sekunder. RPO: nära noll. Trafik routas mellan flera regioner samtidigt. Dyrast, men för verksamhetskritiska system enda realistiska alternativet.
Behöver ni hjälp med Disaster Recovery?
Boka ett kostnadsfritt 30-minuters möte med en av våra specialister inom Disaster Recovery. Vi analyserar ert behov och ger konkreta rekommendationer — helt utan förpliktelse.
Den formella DR-planen – vad den måste innehålla
- Kritikalitetsklassning av system (tier 1–4 eller liknande)
- RTO/RPO per system med affärsjustering
- Roller och ansvar – incident commander, tekniska leads, kommunikationsansvarig, juridisk
- Detaljerade återställningsprocedurer – inte bara "återställ från backup" utan steg-för-steg
- Kommunikationsplan – internt, kunder, tillsynsmyndigheter (NIS2/IMY/DORA)
- Alternativa arbetsplatser för personal vid fysisk incident
- Testschema och dokumentation av testutfall
- Tredjepartsberoenden och deras DR-kapabilitet
Testning – det ingen tycker om men alla måste göra
En otestad DR-plan är fiktion. Testfrekvens efter mognadsnivå:
- Table-top-övningar: Halvårsvis. Diskussionsbaserad genomgång av scenarier.
- Partiell test: Kvartalsvis. Testa en specifik komponent (databas-failover, nätverksroutning).
- Fullskalig test: Årligen. Failover av ett helt system i skarpa men isolerade förhållanden.
- Chaos engineering: Löpande för mogna organisationer. Automatiserade fel injiceras i produktion för att bevisa motståndskraft.
NIS2 kräver specifikt bevis på att återställningskapabiliteten testas. Försäkringar blir allt strängare – obevisad DR kan leda till ersättningsavslag.
Molnbaserad DR ger bättre ekonomi – i de flesta fall
Traditionell DR krävde en duplicerad datacenteranläggning. Kostnaden var jämförbar med produktionsmiljön. Molnbaserad DR vänder på det:
- Betala nästan ingenting när DR-miljön är vilande (pilot light)
- Skala upp bara när det behövs
- Använd managed tjänster (RDS cross-region replicas, S3 cross-region replication)
- Testa failover billigare – AWS Elastic Disaster Recovery låter er testa i isolerade instanser utan att röra primärsystemet
För företag med strikta dataresidens-krav: pilot light inom Sverige är tekniskt möjligt på Azure (Sweden Central + Sweden South) och på AWS genom Availability Zones-separation inom eu-north-1.
Relaterade guider i kunskapsbasen
- Vad är katastrofåterställning i molnet?
- DR-plan – vad ska den innehålla?
- RTO och RPO förklarade
- Vad är pilot light?
- Vad är warm standby i AWS?
- Hur ofta ska DR-planen testas?
- DR och business continuity
- Hur gör man en DR-plan?
FAQ – Vanliga frågor om Disaster Recovery – komplett guide till katastrofåterställning för IT
Vad är skillnaden mellan disaster recovery och business continuity?
Business Continuity (BCP) är affärsprocessens fortsatta funktion vid incident – inkluderar personal, arbetsplatser, kundkommunikation, leveranskedjor. Disaster Recovery (DR) är IT-delen av BCP. Ni behöver båda: DR utan BCP ger teknisk återställning men ingen plan för hur personalen ska fortsätta arbeta. BCP utan DR lovar tillgänglighet men saknar teknisk plan.
Hur ofta ska vi testa vår DR-plan?
Minst årligen för fullskaliga tester. Mogna organisationer testar specifika delar kvartalsvis eller oftare. För NIS2- och DORA-omfattade verksamheter är regelbunden dokumenterad testning ett lagkrav, inte ett förslag.
Vad kostar en DR-lösning?
Pilot light på AWS för ett medelstort företag ligger typiskt på 10–25 procent av produktionsmiljöns kostnad. Warm standby: 30–50 procent. Multi-site active/active: 90–120 procent. Valet avgörs av RTO/RPO-kraven, inte av tekniska preferenser.
Måste DR-miljön ligga inom Sverige?
Ingen generell lag kräver det, men det finns sektor- och kund-specifika krav som gör det praktiskt nödvändigt. Myndigheter kräver ofta nordisk eller svensk lagring. Försäkringsbolag kan ha EU-only-krav. Inom finans kan DORA-tillsyn påverka. Standarden i Norden är minst EU-only; många svenska företag väljer svensk region för primär och annan EU-region för DR.
Hur hanterar vi DR om vår SaaS-leverantör går ner?
Det är en ofta missad risk. Granska leverantörens SLA och DR-plan. Fråga om cross-region redundans, RPO/RTO-åtagande och kompensation vid incident. För kritiska SaaS: överväg om ni behöver en backup-leverantör, egen data-export-rutin eller kortvariga manuella arbetsflöden vid incident.
Disaster Recovery – komplett guide till katastrofåterställning för IT med Opsio
Opsio är en svensk managed cloud-leverantör med AWS Premier Tier-status och över 15 års erfarenhet av att driva molnmiljöer för svenska företag i reglerade branscher. Vi hjälper er från strategi till löpande drift – med svensk fakturering, lokal support och dokumenterad efterlevnad mot NIS2, GDPR och DORA. Boka en konsultation för att diskutera ert behov.
Written By
Group COO & CISO at Opsio
Fredrik is the Group Chief Operating Officer and Chief Information Security Officer at Opsio. He focuses on operational excellence, governance, and information security, working closely with delivery and leadership teams to align technology, risk, and business outcomes in complex IT environments. He leads Opsio's security practice including SOC services, penetration testing, and compliance frameworks.
Editorial standards: Denna artikel är skriven av molnpraktiker och granskad av vårt ingenjörsteam. Vi uppdaterar innehållet kvartalsvis. Opsio upprätthåller redaktionellt oberoende.