Hvad er en disaster recovery-plan? Elementer, RTO/RPO, test og tjekliste

En disaster recovery-plan (DR-plan) er en skriftlig, testet procedure til at genoprette it-systemer og data efter et større nedbrud, et cyberangreb eller tab af en lokation. Den angiver, hvem der erklærer en katastrofe, hvilke systemer der kommer først, hvor hurtigt (RTO), hvor stort et datatab der kan accepteres (RPO), og trinnene til at skifte over til og tilbage fra reservemiljøet.

Vigtigste pointer

• En DR-plan genopretter teknologien; en beredskabsplan for forretningskontinuitet holder hele virksomheden i gang. Du har brug for begge, og DR-planen bør være en delmængde af kontinuitetsplanen.
• Enhver beslutning om genopretning starter med to tal pr. system: recovery time objective (RTO) og recovery point objective (RPO).
• DR i skyen følger fire standardstrategier: backup og gendannelse, pilot light, warm standby og multi-site active/active. Pris og genopretningshastighed stiger sammen.
• En plan, der ikke er testet, er et gæt. Test mindst én gang om året og oftere for kritiske systemer, fra tabletop-øvelser til fuld failover.
• I EU nævner NIS2 artikel 21 "backup management and disaster recovery" som en minimumsforanstaltning. I Sverige gælder det via cybersikkerhedsloven (Cybersäkerhetslagen) fra 15. januar 2026.

Hvad er en disaster recovery-plan?

Det er den tekniske drejebog til at få systemerne tilbage efter en hændelse, som den almindelige robusthed ikke kan absorbere. Typiske udløsere er ransomware, nedbrud i et datacenter eller en cloudregion, en ødelagt database, en fejlslagen ændring, brand eller oversvømmelse.

NIST SP 800-34 definerer en DR-plan som "en skriftlig plan til at genoprette ét eller flere informationssystemer på en alternativ facilitet som svar på en større hardware- eller softwarefejl eller ødelæggelse af faciliteter" (NIST SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems). Den samme vejledning understreger, at en DR-plan er rettet mod informationssystemer, mens en plan for forretningskontinuitet dækker forretningsprocesser som lønudbetaling eller kundeservice.

Du vil også støde på betegnelserne "it-katastrofeplan" og "DRP". De betyder det samme. En god plan er kort nok til at kunne bruges under pres: beslutningsret, prioriteter, runbooks, kontaktpersoner og dokumentation for test. Et langt politikdokument, som ingen har åbnet siden sidste audit, tæller ikke.

Disaster recovery og forretningskontinuitet

Disaster recovery genopretter it. Forretningskontinuitet sikrer, at organisationen kan levere sine produkter og ydelser, mens it, medarbejdere, lokaler eller leverandører er forstyrret. AWS's whitepaper om DR siger det klart: DR-planen "bør være en delmængde af organisationens plan for forretningskontinuitet (BCP), den bør ikke være et selvstændigt dokument."

For en længere sammenligning, herunder BCDR i AWS, Azure og Google Cloud, kan du læse vores guide til disaster recovery og forretningskontinuitet i skyen.

Backup og disaster recovery

Backup er en kopi af data. Disaster recovery er evnen til at køre tjenesten igen. Du kan have perfekte backups og alligevel være nede i dagevis, hvis ingen har scriptet, hvordan servere, netværk, identiteter og DNS skal genopbygges omkring dem. Backups er ét input til DR-planen; 3-2-1-reglen (tre kopier, to medietyper, én offsite) er en fornuftig baseline for dem.

Hvad er formålet med en DR-plan?

Formålet er at gøre genopretningen forudsigelig. Når en katastrofe rammer, erstatter planen improvisation med beslutninger, der er truffet i ro og mag på forhånd.

