Backup er ikke nok: NIS2 kræver Azure Site Recovery

Serverrum med Azure Site Recovery failover-diagram til produktionsvirksomhed

Backup er ikke nok: NIS2 kræver Azure Site Recovery

Af Sten Albert Person A-one Solutions ·
·
Kategori: Azure

Fredag kl. 22:14 krypterer ransomware jeres ERP-server. I har backup – men gendannelsen tager 36 timer. Produktionen står stille hele weekenden, og mandagens leverancer ryger. Det scenarie rammer lige nu hundredvis af danske produktionsvirksomheder, fordi de forveksler backup med disaster recovery. Azure Site Recovery lukker det hul – og opfylder NIS2’s krav om dokumenteret forretningskontinuitet.

Det vigtigste fra denne artikel

  • Backup gendanner data over dage. Disaster recovery gendanner drift på minutter til timer. NIS2 kræver det sidste.
  • Azure Site Recovery replikerer jeres servere løbende og kan failover til Azure med en RPO på 5–15 minutter (Rubrik, 2026).
  • I kan teste failover uden at påvirke produktionen – og bruge testen som NIS2-dokumentation.
  • Ransomware mod produktion steg 56 % i 2025 (Industrial Cyber, 2026). Backup alene stopper ikke nedetiden.
  • Automatiserede runbooks reducerer menneskelige fejl under krisesituationer med op til 80 % (ControlMonkey, 2026).

Sammenligning af tidslinje for backup-gendannelse versus disaster recovery failover

Hvorfor backup ikke opfylder NIS2’s krav om business continuity

De fleste produktions-SMV’er har styr på deres backup. Daglige snapshots, offsite-kopi, måske endda immutable storage. Det er godt – men det løser kun halvdelen af problemet.

Backup svarer på spørgsmålet: “Kan vi få vores data tilbage?”

Disaster recovery svarer på: “Kan vi køre videre?”

NIS2, som nu er fuldt håndhævet i EU, kræver dokumenteret forretningskontinuitet – ikke bare datagendannelse (Acronis, 2026). Det betyder, at I skal kunne påvise:

  1. En defineret RTO (Recovery Time Objective) – hvor hurtigt I er oppe igen.
  2. En defineret RPO (Recovery Point Objective) – hvor meget data I maksimalt mister.
  3. Dokumenterede tests af jeres failover-procedure.

En backup, der tager 24–48 timer at gendanne, opfylder sjældent de krav. Især ikke når revisoren spørger: “Hvornår testede I sidst?”

Sådan virker Azure Site Recovery i praksis

Azure Site Recovery (ASR) replikerer jeres on-premise servere – fysiske, VMware eller Hyper-V – løbende til Azure. Replikeringen sker i baggrunden med en typisk RPO på 5–15 minutter.

Når uheldet rammer, starter I en failover. Jeres servere kører nu som virtuelle maskiner i Azure. ERP, MES, filservere – alt det kritiske er tilgængeligt, mens I rydder op on-premise.

Det afgørende: ASR har en Test Failover-funktion, der spinner jeres servere op i et isoleret Azure-netværk (Microsoft, 2026). Produktionen kører uforstyrret. I får bevis for, at failover virker – og det bevis kan I lægge i NIS2-mappen.

Før → Efter: Fra håb til dokumenteret failover

Før: Driftschefen antager, at backup virker, men har aldrig testet en fuld gendannelse. RTO er ukendt. NIS2-dokumentationen er tom.

Efter: Kvartalsvis Test Failover i ASR. RTO er målt til under 4 timer. Revisoren får en rapport med tidsstempler og skærmbilleder.

Azure Site Recovery test failover i isoleret netværk uden produktionspåvirkning

Tjekliste: Backup vs. Disaster Recovery – hvad har I brug for?

Kriterium Backup Disaster Recovery (ASR)
Gendanner data ✅ Ja ✅ Ja
Gendanner drift (servere kører) ❌ Manuelt, timer–dage ✅ Automatisk, minutter–timer
Typisk RTO 24–72 timer Under 4 timer med runbook
Typisk RPO 24 timer (daglig backup) 5–15 minutter
Testbar uden nedetid ❌ Kræver ofte nedetid ✅ Test Failover i isoleret netværk
NIS2 business continuity ⚠️ Delvist ✅ Opfylder kravet
Beskytter mod ransomware-kryptering ⚠️ Kun med immutable storage ✅ Failover til rent miljø i separat region

Tommelfingerregel: I har brug for begge dele. Backup er jeres sikkerhedsnet for data. ASR er jeres sikkerhedsnet for drift. Det ene erstatter ikke det andet.

Kend jeres reelle RTO og RPO

Vi gennemgår jeres nuværende backup- og DR-setup og beregner, hvor hurtigt I reelt kan være oppe igen. Ingen salgsshow – bare tal, I kan bruge i jeres NIS2-dokumentation.

Book en DR-assessment her

Hvad koster nedetid vs. Azure Site Recovery?

Ifølge ENISA koster nedetid i forsyningskæden i gennemsnit millioner pr. dag (ENISA, 2025). For en dansk produktions-SMV med 100 ansatte ser regnestykket typisk sådan ud:

  • 4 timers produktionsstop: Tabt omsætning, overarbejde, forsinkede leverancer, kontraktbøder. Hurtigt 200.000–500.000 kr. afhængigt af branche.
  • Azure Site Recovery pr. måned: Ca. 175 kr. pr. beskyttet VM (licens) + storage til replikerede data. Compute betales kun under faktisk failover.

Ét produktionsstop betaler typisk for flere års ASR-licenser.

Før → Efter: Fra ukendt risiko til kalkuleret investering

