Een Praktische VPS-back-upstrategie (3-2-1-regel)

Geschreven door het ApexVPS-team • Laatst bijgewerkt: juli 2026 • 7 min lezen

Een betrouwbare VPS-back-upstrategie is het verschil tussen een herstel in vijf minuten en een heel slechte week. Servers falen, schijven raken beschadigd, deploys gaan mis en een enkele verkeerd getypte opdracht kan een map wissen. Het Cloudflare Learning Center en de meeste infrastructuurteams wijzen op dezelfde eenvoudige discipline: de 3-2-1-regel. Deze gids laat zien hoe je die toepast op een echte virtuele server, welke tools je gebruikt en hoe je alles plant en test zodat een restore echt werkt wanneer je die nodig hebt.

Wat de 3-2-1-regel betekent

De 3-2-1-regel is een tientallen jaren oud back-upprincipe dat waar blijft, waar je server ook draait:

3 kopieën van je gegevens — de live kopie plus ten minste twee back-ups.
2 verschillende media- of opslagsystemen — zodat één enkele storing niet beide kopieën tegelijk kan uitschakelen.
1 offsite kopie — fysiek of logisch gescheiden van de machine die u beschermt.

Op een VPS betekent dit meestal uw draaiende server, een lokale back-uprepository en een versleutelde kopie die naar externe opslag op een andere locatie wordt gepusht. Het punt is redundantie zonder een gedeeld punt van falen.

Wat moet u back-uppen op een VPS

Het hele disk blok-voor-blok back-uppen is verspillend en traag. Een goed back-upplan richt zich op de drie zaken die echt moeilijk te reconstrueren zijn.

Applicatiegegevens en bestanden

Geüploade bestanden, website-mappen, containervolumes en alles wat gebruikers genereren. Typische paden zijn /var/www, /srv, /home en uw Docker-volume-map. Als u zelf apps host zoals een bestandsserver of wiki, is dit waar uw onvervangbare inhoud leeft — zie onze gids over een VPS voor self-hosting voor hoe die mappen meestal zijn ingedeeld.

Databases

Kopieer nooit live databasebestanden terwijl de service draait — u kunt een halfgeschreven, beschadigde staat vastleggen. Exporteer in plaats daarvan een consistente dump. Voor MySQL of MariaDB:

mysqldump --single-transaction --routines --triggers \
  -u backup -p mydatabase > /srv/backups/mydatabase.sql

De --single-transaction vlag geeft een consistente momentopname van InnoDB-tabellen zonder ze te vergrendelen. Gebruik voor PostgreSQL pg_dump in plaats daarvan:

pg_dump -U postgres -Fc mydatabase > /srv/backups/mydatabase.dump

Systeem- en serviceconfiguratie

De bestanden die uw server uniek maken: /etc (nginx, systemd-units, cron, SSH-configuratie), pakketlijsten, TLS-certificaten en firewallregels. Deze uit het geheugen herbouwen na een storing is precies het saaie werk dat back-ups bedoeld zijn te voorkomen.

Uw back-uptools kiezen

Drie tools dekken bijna elk VPS-geval. Kies op basis van hoeveel u waarde hecht aan deduplicatie en encryptie.

restic — versleutelde, gedupliceerde snapshots

restic is een moderne back-uptool met één binair bestand die standaard versleutelt en dupliceert. Initialiseer eenmalig een repository en voer daarna back-ups uit:

# One-time: create an encrypted repository
restic init --repo /srv/backups/restic

# Back up files and your database dump
restic -r /srv/backups/restic backup /etc /var/www /srv/backups/mydatabase.sql

# List what you have
restic -r /srv/backups/restic snapshots

BorgBackup — deduplicerende archieven

BorgBackup biedt vergelijkbare deduplicatie en compressie met een iets andere workflow:

borg init --encryption=repokey /srv/backups/borg
borg create --stats /srv/backups/borg::'{hostname}-{now}' /etc /var/www

rsync — eenvoudige spiegel van bestanden

Wanneer u alleen een snelle spiegel van bestanden naar een andere host nodig hebt, is rsync via SSH moeilijk te overtreffen:

rsync -aAX --delete /var/www/ [email protected]:/backups/www/

De -aAX vlaggen behouden rechten, ACL's en uitgebreide attributen; --delete houdt de spiegel in stap met de bron. rsync alleen bewaart geen versiegeschiedenis, daarom combineren veel teams het met restic of borg.

Automatiseer het schema met cron

Een back-up die u moet onthouden, is een back-up die niet zal gebeuren. Zet uw stappen in een script, maak het uitvoerbaar en plan het met cron. Bewerk uw crontab met:

crontab -e

Voeg dan regels als deze toe:

# Full file + config backup every night at 02:15
15 2 * * * /usr/local/bin/vps-backup.sh

# Database dump every hour on the hour
0 * * * * /usr/local/bin/db-dump.sh

Log de uitvoer en laat het script eindigen met non-zero bij falen, zodat u het kunt koppelen aan de monitoring- en alertfuncties die bij uw plan horen. Een stille back-upfout is erger dan geen back-up, omdat het veilig voelt.

Bewaar een echte offsite kopie

