VPS backup strategie 3-2-1-1-0 in 2026: van snapshot tot immutable off-site replica

Volgens cijfers van het NCSC had 58% van de Nederlandse ransomware-slachtoffers geen werkende backup op het moment van een aanval. De gemiddelde schade voor het MKB komt uit op 150.000 euro per incident, met 21 dagen volledige bedrijfsstilstand. Wie wél een goed werkende backup heeft, betaalt 27 keer minder vaak losgeld. Backup is daarmee niet een IT-detail, maar de belangrijkste verzekering die je voor je VPS kunt afsluiten.

Toch is “ik heb een backup” in 2026 niet meer voldoende. Moderne ransomware zoekt actief naar gekoppelde backup-volumes en versleutelt die mee. In deze gids leggen we uit hoe je een serieuze backup-strategie opzet voor een Linux VPS, op basis van de geüpdatete 3-2-1-1-0 regel, met concrete tools en een werkend voorbeeld op Europese infrastructuur.

Waarom de klassieke 3-2-1 in 2026 niet meer genoeg is

De 3-2-1 regel komt uit 2005 en luidt: drie kopieën van je data, op twee verschillende mediatypes, met één kopie off-site. Goede basis, maar de regel is ontstaan in een tijd waarin ransomware nog een zeldzaamheid was. Vandaag de dag versleutelen aanvallers eerst je primaire data en proberen ze direct daarna je backup-server, je gemonteerde NAS en je cloud-sync mee te nemen. Een off-site backup die via SSH-credentials bereikbaar is, biedt geen bescherming als die credentials op de gehackte server stonden.

Daarom is de regel uitgebreid naar 3-2-1-1-0:

• 3: minimaal drie kopieën van je data (origineel plus twee backups).
• 2: opgeslagen op twee verschillende mediatypes.
• 1: minstens één kopie op een geografisch andere locatie.
• 1: minstens één immutable of air-gapped kopie die je zelfs met root-rechten niet kunt verwijderen.
• 0: nul fouten in de verificatie, getest met echte restores.

Die laatste twee cijfers zijn waar de meeste MKB-setups stuklopen. We werken ze hieronder concreet uit.

De vijf lagen vertaald naar een Linux VPS

Laag 1: VPS snapshots

De meeste serieuze cloud VPS-aanbieders (Hetzner, Scaleway, OVHcloud, DigitalOcean) bieden snapshots vanuit hun beheerpaneel of API. Een snapshot is een instant kopie van je hele virtuele schijf op de hypervisor, los van je VPS. Plan dagelijkse snapshots in, bijvoorbeeld via een cronjob die de provider-API aanroept. Snapshots zijn snel terug te zetten en ideaal voor “ik heb net iets stoms gedaan met een config file”.

Belangrijke beperking: snapshots staan in de regel bij dezelfde provider, vaak in hetzelfde datacenter. Als die provider zelf platgaat of jouw account wordt gecompromitteerd, ben je ze kwijt. Snapshots zijn daarmee de bovenste laag van je backup-piramide, niet de enige.

Laag 2: bestandsniveau-backup met restic, BorgBackup of Kopia

Voor file-level backups van je MySQL-dumps, applicatiebestanden, Nextcloud-data en config-directories heb je een serieuze backup-tool nodig. In 2026 zijn er drie open source kanshebbers die ertoe doen:

• restic (versie 0.17.1, mei 2026): praat native met S3, Backblaze B2, Azure Blob, Google Cloud Storage, SFTP en lokale schijven. Grootste community, beste documentatie, end-to-end encryptie standaard. Voor de meeste MKB-setups de juiste keuze.
• BorgBackup (1.4.4 stable, maart 2026): beste compressie en deduplicatie, laag geheugengebruik. Praat alleen via SSH naar een Borg-repository. Geen native cloud-support, maar in combinatie met rclone of borgmatic alsnog krachtig. Versie 2.0 staat al in beta, maar is nog niet productie-rijp.
• Kopia (0.23.0, mei 2026): heeft als enige een ingebouwde web-UI, scheduling en policy-management. Snelste backup-snelheid in benchmarks. Steile leercurve voor wie van de command line komt, maar erg geschikt als je een centrale backup-server wilt voor meerdere VPS’en.

Voor de meeste lezers van deze gids is restic de aanbevolen start. Het is goed gedocumenteerd, encrypted by default, en heeft een actieve Nederlandse en internationale community. Je leert het in een avond.

Laag 3: off-site target binnen de EU

De off-site kopie moet bij een andere partij staan dan je VPS-provider, en bij voorkeur in een Europees datacenter zodat je AVG-, NIS2- en dataresidency-eisen netjes invult. Goede opties in 2026:

• Hetzner Storage Box: vanaf 3,20 euro per maand voor 1 TB, ongelimiteerd dataverkeer, datacenters in Duitsland en Finland. Praat via SSH, SFTP, WebDAV en SMB. Werkt direct met restic, Borg en rclone.
• Backblaze B2: S3-compatibel, lage prijs per GB, datacenter in Amsterdam beschikbaar. Werkt native met restic via het S3-protocol.
• Wasabi EU of Impossible Cloud: S3-compatibele providers met Europese datacenters en native ondersteuning voor object lock (zie laag 4).

Let bij de keuze niet alleen op de prijs per GB opslag, maar ook op uitgaande bandbreedtekosten. Sommige Amerikaanse hyperscalers rekenen tot 9 cent per GB om je data weer op te halen. Bij een serieuze restore betaal je dan opeens honderden euro’s bovenop je maandelijkse opslag.

Laag 4: een immutable kopie tegen ransomware

