Website backup 3-2-1 regel: het minimum voor ransomware-bestendigheid

De website backup 3-2-1 regel is uitgevonden voor fotografen die filmrolletjes wilden bewaren, maar hij is in 2026 relevanter dan ooit voor website-eigenaren. Ransomware-aanvallen op Nederlandse MKB-sites zijn helaas geen uitzondering meer, en hosting-backup alleen is in mijn ervaring zelden voldoende. Goede backups maken het verschil tussen “we draaien morgen weer” en “we beginnen vanaf nul”. En vooral dat laatste wil niemand.

Dit artikel vertaalt de 3-2-1 regel naar wat hij voor een MKB-website concreet betekent, plus de moderne uitbreiding (3-2-1-1-0) die de meeste klanten nog niet kennen.

Wat de 3-2-1 regel betekent en waar hij vandaan komt

De regel is in 2005 op papier gezet door fotograaf Peter Krogh in zijn boek “The DAM Book”. Het achterliggende idee is ouder en gaat terug naar IT-praktijken uit de jaren 80, toen tape-backups en off-site opslag al gangbaar waren. Krogh bedacht alleen het ezelsbruggetje.

De regel zelf:

• 3 kopieen van je data (het origineel telt mee, dus 1 origineel + 2 backups)
• 2 verschillende media-typen (bv server-disk + cloud-storage)
• 1 kopie offsite (op een andere fysieke locatie)

Het doel: voorkomen dat één gebeurtenis (een brand, een ransomware-aanval, een diskcrash) al je kopieen tegelijk treft. Dat is wat ransomware in 2026 expliciet probeert te doen: ook je backup-snapshots versleutelen.

Website backup 3-2-1 regel toegepast: hoe ziet dit er echt uit?

Voor een typische WordPress-MKB-site vertaalt 3-2-1 zich zo:

• Kopie 1: je live site (database + bestanden op de hosting)
• Kopie 2: de hosting-backup van je provider (dagelijkse snapshot van Hostinger, Antagonist, etc.)
• Kopie 3: een offsite-backup bij een onafhankelijke partij (Backblaze B2, AWS S3, Wasabi)

Media-typen:

• Server-storage (de SSD op je hosting)
• Object-storage in de cloud (S3-compatibel)

Offsite:

• Een aparte cloud-provider die niet jouw hoster is

Dit is het minimum. Het kost typisch 1 tot 5 euro per maand aan storage voor een gemiddelde MKB-site. De inrichting eenmalig 2 tot 3 uur. Daarna draait het zonder dat je er nog naar omkijkt, mits je het wel periodiek test.

Waarom hosting-backup alleen niet voldoende is

Veel klanten denken dat een dagelijkse hosting-backup voldoende is. In de praktijk klopt dat in 9 van de 10 routine-scenario’s: een fout commit, een mislukte update, een ongeluk in WordPress. De hosting-backup van gisteren is dan precies wat je nodig hebt.

De problemen ontstaan in de tiende situatie:

1. Ransomware bereikt ook de backups. Een aanvaller die admin-rechten heeft op je hosting-paneel, kan vaak ook de backup-snapshots verwijderen. Dat is hun expliciete doel: niet alleen je data versleutelen, maar de herstelroute afsluiten.
2. Korte retentie. Veel hosters bewaren maar 7 tot 14 dagen backup. Ontdek je een infectie pas na drie weken (niet ongewoon bij subtiele backdoors): geen schone backup meer.
3. Geen integriteit-check. Je hoster maakt elke nacht een snapshot, maar test niet of die ook restorebaar is. Dat ontdek je pas op het moment dat het echt fout zit.
4. Hoster-failure. Datacenter brand, financiele issues bij je provider, een hosting-bedrijf dat ineens dichtgaat. Dat zijn zeldzame maar reele scenario’s.

Een offsite-backup bij een onafhankelijke partij dekt al deze gaten.

De moderne uitbreiding: 3-2-1-1-0 (immutable + restore-test)

CISA en NIST raden sinds 2020 een uitgebreidere variant aan:

• 3 kopieen
• 2 media-typen
• 1 offsite
• 1 immutable of air-gapped
• 0 fouten via verifieerbare restore-test

De 1 immutable: een backup-kopie die voor een ingestelde periode niet verwijderd of overschreven kan worden, zelfs niet door een admin met volle rechten. Beschermt tegen ransomware en tegen interne fouten (een ontslagen medewerker die uit wrok dingen wil wissen).

In de praktijk doe je dat met S3 Object Lock (compliance-mode) of B2 Object Lock. Stel een retention-periode in van bijvoorbeeld 30 of 90 dagen. Binnen die periode kan niemand het bestand verwijderen, ook jij niet.

De 0 fouten: maandelijks of kwartaalmatig een restore-test draaien naar staging. Documenteer datum, doorlooptijd en eventuele errors. Zonder restore-test weet je niet of je backups echt werken; je vermoedt het.

Twee media: welke combinaties werken voor websites

De “2 verschillende media-typen” was historisch belangrijk omdat tape en disk fysiek anders zijn. In de cloud-wereld is het soepeler geinterpreteerd: zolang het twee onafhankelijke opslag-systemen zijn, telt het.

Voor websites zijn de bruikbare combinaties:

• Server-disk + cloud object-storage (bv hosting-disk + Backblaze B2). De meest gangbare keuze.
• Server-disk + extern NAS bij beheerder. Werkt, maar vraagt actieve beheerder-workflow. Voor solo-MKB minder praktisch.
• Twee verschillende cloud-providers. Bv. hosting-backup + S3. Wettelijk telt het, technisch is het iets minder robuust dan disk + cloud.

