Veel organisaties gaan er onbewust vanuit dat Microsoft 365 “wel goed zit” als het om back-up gaat. En ja: Microsoft is goed in beschikbaarheid. Maar beschikbaarheid is niet hetzelfde als herstelbaarheid. Retention, prullenbakken en versiebeheer helpen tegen kleine fouten, maar ze zijn geen garantie dat je na een serieus incident snel terug bent naar “zoals het was”.
De echte vraag is: kun je herstellen binnen de tijd die je business nodig heeft, en ook als je primaire omgeving zelf het probleem is? Denk aan ransomware op tenant-niveau, massale verwijdering, een verkeerd ingestelde policy, of een gecompromitteerd admin account. In dat soort scenario’s wil je niet ontdekken dat je back-up “in hetzelfde mandje” zat, of dat herstel alleen werkt als de onderliggende cloud-infrastructuur nog precies meewerkt.
Daarom draait een goede cloud back-up aanpak om drie dingen: 3-2-1, immutability, en hersteltesten. Niet om aannames.
Kader: back-up vs retention (belangrijker dan het klinkt)
Retention (bewaarbeleid) is geen back-up. Retention is bedoeld om informatie langer te bewaren voor compliance en om “per ongeluk verwijderen” te kunnen herstellen binnen de Microsoft 365 omgeving. Het is geen volledige disaster recovery-oplossing.
Back-up is bedoeld voor herstelbaarheid: je kunt data (en waar nodig configuratie) terugzetten naar een bruikbare toestand, binnen een afgesproken RPO/RTO.
Vuistregel: als je herstel alleen werkt zolang dezelfde omgeving, identiteiten en beheervlakken nog intact zijn, dan heb je waarschijnlijk geen back-upstrategie maar een “recovery feature-set”.
Waarom Microsoft 365 alleen niet genoeg is
Microsoft 365 biedt veel herstelopties die waardevol zijn voor dagelijkse fouten:
- prullenbakken en retentie
- versiegeschiedenis
- eDiscovery en legal hold
Maar bij grotere incidenten ontstaan er typische blinde vlekken:
- Tenant-compromise: een aanvaller met adminrechten kan data verwijderen, policies aanpassen en herstel frustreren.
- Ransomware en massale encryptie/verwijdering: ook “legitieme” acties kunnen zich snel verspreiden.
- Misconfiguratie: één verkeerde Conditional Access-, sharing- of lifecycle-policy kan grote gevolgen hebben.
De 5 scenario’s waar je back-up tegen moet kunnen
- Ransomware of data sabotage in de tenant
- Compromised admin account (Entra ID, privileges, recovery paths)
- Mass delete of foutieve automation
- Operationele fouten (per ongeluk verwijderen, fout beleid, fout script)
- Grote verstoring bij de provider (zeldzaam, maar enorme impact)
Praktische framework
De 3-2-1 regel blijft bruikbaar, ook in SaaS:
- 3 kopieën van je data
- op 2 verschillende ‘media’/platformen (dus niet alleen binnen dezelfde beheercontext)
- waarvan 1 off-site / off-platform
Het punt is niet dat “de cloud geen back-up kan zijn”. Het punt is dat je back-up niet volledig mag meefalen met hetzelfde beheer- of identiteitsvlak.
Als je back-ups immutable zijn, kan een aanvaller (of beheerfout) ze niet stilletjes overschrijven of verwijderen. Dit is een van de meest effectieve maatregelen tegen ransomware.
Een back-upoplossing is zo sterk als:
- het identity model (MFA, least privilege, break-glass)
- de scheiding tussen productiebeheer en back-upbeheer
- de logging en alerting op kritieke acties
RPO/RTO horen geen papieren waarden te zijn.
- RPO: hoeveel data mag je maximaal kwijtraken?
- RTO: hoe snel moet je weer operationeel zijn?
Als je niet test, weet je het niet.
M365 vs Azure: andere workloads, andere herstelpijn
Herstel draait vaak om:
- mailboxen en items
- sites, libraries en permissies
- Teams (incl. private channels) en bijbehorende bestanden
Bij Azure is “restore” vaker een combinatie van:
- data terugzetten
- infra opnieuw opbouwen
- configuratie herstellen (RBAC, policies, netwerk)
Daarom is “we hebben back-updata” niet hetzelfde als “we kunnen herstellen naar werkende dienstverlening”.
Checklist: 10 vragen om je back-up aanpak te toetsen
- Welke workloads dek je aantoonbaar: Exchange, SharePoint, OneDrive, Teams en (waar nodig) Entra ID?
- Kun je niet alleen data, maar ook permissies en configuraties herstellen (waar relevant)?
- Hoe bescherm je back-ups tegen tenant-compromise (apart beheer, least privilege, MFA)?
- Voldoe je aan 3-2-1 op een manier die echt “off-platform” is?
- Zijn back-ups immutable/WORM tegen ransomware?
- Zijn RPO en RTO concreet en realistisch?
- Kun je granular restoren (mail item, bestand, Teams channel) én volledige restore waar nodig?
- Hoe herstel je als de primaire omgeving zélf de oorzaak is (identity, beheer, access)?
- Doe je periodieke restore tests, en leg je bevindingen vast?
- Is governance belegd (owner, besluitvorming, testfrequentie, acceptatie van risico’s)?
Conclusie
Een goede back-upstrategie voor Microsoft 365 en Azure draait om één vraag: kun je herstellen onder stress, binnen de tijd die je nodig hebt, en ook als ‘hetzelfde mandje’ het probleem is?
Als je dit niet getest hebt, weet je je RTO/RPO niet.
Intake: back-up situatie en aanpak beoordelen
Wil je dit snel scherp krijgen? Plan dan een back-up intake. In 45–60 minuten lopen we je huidige aanpak langs en krijg je kort en concreet advies terug met:
- de grootste gaps en single points of failure
- minimale set verbeteracties (prioriteit)
- wat je als eerste moet testen (restore test plan light)