Før: IT-budgettet har ingen post til disaster recovery. Ledelsen ser det som en udgift uden afkast – indtil det sker.

Efter: ASR kører på 8 kritiske VM’er til ca. 1.400 kr./md. i licens. Ledelsen har et konkret tal for nedetidsrisiko og ved, at investeringen er en brøkdel af ét nedbrud.

Regneeksempel der sammenligner omkostning ved nedetid med Azure Site Recovery pris

Hvorfor produktionsvirksomheder er særligt udsatte

Ransomware-angreb mod produktionssektoren steg 56 % i 2025, og branchen udgør nu omkring halvdelen af alle globale angreb (Industrial Cyber, 2026). Årsagen er enkel: legacy OT-systemer, der aldrig blev designet til at modstå cyberangreb, sidder nu på samme netværk som kontorens IT.

CISA anbefaler segmentering og isolerede failover-miljøer som kritisk forsvar mod spredning fra IT til fabriksgulvet (CISA, 2026). ASR understøtter det ved at lade jer failover til et isoleret Azure-netværk, hvor ransomwaren ikke kan følge med.

Microsofts egen best-practice anbefaler isolerede replikaer i en separat Azure-region for at reducere blast radius (Microsoft Learn, 2026).

Sådan kommer I i gang med Azure Site Recovery

ASR er ikke et projekt, der tager måneder. For de fleste SMV’er ser processen sådan ud:

  1. Kortlæg kritiske servere. Hvilke systemer skal køre inden for 4 timer? ERP, MES, filserver, Active Directory – prioritér dem.
  2. Definér RTO og RPO. Sæt realistiske mål. Under 4 timer RTO og 15 minutters RPO er opnåeligt for de fleste produktions-workloads (Rubrik, 2026).
  3. Installér ASR Mobility Service på de servere, der skal beskyttes (fysiske, VMware eller Hyper-V).
  4. Konfigurér replikering til en Azure-region (fx North Europe).
  5. Byg en Recovery Plan (runbook) der definerer rækkefølgen: AD først, derefter database, derefter applikationsservere.
  6. Kør Test Failover i et isoleret netværk. Dokumentér resultatet med tidsstempler.
  7. Planlæg kvartalsvise tests. Sourcepass (2026) anbefaler minimum to gange årligt – vi anbefaler kvartalsvist.

Har I allerede en sikkerhedsstrategi og Azure-tilstedeværelse, kan ASR typisk være i drift inden for 1–2 uger for de mest kritiske servere.

FAQ: Azure Site Recovery og NIS2

Hvad er forskellen på backup og disaster recovery?

Backup kopierer data, så I kan gendanne filer og databaser – typisk over 24–72 timer. Disaster recovery replikerer hele servere og kan starte dem i Azure inden for minutter til timer. I har brug for begge.

Er Azure Site Recovery nok til at opfylde NIS2?

ASR dækker kravet om dokumenteret forretningskontinuitet og testbar failover. Men NIS2 kræver også risikostyring, incident response og leverandørstyring. ASR er ét element i en samlet plan.

Hvad koster Azure Site Recovery pr. server?

Licensen er ca. 175 kr./md. pr. beskyttet VM. Dertil kommer storage til replikerede data (typisk få hundrede kroner). Compute betaler I kun, når I faktisk kører failover eller test.

Kan man teste failover uden at påvirke produktionen?

Ja. ASR’s Test Failover spinner serverne op i et isoleret Azure-netværk. Jeres produktionsmiljø mærker intet. Testen kan køres i arbejdstiden.

Hvad er en realistisk RTO med Azure Site Recovery?

For komplekse produktions-apps med ERP og databaser: under 4 timer med en pre-testet runbook. For simple filservere: under 30 minutter. DNS-opdatering og verifikation tager tid – regn altid med det.

Kan ASR beskytte fysiske on-premise servere?

Ja. ASR understøtter fysiske servere, VMware og Hyper-V. I installerer en Mobility Service-agent på serveren, og replikeringen kører via en process server on-premise.

Hvor ofte skal vi teste vores disaster recovery?

Minimum to gange årligt ifølge brancheanbefalinger. Vi anbefaler kvartalsvist – især hvis I er underlagt NIS2. Hver test giver dokumentation, der kan fremvises ved audit.

Næste skridt: Gør jeres DR testbar og NIS2-klar

  1. Auditér jeres nuværende setup: Kortlæg hvilke servere der har backup, og hvilke der har egentlig DR. Sandsynligvis er der et hul.
  2. Beregn jeres nedetidsrisiko: Tag jeres timeomsætning og gang med forventet gendannelsestid. Det tal overbeviser ledelsen.
  3. Prioritér 3–5 kritiske servere til ASR-replikering. Start med dem, der stopper produktionen, hvis de går ned.
  4. Kør jeres første Test Failover inden for 30 dage – og gem rapporten til NIS2-dokumentationen.
  5. Kontakt os hvis I vil have hjælp til at designe en DR-runbook, der matcher jeres RTO-krav og driftsbehov.

Tilmeld dig vores nyhedsbrev

Synes du også det er fantastisk at lære nye ting? Tilmeld dig til vores nyhedsbrev, og få opdateringer og tilbud.

Ved at tilmelde, accepterer du vores datapolitik

Kontakt os

Har du flere spørgsmål? Vi står klar ved linjen

Du kan ringe til dette nummer for alle relvante sprøgsmål eller support.

+45 70 26 48 50

IT support firma medarbejder hjælper erhvervskunde med teknisk løsning

Skal vi tage et kig på jeres IT?

Skriv jer op — vi kontakter dig inden for én arbejdsdag med en uforpligtende vurdering?