Microsoft 365 Backup vs. Retention: bliv klar til gendannelse

De fleste Virksomheder opdager forskellen på retention og backup den dag, noget går galt: en mappe slettes, et Team ryger, eller ransomware krypterer SharePoint. Hvis jeres “plan” er papirkurv + retention, kan I ende med dagevis af oprydning, selvom data teknisk set findes. Målet er enkelt: I skal kunne gendanne hurtigt og dokumentere det.

• Skil compliance og genopretning ad: Brug retention til lovkrav/oprydning, og backup til hurtig gendannelse (definér ejerskab og politik pr. workload).
• Mål jeres RTO i praksis: Sæt et max for “hvor længe kan vi stå stille?” og test med en rigtig restore-øvelse (ikke kun en papirplan).
• Dæk Teams/SharePoint rigtigt: Kortlæg hvad der skal kunne genskabes (Teams, filer, struktur, tilladelser) og hvilke huller I har i dag.
• Beskyttelse mod backup-angreb: Kræv immutable/uforanderlig backup og separat adgangsstyring, så angribere ikke kan slette jeres redningskrans.
• Gør NIS2-beredskab konkret: Dokumentér backup management og disaster recovery, inkl. restore-tid og ansvar (ledelsen skal kunne svare på det).

Hvorfor retention ikke redder jer, når der skal gendannes

Retention er lavet til at bevare eller slette data efter regler. Det er godt til compliance og oprydning, og vi har selv skrevet om retention i SharePoint på bloggen. Problemet opstår, når retention bliver forvekslet med en gendannelsesplan.

Hvis I skal gendanne en hel Teams-kanal, en større SharePoint-struktur eller mange filer efter et angreb, bliver retention typisk en langsom og upræcis proces. I står og leder efter “hvad var slettet hvornår”, i stedet for at trykke “restore” til et kendt tidspunkt.

Før → Efter #1
Før: “Vi har retention, så vi er dækket.” Når en mappe med 80.000 filer ryger, bruger I timer/dage på at udpege og genskabe manuelt.
Efter: Backup med kendt RPO/RTO og testet restore-runbook. I kan gendanne en hel struktur til et tidspunkt og komme videre samme dag.

Hvorfor Microsoft 365 Backup stadig er jeres ansvar

Microsoft kører platformen, men I ejer data og konsekvenserne. Det er essensen af Microsofts Shared Responsibility Model: oppetid på infrastrukturen er én ting; jeres evne til at gendanne efter sletning, fejl eller malware er noget andet.

To hurtige tommelfingerregler:

• Sletning og fejl: Hvis en bruger sletter, flytter eller overskriver, er det jeres proces, der skal kunne rulle tilbage.
• Angreb: Hvis data krypteres, hjælper historik/papirkurv kun, hvis I kan gendanne i den mængde og hastighed, jeres drift kræver.

Sådan hænger NIS2 backup-krav sammen med jeres drift (RTO/RPO)

NIS2 (Article 21) peger direkte på “business continuity, such as backup management and disaster recovery”. I praksis bliver mange virksomheder målt på, om de kan fortsætte driften, ikke om de kan finde en fil om 14 dage.

Start med to tal, ledelsen kan forstå:

• RTO (Recovery Time Objective): Hvor hurtigt skal I være i gang igen? 4 timer, 24 timer, 3 dage?
• RPO (Recovery Point Objective): Hvor meget data må I miste? 15 min., 4 timer, 24 timer?

Før → Efter #2
Før: “Vi har backup et sted.” Ingen ved, hvor lang tid restore tager, eller hvem der gør hvad i en krise.
Efter: En dokumenteret plan med RTO/RPO pr. system + en kvartalsvis restore-test. I kan svare revisor/kunder: “Vi kan gendanne SharePoint på X timer, Teams på Y.”

Tjekliste: Backup vs. retention pr. Microsoft 365-workload

Brug skemaet her som beslutningsregel. Hvis I sætter kryds i “hurtig gendannelse kræves”, skal det typisk løses med en egentlig backup (native Microsoft 365 Backup eller en Office 365 backup løsning), ikke kun retention.

Workload	Typisk hændelse	Retention hjælper?	Backup bør dække?	Hvad I skal tjekke
SharePoint	Massesletning / kryptering	Delvist (langsommere ved mange objekter)	Ja	Restore af hel site/mapper, tilladelser, versionspunkt
OneDrive	Bruger rydder ud / fejl i synk	Delvist	Ja	Gendannelse efter fratrædelse, retention efter bruger-lukning
Teams	Team/kanal slettes	Ikke nok	Ja	Backup af Teams data inkl. filer/struktur og hurtig restore
Exchange	Mailbox/mapper slettes	Ofte ok til enkeltposter	Ofte ja	Restore af mailbox/kalender i bulk, eDiscovery vs. restore

Fejl der koster jer mest tid ved ransomware recovery

Truslen er ikke kun at blive ramt. Det er at stå stille bagefter. Ransomware-rapporter fra Sophos/CISA (2025) peger på, at angribere målrettet forsøger at ramme backups, og at immutable storage derfor bør være et krav, ikke en option.

