Microsoft 365 backup løsninger: vælg rigtigt første gang

En bruger sletter et Team. En admin rydder papirkurven. Eller ransomware krypterer SharePoint og fjerner versionshistorik. I Microsoft 365 kan “vi har retention” hurtigt blive til “vi kan ikke genskabe”. Her får I beslutningsregler til at vælge Microsoft 365 backup løsninger, så I kan måle jeres restore-tider og dokumentere det til NIS2.

Key takeaways: hvad I gør i praksis

• Skil governance fra recovery: Brug retention til opbevaring/regelstyring, og brug backup til hurtig genskabelse efter fejl og angreb.
• Sæt tal på RPO/RTO: Beslut hvor meget data I må miste (RPO) og hvor længe I må være nede (RTO) – og test at I kan holde det.
• Planlæg for ransomware i skyen: Antag at angriberen forsøger at slette versionshistorik og papirkurve; vælg backup med beskyttelse mod sletning (immutability/uforanderlighed).
• Vælg “restore-niveau” før produkt: Skal I kunne genskabe et enkelt dokument, et helt site, et Team eller hele tenantens data?
• Gør NIS2 til en checkliste: Dokumentér processer, roller og restore-tests (ikke kun at backup “findes”). Se NIS2 artikel 21.

Hvorfor retention og papirkurv ikke er en backup

Microsofts indbyggede mekanismer (papirkurv, versionshistorik, retention policies) er primært lavet til opbevaring og governance. Det er ikke det samme som disaster recovery.

Det hænger sammen med Microsofts Shared Responsibility Model: Microsoft leverer platformen og oppetid, men I har ansvaret for data og genskabelse ved brugerfejl, insider-sletning og mange angrebsscenarier.

Praktisk tommelfingerregel

• Retention: “Vi skal kunne finde/holde på data i X år” (compliance).
• Backup: “Vi skal kunne genskabe data på Y minutter/timer” (drift).

Før → Efter #1:
Før: I tror, at en retention policy = sikker gendannelse.
Efter: I har en konkret restore-procedure og en testet backup, så et slettet SharePoint-site kan genskabes uden panik og uden manuel detektiv-arbejde.

Hvordan ransomware rammer SharePoint/Teams, når alt “ligger i skyen”

Ransomware i 2025/26 handler ofte ikke om at knække Microsofts datacentre. Det handler om at misbruge jeres identiteter, synkronisering og rettigheder. Når angriberen har adgang, kan de kryptere eller masse-overskrive filer i OneDrive/SharePoint og forsøge at fjerne spor ved at angribe papirkurve og versionshistorik.

Analytiker-konsensus fra bl.a. Gartner/Forrester peger på, at ransomware i stigende grad forsøger at forhindre restore via native værktøjer, og at mange virksomheder har oplevet SaaS-datatab, der ikke kunne genskabes fuldt ud med de indbyggede muligheder alene (se Gartner-oversigten: backup & recovery insights).

Hvad I skal kunne efter et angreb

• Genskabe til en kendt god version (før kryptering/overskrivning).
• Genskabe hurtigt og granulært (ikke kun “alt eller intet”).
• Genskabe selv hvis en kompromitteret admin-konto forsøger at slette backups.

Hvordan vælger I mellem Microsoft native, Microsoft 365 Backup Storage og 3. parts?

Der er groft sagt tre niveauer, når I kigger på backup af Office 365:

1) Native retention/papirkurv (standard)

• Styrke: Godt til governance og “oops”-fejl inden for de grænser, Microsoft har sat.
• Svaghed: Designet er ikke en fuld backup-strategi. Restore kan være tidskrævende, upræcist eller utilstrækkeligt i angrebsscenarier.
• Godt nok når: I kan leve med længere gendannelsestid, og påvirkningen ved datatab er lav.

2) Microsoft 365 Backup Storage (betalt Microsoft-service)

• Styrke: Fokus på hurtig restore (fx SharePoint/OneDrive) og tæt Microsoft-integration.
• Svaghed: Dækker ikke altid alle “granulære” eller tværgående behov på samme måde som specialiserede værktøjer (fx avanceret søgning/udtræk i historiske backups).
• Godt nok når: I primært vil optimere restore-hastighed på Microsofts datatyper og accepterer servicegrænserne. Se produktsporet: Microsoft 365 Backup Storage.

3) 3. parts backup (fx Veeam/Datto/AvePoint) som Managed Backup

• Styrke: Typisk mere fleksible restore-muligheder, bedre kontrol over retention/immutability og ofte stærk rapportering til revision/compliance.
• Svaghed: Kræver valg af leverandør, opsætning, overvågning og løbende test (det er en driftstjeneste, ikke et “køb og glem”).
• Godt nok når: I har lav tolerance for nedetid, høj risiko, eller I skal kunne dokumentere restore-tests og kontrolmiljø.

Før → Efter #2:
Før: Restore bliver et ad-hoc projekt, når noget går galt (“kan vi finde en kopi et sted?”).
Efter: I har faste restore-scenarier (SharePoint-site, Teams, OneDrive) med mål for RTO og en log over udførte tests, som I kan vise ledelse og revisor.

Tjekliste: sådan kravspecificerer I en backup-løsning til Microsoft 365

Brug listen som krav til IT, leverandør eller jeres MSP. Den tvinger jer til at vælge ud fra drift og risiko – ikke features.