Dit is het cijfer waar de meeste setups blijven steken. Een immutable kopie is een backup die, eenmaal geschreven, voor een ingestelde periode niet meer kan worden gewijzigd of verwijderd. Niet door een aanvaller, niet door jou, niet door je hosting-provider. De standaardimplementatie heet S3 Object Lock en geeft je write-once-read-many opslag.

Praktisch zet je dit op door bij je S3-compatibele provider (Backblaze B2, Wasabi, Impossible Cloud, AWS S3) een aparte bucket aan te maken met object lock in compliance mode en een retentieperiode van bijvoorbeeld 30 dagen. Restic schrijft daar zijn snapshots naartoe. Een aanvaller die op je VPS root weet te krijgen en de restic-credentials achterhaalt kan vervolgens niets met je oude backups uitrichten, omdat zelfs het opslagaccount de object-lock niet kan opheffen.

Voor een single-VPS setup die geen object lock nodig heeft is een goedkoper alternatief: gebruik een dedicated append-only SSH-key voor je BorgBackup-repository. Die kan wel schrijven, maar niet verwijderen. Dat is geen volwaardige immutability, maar wel een serieuze verbetering ten opzichte van een normale read/write-key.

Laag 5: nul fouten, periodieke restore-tests

Een onbeproefde backup is een gerucht. We zien in de praktijk dat MKB-bedrijven jarenlang trouw hun backups draaien, maar pas op het moment van een crash ontdekken dat de MySQL-dump leeg was, dat één directory ontbrak, of dat het encryptiewachtwoord nooit ergens veilig is opgeslagen. Bouw daarom restore-tests in als vaste routine:

• Wekelijks: automatische integriteitscheck (restic check of borg check).
• Maandelijks: een echte restore van een willekeurige snapshot naar een aparte test-VPS, en verifieer dat de applicatie boot.
• Kwartaal: een complete disaster recovery oefening. Doe alsof je primaire VPS niet meer bestaat en bouw vanaf nul opnieuw op op basis van je backup en je documentatie.

Tijdens die kwartaaltest komt vaak naar boven dat je infrastructure as code ontbreekt of incompleet is. Een goede distributiekeuze en een gedocumenteerde Ansible-playbook helpen je om binnen een uur weer in de lucht te zijn in plaats van een dag te puzzelen.

Een werkbaar voorbeeld voor het Nederlandse MKB

Stel je hebt een Linux VPS bij een Europese aanbieder met daarop een WordPress-site, een Nextcloud-instantie voor je team en een MySQL-database. Dit is een setup die voor de meeste MKB-bedrijven volstaat:

1. Snapshots via de provider, dagelijks om 03:00, met 7 dagen retentie. Kostprijs: ongeveer 0,01 euro per GB per maand.
2. Restic naar een Hetzner Storage Box, dagelijks om 04:00 na de database-dump. Retentie: 7 daily, 4 weekly, 12 monthly. Kostprijs: vanaf 3,20 euro per maand voor 1 TB.
3. Restic naar een S3-bucket met Object Lock bij Backblaze B2 of Wasabi EU, wekelijks. Retentie: 12 weken, niet wijzigbaar. Kostprijs: enkele euro’s per maand voor de meeste sites.
4. Wekelijkse restic check uit een aparte monitoring-VPS, met alert via je monitoring-stack als de check faalt.
5. Maandelijkse handmatige restore naar een test-VPS. Documenteer dat in een runbook in je wiki.

Totale extra kosten voor zo’n setup: ongeveer 7 tot 15 euro per maand. Dat is een fractie van een uur van een gemiddelde IT’er, en oneindig veel goedkoper dan de 150.000 euro die een ransomware-incident gemiddeld kost.

Veelgemaakte fouten bij VPS-backup

• Geen aparte database-dump. Een file-level backup van een draaiende MySQL- of PostgreSQL-server kan inconsistent zijn. Draai eerst mysqldump of pg_dump naar een dump-bestand, daarna pas restic.
• Backup-credentials op de bron-server. Als root op je VPS de delete-rechten heeft op je remote repository, kan ransomware die ook gebruiken. Werk met append-only keys of object lock.
• Niet getest, niet geverifieerd. Zonder de “0” uit 3-2-1-1-0 is je hele setup theorie.
• Eén bewaarperiode. Een backup van gisteren helpt niet als de aanvaller drie weken geleden al binnen was. Bewaar een ladder van retenties: dagelijks, wekelijks, maandelijks.
• Wachtwoorden alleen op de VPS. Bewaar het restic- of Borg-encryptiewachtwoord ook in een password manager buiten je VPS. Zonder dat wachtwoord is je backup waardeloos, ook voor jou.

Backup is geen project, het is een routine

De grootste fout die we tegenkomen is dat backup als eenmalig project wordt gezien: opzetten, vergeten, hopen dat het werkt. Een werkende backup-strategie vraagt om monitoring, periodieke restores en aanpassingen wanneer je stack verandert. Zet de check-momenten in je agenda en behandel een gefaalde backup-job met dezelfde urgentie als een server die offline gaat.

Wil je dit niet zelf opzetten? PC Patrol levert managed Cloud VPS hosting waar 3-2-1-1-0 backup standaard wordt ingericht, inclusief immutable off-site replica in een Europees datacenter en maandelijkse geautomatiseerde restore-tests. Onze servers staan bij een Nederlandse hostingpartner met datacenters in de EU. Plan een vrijblijvend gesprek via onze contactpagina en we kijken samen of je huidige backup-setup je bedrijf echt overeind houdt als het er op aankomt.