Tre klassiske tidstyve

1. Backup uden immutability: Hvis en angriber kan slette eller ændre jeres backups, er I tilbage ved nul.
2. Samme admin-konto til alt: Hvis backup-administration ligger på samme identitet som M365-admin, øger I “blast radius”. Overvej separate roller og stærk MFA.
3. Ingen restore-test: I ved først, om en løsning virker, når I prøver at gendanne en større mængde data under tidspres.

Hvordan vælger I mellem Microsoft 365 Backup og en 3.-parts løsning?

I 2025/26 har Microsoft lagt meget vægt på hurtig gendannelse med Microsoft 365 Backup. Pointen for jer er ikke “native vs. 3. part” som religion, men hvilken model der rammer jeres krav til restore-hastighed og kontrol.

Brug disse valgkriterier

• Restore-hastighed ved store hændelser: Spørg leverandøren: “Hvor lang tid tager det at gendanne 1 TB SharePoint-data?” Få svaret i en test, ikke i en brochure.
• Granularitet: Kan I gendanne enkeltobjekter (filer, mapper, Teams-kanaler) uden at rulle alt tilbage?
• Immutable backup: Er backup uforanderlig, og i hvor lang tid? Hvem kan ændre politikken?
• Adgangsmodel: Kan backup-administration isoleres (separate konti/roller, MFA, logging)?
• Drift/overvågning: Hvem reagerer på fejl i jobs, og hvor hurtigt? Hvis I ikke har tid, så læg det i drift hos en MSP.

FAQ: Microsoft 365 Backup, retention og NIS2

Hvad er forskellen på Microsoft 365 Backup og retention?

Retention styrer hvor længe data bevares/slettes af compliance-hensyn. Microsoft 365 Backup handler om at kunne gendanne data hurtigt til et bestemt tidspunkt. Hvis jeres mål er hurtig recovery, er retention sjældent nok alene.

Er papirkurv og versionshistorik nok til virksomheden?

Til enkelte filer: ofte ja. Til massesletning, kryptering eller gendannelse af struktur (sites/Teams/mapper): typisk nej. Tommelfingerregel: Hvis I ikke kan leve uden SharePoint/Teams i 24 timer, så skal I have testet backup med dokumenteret RTO.

Hvad betyder NIS2 backup-krav i praksis?

At I skal kunne vise, at I kan fortsætte driften efter hændelser. Minimum: dokumenteret backup management, disaster recovery-plan og en gennemført restore-test. Det er især relevant, hvis I er en del af en forsyningskæde, hvor kunder spørger ind til beredskab.

Hvad skal vi kunne gendanne i Teams?

Start med det, der stopper arbejdet: Teams-filer (SharePoint), kanalstruktur og kritiske samarbejdsområder. Lav en liste over “kritiske Teams” og kræv, at de kan gendannes inden for jeres RTO. Overvej også data fra integrationer, hvis de er forretningskritiske.

Hvordan sætter vi RTO og RPO uden at gætte?

Tag udgangspunkt i jeres processer: hvor mange timer kan salg, drift og leverance stå stille? Sæt en foreløbig RTO pr. workload (fx SharePoint 8 timer, e-mail 24 timer) og valider den i en restore-test. Justér efter første øvelse.

Hvordan beskytter vi backups mod at blive slettet ved et angreb?

Krav: immutable/uforanderlig backup, separate admin-roller, stærk MFA og logging. Sørg for, at ingen “almindelig global admin” kan ændre eller slette backup-politikker uden ekstra kontrol.

Hvad koster en Office 365 backup løsning typisk?

Kig på to linjer: licens/backup pr. bruger + storage/retention. Bed om en pris baseret på jeres reelle datamængde og jeres RPO/RTO. Hvis prisen bliver “for lav”, er det ofte fordi restore-hastighed, support eller immutability ikke er med.

Sådan kommer I i gang: 7 konkrete skridt på 14 dage

1. Udpeg 3 kritiske workloads (typisk SharePoint, Teams, Exchange/OneDrive) og en forretningsansvarlig pr. område.
2. Sæt foreløbig RTO/RPO pr. workload i et simpelt skema (maks 1 side).
3. Kortlæg “hvad der skal gendannes”: sites, Teams, brugere, integrationer, samt hvilke data der er mest tidskritiske.
4. Vælg backup-model (Microsoft 365 Backup eller 3. part) ud fra restore-hastighed, granularitet og immutable krav.
5. Separér adgang: lav dedikerede backup-adminroller, håndhæv MFA og logning.
6. Kør en restore-test på en realistisk hændelse (fx gendan et slettet Team eller et SharePoint-site) og mål tiden.
7. Dokumentér resultatet i jeres beredskabsmappe til NIS2: hvem gør hvad, og hvad er jeres målte RTO.

Hvis I vil have hjælp til at designe, drifte og teste jeres Microsoft 365 Backup-setup, så se vores ydelser inden for Microsoft 365, IT-sikkerhed og compliance.