• Begræns nedetid. Kritiske systemer kommer tilbage inden for en aftalt tid i en aftalt rækkefølge.
• Begræns datatab. Backups og replikering kører med den hyppighed, som forretningen har godkendt.
• Fjern tvivl. Alle ved, hvem der kan erklære en katastrofe, hvem der leder, og hvem der taler med kunder og myndigheder.
• Styr omkostningerne. Ikke alle systemer har brug for en hot standby. Planen registrerer, hvilke der har, og hvorfor.
• Dokumentér compliance. Tilsynsmyndigheder, revisorer, forsikringsselskaber og store kunder spørger i stigende grad efter testet genopretningsevne og ikke blot en politik.

Det er også de fordele, købere spørger til. En plan, der er blevet øvet, forkorter reelle nedbrud, fordi folk allerede har trænet trinnene.

RTO og RPO: de to tal, der driver planen

Recovery time objective (RTO) er, hvor længe et system må være nede. Recovery point objective (RPO) er, hvor meget data, målt i tid, du har råd til at miste. AWS definerer RTO som "den maksimalt acceptable forsinkelse mellem afbrydelsen af tjenesten og genoprettelsen af tjenesten" og RPO som "den maksimalt acceptable tid siden det seneste genoprettelsespunkt for data."

Regneeksempel. En webshop aftaler en RTO på 4 timer og en RPO på 15 minutter for sit ordresystem. Hvis databasen går ned kl. 10.00, skal der senest kl. 14.00 igen kunne modtages ordrer, og højst ordrer lagt mellem kl. 9.45 og 10.00 skal eventuelt indtastes igen eller genskabes på anden vis. En natlig backup kan ikke opfylde den RPO; webshoppen har brug for log shipping eller replikering mindst hvert 15. minut. Dens interne wiki kan derimod acceptere en RTO på 3 dage og en RPO på 24 timer, hvilket en daglig backup dækker.

To praktiske regler hjælper:

• Fastsæt mål pr. system gennem en business impact analysis og ikke ét tal for "it". Konsekvensen kan også ændre sig over tid: AWS bemærker, at et nedbrud af lønsystemet lige før lønudbetalingen gør langt mere skade end et lige efter.
• Hold RTO under den maksimalt acceptable nedetid for forretningsprocessen. NIST SP 800-34 forklarer, at RTO "normalt skal være kortere" end den grænse, fordi data stadig skal genbehandles, når systemerne er tilbage.

Flere eksempler og en trinvis metode til at fastsætte begge mål finder du i RPO og RTO i disaster recovery forklaret.

DR-strategier: fra backup og gendannelse til active/active

AWS-whitepaperen Disaster Recovery of Workloads on AWS deler DR i skyen op i fire strategier. De samme mønstre gælder på Azure (hvor Azure Site Recovery replikerer virtuelle maskiner til en sekundær region) og på Google Cloud.

Forskellen mellem pilot light og warm standby forvirrer mange teams. AWS formulerer det sådan: et pilot light-miljø "kan ikke behandle forespørgsler uden at der først tages yderligere skridt", mens en warm standby "straks kan håndtere trafik (med reduceret kapacitet)." Vores artikel om pilot light disaster recovery gennemgår mønsteret i detaljer.

To punkter fra whitepaperen overses ofte. For det første kan et multi-AZ-design inden for én region "allerede opfylde en stor del af dine behov for risikoreduktion" ved fejl på datacenterniveau; en anden region er til hændelser, der rammer hele regionen, eller til krav fra tilsynsmyndigheder. For det andet fungerer backup og gendannelse kun hurtigt, hvis infrastrukturen er defineret som kode, fordi du skal udrulle netværk, servere og konfiguration igen, ikke kun data.

DRaaS og disaster recovery i skyen

Disaster recovery as a service (DRaaS) betyder, at en udbyder replikerer dine servere til sin sky og driver værktøjerne til failover. AWS Elastic Disaster Recovery og Azure Site Recovery er de native muligheder; managed service providers bygger runbooks, overvågning og test omkring dem. DRaaS gør et kapitalprojekt (et andet datacenter) til en løbende omkostning, men fritager dig ikke for ansvaret for at fastsætte RTO/RPO, godkende planen og deltage i test.