Kravområde	Spørgsmål I skal kunne svare på	Hvad I kigger efter i løsningen
Scope	Hvilke workloads skal med (Exchange, OneDrive, SharePoint, Teams)?	Dækning pr. workload + tydelig afgrænsning af Teams-komponenter.
Restore-niveau	Skal I kunne genskabe enkeltfil, mappe, site, mailbox, Team?	Granulær restore + mulighed for restore til alternativ placering (”sandbox”).
RPO/RTO	Hvor meget data må I miste, og hvor hurtigt skal I op igen?	Konfigurerbare backup-intervaller + dokumenterede restore-tider via test.
Ransomware-resiliens	Hvad hvis en angriber får admin-rettigheder?	Uforanderlighed (immutability), MFA/rolleopdeling, sletningsbeskyttelse.
Adgang & separation	Hvem kan slette backup, ændre retention, eller eksportere data?	Least privilege, separate admin-konti, audit logs og godkendelsesflow.
NIS2/BCP	Kan I dokumentere backup management og DR-plan + test?	Rapporter, testprotokoller, runbooks og ansvar (RACI).
Økonomi	Hvad koster 1 dags nedetid vs. licens og drift?	En enkel ROI-model + mulighed for skalering pr. bruger/workload.

Fejl der koster jer dage: typiske huller i SMB-backup

• I har ingen restore-mål: Uden RTO/RPO bliver alt “når vi får tid”. Sæt mål pr. forretningskritisk område (fx SharePoint/Teams).
• I glemmer Teams som “samling”: Teams er ikke kun filer. I skal vide præcis, hvad der genskabes (kanaler, filer, mødenoter, apps/Planner afhænger af løsning).
• Backup uden test: Hvis ingen har prøvet en fuld restore, ved I ikke, om det virker – eller om I har rettighederne, når det brænder.
• Admin-konto = single point of failure: Hvis samme konto kan administrere både M365 og backup, kan en kompromittering tage det hele med.

Sådan kobler I NIS2-krav til jeres backup (uden at drukne i papir)

NIS2 nævner eksplicit backup management og disaster recovery som en del af sikkerhedsforanstaltningerne (artikel 21). Se lovteksten her: NIS2 Directive (EU).

For mange SMB’er handler det ikke kun om, om I er “direkte omfattet”. Kunder og leverandører forventer samme disciplin i forsyningskæden.

Minimumsdokumentation (det I faktisk skal kunne fremvise)

1. DR-runbook: Hvem gør hvad, når SharePoint/Teams er ramt (kontaktliste, beslutningspunkt, eskalering).
2. Restore-tests: Dato, scenarie, varighed, resultat, afvigelser og næste handling.
3. Adgangskontrol: Hvem har backup-admin, hvordan er MFA, og hvordan er roller adskilt.
4. Change-log: Når I ændrer retention, licenser eller scopes, opdaterer I dokumentation og tests.

FAQ: backup af Office 365 i praksis

Har Microsoft ikke backup af vores Microsoft 365-data?

Microsoft beskytter platformen og tilbyder retention/papirkurv, men I har ansvaret for at kunne genskabe data efter brugerfejl, insider-hændelser og mange angrebsscenarier. Det følger Shared Responsibility-modellen.

Hvad er forskellen på Office 365 retention policy vs backup?

Retention handler om at bevare data og håndhæve regler (fx opbevaring i X år). Backup handler om at gendanne data hurtigt og præcist til en tidligere tilstand. Hvis jeres primære mål er kort RTO, skal I have en rigtig backup.

Hvilke Microsoft 365 backup løsninger giver hurtigst restore?

Hurtighed afhænger af løsning og scenarie. Microsoft 365 Backup Storage er lavet til high-speed restore for udvalgte workloads (typisk SharePoint/OneDrive). 3. parts løsninger kan til gengæld være stærke på granulære restores, historik og kontrol, især når I skal kunne dokumentere tests og separation.

Kan ransomware slette vores versionshistorik og papirkurv i SharePoint?

Moderne angreb forsøger ofte at sabotere native gendannelsesmuligheder. Beskyt jer ved at have backup med sletningsbeskyttelse/immutability og ved at adskille backup-adgang fra jeres almindelige M365-adminkonti.

Hvordan vælger vi RPO og RTO for SharePoint og Teams?

Start med forretningen: Hvor mange timers dokument- og samarbejdsdata kan I tåle at miste (RPO), og hvor længe kan afdelinger arbejde uden SharePoint/Teams (RTO)? Sæt typisk strammere mål for fællesdrev/projektrum end for personlige OneDrive-områder, og bekræft målene via en restore-test.

Hvad kræver NIS2 konkret af vores backup?

I skal kunne vise, at I styrer backup og DR som en proces: klare roller, adgangskontrol, og regelmæssige tests med dokumenteret resultat. En “vi har en backup-licens” er ikke nok, hvis I ikke kan bevise, at I kan genskabe inden for jeres mål.

Beskytter backup mod “data poisoning” og Copilot-fejl?

Backup kan ikke forhindre, at dårlige data opstår, men den giver jer en undo-knap: I kan rulle tilbage til en kendt god version, hvis Copilot eller automatiseringer har spredt fejl, eller hvis data er blevet korrupte over tid.

Sådan kommer I i gang (konkrete skridt)

1. Kortlæg kritiske data: Notér hvilke SharePoint-sites/Teams der stopper driften, hvis de er væk.
2. Sæt RPO/RTO pr. område: Én side, max. 6 linjer. Få CFO/COO til at godkende.
3. Vælg restore-scenarier: Minimum: slettet Team, krypteret SharePoint-mappe, bortkommet OneDrive.
4. Indfør rolle-adskillelse: Separate backup-admins, MFA, og logning af alle ændringer.
5. Kør en restore-test hver kvartal: Mål tid, dokumentér afvigelser, og justér backup-scope og politikker.
6. Gem dokumentationen ét sted: DR-runbook + testlog, klar til kunde- og NIS2-dialog.