Is multicloud een back-upstrategie?

Wat lost multicloud eigenlijk op?

Multicloud betekent dat je workloads draaien bij meer dan één cloudaanbieder, bijvoorbeeld AWS en Azure. Het lost de afhankelijkheid van één leverancier (vendor lock-in) op. Is de opzet ervoor gebouwd, dan blijven bepaalde diensten ook draaien als één aanbieder een regionale storing heeft.

Dat zijn echte voordelen. Je plaatst workloads waar ze het best passen, onderhandelt vanuit een sterkere positie en zit niet vast aan de prijzen of de roadmap van één aanbieder. Voor applicaties die zijn gebouwd om bij uitval over te schakelen (failover) kan een tweede cloud klanten bedienen terwijl de eerste herstelt.

Wat multicloud niet doet, is de data in die workloads beschermen. Het is verleidelijk om "onze data staat in twee clouds" te lezen als "onze data heeft een back-up". Dat klopt niet, en het verschil merk je pas als er iets misgaat. Die kloof dicht Backup as a Service.

Waarom beschermt multicloud je data niet?

Omdat de kopieën in een multicloudopzet live kopieën zijn. Worden data tussen platforms gesynchroniseerd of gerepliceerd, dan wordt een verwijdering, een corrupte schrijfactie of een ransomware-versleuteling mee gekopieerd, vaak binnen enkele seconden.

Cloudaanbieders zeggen dit zelf ook duidelijk over hun replicatie. In de documentatie over redundantie van Azure Storage schrijft Microsoft: "Redundantie beschermt tegen hardwarestoringen, niet tegen bewerkingen die data wijzigen." Hetzelfde geldt als je repliceert tussen aanbieders.

Zo raak je data kwijt in een multicloudomgeving:

• Gesynchroniseerde fouten: een beheerder verwijdert een bucket of een map en de synchronisatie haalt de data overal weg.
• Corruptie die zich verspreidt: een bug in een applicatie schrijft foute data en elke gekoppelde kopie neemt die over.
• Ransomware met beheerrechten: een aanvaller met cloudinloggegevens kan data versleutelen of verwijderen in elke omgeving waar die inloggegevens toegang toe geven.
• Geen weg terug in de tijd: zonder back-ups met versies is er geen schoon moment om naar terug te zetten.

Voor databescherming heb je drie eigenschappen nodig die multicloud standaard niet biedt: versiebeheer, isolatie van de inloggegevens voor productie en een geteste manier om terug te zetten.

Wat laten recente cloudstoringen zien over gedeelde afhankelijkheden?

Ze laten zien dat verborgen afhankelijkheden, vooral identiteit, DNS en gedeelde diensten, meerdere systemen tegelijk kunnen platleggen. Twee clouds helpen minder dan je verwacht als beide op hetzelfde falende onderdeel leunen.

Het geval Cloudflare is de les van multicloud in het klein. Cloudflare schreef dat de aanleiding weliswaar een storing bij een leverancier was, maar dat "we uiteindelijk verantwoordelijk zijn voor de afhankelijkheden die we kiezen". Eén opslagafhankelijkheid bij de cloud van een andere aanbieder legde de inlogdiensten stil voor klanten die niet wisten dat die afhankelijkheid bestond.

Dit komt vaker voor. In negen jaar monitoring zag de storingsanalyse 2026 van het Uptime Institute dat externe leveranciers van IT- en datacenterdiensten, waaronder de grote cloud- en internetbedrijven, goed waren voor ongeveer twee derde van de publiek gemelde storingen.

Multicloud of back-up: wat is het verschil?

Multicloud houdt diensten beschikbaar; een back-up maakt data herstelbaar. Ze beantwoorden verschillende vragen, dus een weerbare opzet heeft allebei nodig.

Op één punt komen ze samen. De CISA #StopRansomware Guide raadt aan een multicloudoplossing te overwegen voor cloud-to-cloud-back-ups, "voor het geval alle accounts bij dezelfde leverancier worden getroffen". Een tweede aanbieder is een goede plek voor een back-up, mits het echt een back-up is. De principes van het Britse NCSC voor ransomwarebestendige cloudback-ups leggen de lat: back-ups moeten bestand zijn tegen verwijdering, ook door gecompromitteerde beheeraccounts, en eerdere versies moeten terug te zetten blijven.

Heb je in een multicloudomgeving nog een back-up nodig?

Ja. Multicloud verkleint de kans dat alles tegelijk onbeschikbaar is. Het helpt niet op de dag dat iemand de verkeerde data verwijdert, een aanvaller ze versleutelt of een account wordt geblokkeerd of gesloten.

Het speelt ook voor de regelgeving. NIS2-artikel 21(2)(c) verplicht essentiële en belangrijke entiteiten om maatregelen te nemen voor bedrijfscontinuïteit, waaronder back-upbeheer en disaster recovery, en voor crisisbeheer. Uptime over twee clouds laat niet zien dat je verloren data kunt terugzetten. Herstellogs wel. Zie wat NIS2-artikel 21 vraagt.

Voor systemen die snel terug moeten, voeg je disaster recovery toe op standby-infrastructuur. Daarmee draaien je systemen weer na een calamiteit, zonder dat je hoeft te wachten tot een cloudaanbieder zijn eigen herstel heeft afgerond.

Hoe bouw je een weerbare datastrategie voor multicloud?

Houd multicloud voor beschikbaarheid en voeg een back-uplaag toe die erbuiten staat. Breng je afhankelijkheden in kaart, stel hersteldoelen vast en test ertegen.

1. Breng kritieke data en afhankelijkheden in kaart: op welke identiteitsprovider, DNS, SaaS-tools en opslag leunt elk systeem, in elke cloud?
2. Stel RPO en RTO per systeem vast: hoeveel werk je maximaal kwijt mag raken en hoe lang je maximaal uit de lucht mag zijn. Zie RTO en RPO uitgelegd.
3. Maak een back-up buiten de productieclouds: gebruik aparte inloggegevens, zodat één gecompromitteerd beheeraccount niet bij zowel productie als back-up kan.
4. Maak één kopie onveranderbaar en één air-gapped: volg de 3-2-1-1-0-regel.
5. Plan voor een uitval van identiteit: bewaar noodaccounts (break-glass accounts) en hersteldraaiboeken op een plek die bereikbaar is als single sign-on niet werkt.
6. Test terugzetten elk kwartaal en na grote wijzigingen: zie hoe je controleert of je back-up werkt.

We maken een back-up van workloads in AWS, Azure en Google Cloud en bewaren die in onze eigen Tier III-datacenters in Nederland en Duitsland, onder EU-recht en onafhankelijk van de Amerikaanse hyperscalers (grote cloudaanbieders). Back-ups zijn onveranderbaar met Object Lock, we bewaren een air-gapped kopie en beheeracties vragen MFA.

Wat je nu kunt doen

Multicloud is een goede keuze voor flexibiliteit en uptime. Het is geen back-upstrategie. Als je enige kopieën live kopieën in andere clouds zijn, kan één fout of één gecompromitteerd beheeraccount ze allemaal bereiken.

Begin met een lijst van de systemen die geen schoon herstelpunt hebben als er vandaag data wordt verwijderd. Voeg daarna een onafhankelijke, onveranderbare kopie toe buiten je productieclouds. In ons overzicht van Backup as a Service zie je hoe die laag werkt.

Wil je een second opinion over je multicloudopzet? Vraag een gratis assessment aan bij onze engineers, in het Nederlands, Duits of Engels.

Dit artikel is algemene informatie, geen juridisch advies.