Hot, warm og cold sites

Før cloudregioner beskrev man DR-strategier ud fra beredskabet på den alternative lokation. NIST SP 800-34 beskriver cold sites som plads med strøm, køling og forbindelser, men uden udstyr, warm sites som delvist udstyret med hardware og telekommunikation og hot sites som fuldt konfigureret med hardware, infrastruktur og personale. Et cold site er det billigste, men kan tage dage eller uger at få op at køre. Cloudens modstykker svarer groft sagt til backup og gendannelse (cold), pilot light eller warm standby (warm) og active/active (hot). Læs mere i hvad er et hot site i disaster recovery.

Hvad bør en DR-plan indeholde? Tjekliste

Brug tjeklisten til at bygge en ny plan eller auditere en eksisterende. Hver linje bør findes som et navngivet, dateret artefakt og ikke som et løfte.

Sådan laver du en DR-plan i syv trin

1. Gennemfør en business impact analysis og risikovurdering. Det er første skridt i enhver DR-indsats. Lav en liste over forretningsprocesser, hvad et nedbrud koster pr. time, og hvilke systemer hver af dem har brug for.
2. Fastsæt RTO og RPO pr. system. Grupper systemerne i tre-fire niveauer, så du designer til niveauer og ikke til hundredvis af enkeltservere.
3. Vælg en strategi pr. niveau. Match hvert niveau med backup og gendannelse, pilot light, warm standby eller active/active. Sammenhold prisen med den konsekvens, du målte i trin 1.
4. Byg den tekniske kapacitet. Backups, kopier på tværs af regioner eller konti, replikering, infrastructure as code samt overvågning og alarmering også i genopretningsmiljøet.
5. Skriv runbooks. Korte, nummererede trin, som en vagthavende ingeniør kan følge kl. 03.00, inklusive failback.
6. Test og ret. Start med en tabletop-øvelse, derefter gendannelsestests og så en failover. Registrér den målte RTO og RPO.
7. Vedligehold den. Gennemgå mindst en gang om året og efter enhver væsentlig ændring af systemer, leverandører eller organisationen.

Disaster recovery ved cyberhændelser og ransomware

For mange virksomheder er den katastrofe, de reelt skal planlægge for, ransomware eller en kompromitteret administratorkonto snarere end en oversvømmelse. Det ændrer planen på tre måder.

• Replikering er ikke nok. AWS advarer om, at kontinuerlig replikering "måske ikke beskytter mod katastrofehændelser som datakorruption eller ondsindede angreb (såsom uautoriseret sletning af data) lige så godt som backups fra bestemte tidspunkter." Behold backups fra bestemte tidspunkter, som angribere ikke kan slette, helst i en separat konto med andre legitimationsoplysninger.
• Genopretning starter efter inddæmning. Planen for håndtering af hændelser afgør, hvornår miljøet er rent nok til at gendanne ind i. Gendannelse til kompromitteret infrastruktur smitter den igen.
• Identitet er en afhængighed. Hvis din identitetsudbyder eller adgangskodemanager er nede eller kompromitteret, skal runbooks beskrive, hvordan de reagerende får adgang.

Hvornår aktiveres en DR-plan?

Planen aktiveres, når et nedbrud overskrider eller tydeligt vil overskride det, den almindelige hændelseshåndtering kan løse inden for RTO. Skriv kriterierne ned, for eksempel "primær region utilgængelig i mere end 30 minutter" eller "produktionsdata krypteret af ransomware", og angiv, hvem der beslutter. Se hvornår du skal aktivere en disaster recovery-plan for typiske udløsere.

Hvor ofte bør en DR-plan testes?

Test mindst én gang om året og efter hver væsentlig ændring. Kritiske systemer fortjener hyppigere øvelser. NIST's eksempel på en beredskabspolitik siger, at genopretningsevner "skal testes årligt", og vejledningen anbefaler at gennemgå planen "mindst årligt" og efter væsentlige ændringer.