Wat niet telt als twee media: twee verschillende mappen op dezelfde disk. Of een hosting-backup en een file-sync naar dezelfde server.

Offsite: concrete opties voor Nederlandse MKB

Vier opties die ik regelmatig inzet:

Backblaze B2. Goedkoopste (ongeveer USD 6 per TB per maand storage in 2026). Egress USD 10 per TB. Voor een 5 GB WordPress: USD 0,03 per maand. Datacenters in de EU (Amsterdam). Voor MKB met geen specifieke compliance-eisen: mijn standaardkeuze.

AWS S3. Datacenter eu-west-1 (Ierland) of eu-central-1 (Frankfurt). USD 23 per TB per maand voor Standard. Glacier Deep Archive USD 1 per TB voor backups die je zelden hoeft te restoren. Duurder dan B2, maar met enterprise-grade tooling.

Wasabi. USD 6,99 per TB per maand (per 1 juli 2026 wordt dit $7.99/TB), geen egress fees. Datacenters in Amsterdam (EU-Central). Goedkoper dan AWS, vergelijkbaar met B2.

Een tweede hoster. Heb je twee hosting-accounts (bv productie bij Hostinger, staging bij Antagonist): backup van de een naar de ander kan een eenvoudige offsite-laag vormen. Niet zo robuust als object-storage, wel een praktische optie voor wie alles in eigen handen wil houden.

Voor de juridische kant van offsite-storage: backups bevatten persoonsgegevens (klanten in WooCommerce, formulier-inzendingen), en je hebt een verwerkersovereenkomst nodig met je backup-provider. Voor juridische maatwerk-vragen verwijs ik door naar een privacy-advocaat. Lypii geeft daar geen juridisch advies over. Meer over verwerkersovereenkomsten staat in mijn artikel over een datalek op je website.

Restore-test: de 0 in 3-2-1-1-0 die iedereen overslaat

De restore-test is het onderdeel dat in de praktijk het minst wordt gedaan en bij een echt incident de grootste verrassingen oplevert. Ik kom regelmatig op sites waar er weliswaar backups draaien, maar waar de restore nog nooit is geprobeerd.

Een minimale restore-test:

1. Pak je meest recente offsite-backup.
2. Restore naar een staging-omgeving (een sub-domein, een lokale Docker, een tweede hosting-account).
3. Doe een korte rondje: kan ik inloggen? Werkt de homepage? Klopt de database-data?
4. Documenteer de doorlooptijd. Eerste restore duurt vaak 30-60 minuten voor een gemiddelde site.

Frequentie: minimaal kwartaalbasis. Bij webshops elke maand. Documenteer in een eenvoudig logboek: datum, gebruikte backup, doorlooptijd, eventuele errors.

Zonder restore-test heb je backups, geen herstel-plan. Het verschil zie je pas in de praktijk.

Mijn standaard backup-stack voor klanten

Per stack hieronder de concrete tooling die ik inzet.

WordPress:

• UpdraftPlus (gratis voldoende, Premium voor incrementeel + B2 add-on EUR 70 per jaar)
• Target: Backblaze B2
• Frequentie: database dagelijks, files wekelijks
• Retention: 30 dagen daily + 12 maandelijks

Alternatief voor WP-only: BlogVault (vanaf USD 89 per jaar). Sterker op incrementeel en restore-comfort.

Laravel:

• spatie/laravel-backup (gratis)
• Schedule via Laravel’s task-scheduler
• Target: S3 of B2 via Flysystem
• Frequentie: database elk uur of dagelijks, files wekelijks

Statamic:

• Site bestaat grotendeels uit content in Git → Git is je versie-control voor content
• Assets via een sync naar B2 of S3 (rsync of vergelijkbaar)
• Database voor user-data en cache: optioneel afhankelijk van de site

Statisch (Netlify, Vercel):

• Git-repo IS je backup van de site
• Build-artifacts indien gewenst naar object-storage
• Geen database, weinig actieve data, eenvoudigste case

Voor de officiele backup-richtlijnen van CISA (overheids-IT-richtlijn, breed bruikbaar): zie CISA’s data backup guidance. Engelstalig, technisch.

Wat ik aanraad om vandaag nog te doen

Een lijst die je binnen een uur kunt afwerken:

1. Inventariseer je huidige backup: wie maakt hem, waar staat hij, hoe oud is hij?
2. Probeer een restore op een staging-omgeving. Loopt het binnen 60 minuten? Lukt het uberhaupt?
3. Heb je geen offsite-kopie: maak vandaag een B2-account aan en doe een eerste sync.
4. Documenteer wat je nu hebt op een A4. Dat is je backup-plan in versie 1.

Voor wie liever de hele stack laat opzetten: een 3-2-1 backup-stack op een bestaande WordPress duurt 2-3 uur (€70 per uur kantoor). Daarna kost het structureel €1 tot €5 per maand aan storage. Geen 24/7-support, wel een gratis 15-minuten-check bij twijfel. Meer over WordPress onderhoud en wat backup-monitoring in een onderhoudscontract betekent.

Verbeteren boven herbouwen: een goede backup-stack maakt dat je nooit vanaf nul hoeft te beginnen.

Multi-stack: 3-2-1 werkt op elke stack. WordPress via UpdraftPlus, Laravel via spatie/laravel-backup, Statamic via git + rsync, statische sites via git + build-artifact-sync. De principes blijven gelijk, de tools verschillen.