De "1" in 3-2-1 is het deel dat de meeste mensen overslaan. Een back-up op dezelfde server die het beschermt, verdwijnt met die server. Push een versleutelde kopie naar iets onafhankelijks — objectopslag, een externe SFTP-box of een andere provider. restic en borg schrijven beide direct naar externe repositories, bijvoorbeeld via SFTP:

restic -r sftp:[email protected]:/backups/restic backup /var/www

Omdat restic en borg versleutelen voordat de gegevens uw VPS verlaten, ziet de externe host nooit uw leesbare tekst. Snoei oude snapshots volgens een beleid, zodat opslag niet oneindig groeit:

restic -r /srv/backups/restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

Test uw herstellen — elke keer

Een ongeteste back-up is een gerucht. Plan een periodiek herstel naar een wegwerplocatie en bevestig dat bestanden en databases intact terugkomen:

# Restore the latest snapshot into a scratch directory
restic -r /srv/backups/restic restore latest --target /tmp/restore-test

# Verify repository integrity
restic -r /srv/backups/restic check

# Re-import a database dump into a scratch database
mysql -u root -p restore_test < /srv/backups/mydatabase.sql

Als het terugzetten slaagt en de gegevens matchen, heb je een strategie. Zo niet, dan heb je dat net geleerd op een dinsdagmiddag in plaats van tijdens een echte storing.

Snapshots zijn één laag, niet de hele strategie

Elk ApexVPS-plan bevat automatische back-ups — dagelijkse snapshots op Starter Pro en uurlijkse snapshots op Business — en ze zijn echt nuttig voor snelle rollbacks na een mislukte implementatie of een onbedoelde verwijdering. Maar wees eerlijk over wat ze zijn: een handige eerste laag die op ons platform draait. Ze vervangen niet de offsite, onafhankelijk geverifieerde kopie die de 3-2-1-regel vereist. Behandel platformsnapshots als je snelle lokale herstelpunt en draai je eigen restic- of borg-taak om te voldoen aan de offsite- en geteste-herstelonderdelen van de regel. Die gelaagde aanpak is wat een hoopvolle opzet scheidt van een veerkrachtige, of je nu apps zoals Nextcloud zelf host of een productiedatabase draait.

Je checklist voor een VPS-back-upstrategie

Alles bij elkaar genomen ziet een complete back-upstrategie voor een virtuele server er zo uit. Doorloop het een keer, script het en laat cron het voortzetten:

Identificeer wat ertoe doet — applicatiebestanden, database-dumps en de configuratie onder /etc.
Kies een tool — restic of BorgBackup voor versleutelde, gedupliceerde, versiebeheerde back-ups; rsync voor eenvoudige spiegels.
Dump databases consistent — mysqldump --single-transaction of pg_dump, nooit een ruwe kopie van live bestanden.
Automatiseer het — plan het script met cron en waarschuw bij elke exit-code die niet nul is.
Push één kopie offsite — versleuteld, op onafhankelijke opslag, met een verstandig bewaarbeleid.
Test herstel regelmatig — herstel naar een tijdelijke locatie en bevestig dat de gegevens intact zijn.

Doe deze zes dingen en de 3-2-1-regel stopt met theorie te zijn en wordt een gewoonte waar je infrastructuur op kan leunen. Het uur dat je vooraf besteedt aan de opzet is niets vergeleken met de kosten van ontdekken, midden in een incident, dat je enige kopie op de schijf stond die net is overleden.

Heb je een server nodig die je volledig beheert om dit te draaien? ApexVPS geeft je volledige root-toegang, NVMe-opslag en toegewijde resources in 39 datacenters — met alleen crypto-afrekening, geen kaart en geen KYC. Vergelijk dedicated VPS-plannen →

Veelgestelde Vragen

Tellen providersnapshots als een back-upstrategie?

Snapshots zijn één nuttige laag, maar geen complete strategie. Onze dagelijkse en uurlijkse snapshots beschermen tegen de meeste kortetermijnfouten, maar ze staan op hetzelfde platform als je server. Een volledige 3-2-1-back-upstrategie vereist nog steeds een onafhankelijke, offsite kopie die jij beheert en herstel dat je daadwerkelijk hebt getest.

Hoe vaak moet ik een VPS back-uppen?

Stem de frequentie af op hoeveel gegevens je kunt veroorloven te verliezen. Statische bestanden en configuraties kunnen dagelijks worden geback-upt, terwijl actieve databases vaak uurlijkse dumps rechtvaardigen. Gebruik cron om het schema te automatiseren, zodat back-ups nooit afhangen van het onthouden ervan.

Wat is de beste tool voor VPS-back-ups?

restic en BorgBackup zijn beide uitstekend: ze dedupliceren, comprimeren en versleutelen back-ups en ondersteunen offsite-repositories. rsync is prima voor eenvoudige bestandsspiegeling, en mysqldump of pg_dump verzorgen database-exporten. Veel opstellingen combineren een database-dump met een restic- of borg-run.

Hoe weet ik dat mijn back-ups echt werken?

Test herstel op een schema. Herstel naar een tijdelijke map, verifieer bestandsinhoud en checksums en importeer een database-dump in een tijdelijke database. Een back-up die je nooit hebt hersteld, is slechts een hoopvolle gok, geen herstelplan.