NIST skalerer også testens dybde efter systemets konsekvensniveau. For systemer med lav konsekvens er en tabletop-øvelse tilstrækkelig; systemer med moderat konsekvens kræver en funktionel øvelse, der omfatter gendannelse fra backup; systemer med høj konsekvens kræver en funktionel øvelse i fuld skala, der omfatter "en systemfailover til den alternative lokation."

Kolonnen med hyppighed er vores anbefaling til en typisk mellemstor virksomhed; din tilsynsmyndighed eller dine kunder kan kræve mere. AWS opsummerer, hvorfor test er vigtig: "den eneste fejlgenopretning, der virker, er den vej, du tester ofte." Registrér efter hver test den målte genopretningstid og det målte datatab, sammenhold dem med dine mål, og tildel ejere til alle huller.

NIS2 og den svenske cybersikkerhedslov

For organisationer inden for NIS2 er disaster recovery ikke længere valgfri god praksis. Artikel 21, stk. 2, litra c i direktiv (EU) 2022/2555 (NIS2) kræver, at risikostyringsforanstaltningerne som minimum omfatter "business continuity, such as backup management and disaster recovery, and crisis management". Artikel 23 tilføjer frister for rapportering af væsentlige hændelser: en tidlig varsling inden for 24 timer efter, at man er blevet opmærksom på hændelsen, og en underretning om hændelsen inden for 72 timer. Din DR-plan og din proces for rapportering af hændelser skal derfor fungere sammen.

I Sverige er NIS2 gennemført ved cybersikkerhedsloven (Cybersäkerhetslag, SFS 2025:1506), som trådte i kraft den 15. januar 2026. Kapitel 2, § 3 nævner "kontinuitetshantering och krishantering" (kontinuitetsstyring og krisestyring) blandt minimumsforanstaltningerne. Regn med, at tilsynsmyndighederne beder om dokumentation: en aktuel plan, testrapporter og lukkede fund.

Sådan hjælper Opsio

Opsio designer, driver og tester DR for workloads på AWS og Azure som en del af sin cloud disaster recovery-tjeneste.

Ofte stillede spørgsmål

Hvad er de vigtigste elementer i en disaster recovery-plan?

Kernen er en business impact analysis og risikovurdering, RTO og RPO pr. system, en genopretningsstrategi pr. niveau, backup og replikering, kriterier for aktivering, roller og kontaktpersoner, trinvise runbooks inklusive failback, en kommunikationsplan samt en plan for test og vedligeholdelse.

Hvad er første skridt i en disaster recovery-indsats?

Første skridt er en business impact analysis kombineret med en risikovurdering. Den fortæller dig, hvilke processer og systemer der betyder mest, og hvor længe de kan være nede, hvilket fastsætter den RTO og RPO, som alle senere beslutninger afhænger af.

Hvor ofte bør en disaster recovery-plan testes?

Mindst en gang om året og efter enhver større ændring af systemer eller leverandører. Kør tabletop-øvelser for alle planer og gendannelses- eller failover-tests for kritiske systemer, som NIST SP 800-34 anbefaler for systemer med højere konsekvens.

Hvad er forskellen på disaster recovery og forretningskontinuitet?

Disaster recovery genopretter it-systemer og data. Forretningskontinuitet holder forretningen i drift under en forstyrrelse og dækker også medarbejdere, lokaler, leverandører og kommunikation. DR-planen bør være en del af planen for forretningskontinuitet.

Hvilke fire disaster recovery-strategier findes der i skyen?

Backup og gendannelse, pilot light, warm standby og multi-site active/active. De spænder fra timers genopretningstid til lavest pris til genopretning næsten i realtid til højest pris, ifølge AWS's DR-whitepaper.

Kræver NIS2 planlægning af disaster recovery?

NIS2 artikel 21, stk. 2, litra c kræver, at væsentlige og vigtige enheder dækker business continuity, "such as backup management and disaster recovery, and crisis management". I praksis betyder det en dokumenteret, testet DR-evne, som du kan vise til tilsynsmyndigheden.