Een back-upstrategie voor je VPS

Een goede back-upstrategie voor een VPS heeft drie lagen: automatische serverback-ups om snel een complete server terug te zetten, dumps op applicatieniveau voor databases, en een versleutelde offsite kopie op een tweede locatie. Maak daarnaast een snapshot vóór elke riskante wijziging en test regelmatig het herstel, want een ongeteste back-up is alleen maar hoop.

Deze gids legt elke laag uit, met commando's voor Ubuntu 24.04 en Debian 12.

Begin met de 3-2-1-regel

De klassieke regel geldt nog steeds:

• 3 kopieën van je data (de live versie plus twee back-ups),
• op 2 verschillende soorten opslag of systemen,
• waarvan 1 offsite, op een andere locatie of bij een andere provider.

Op een VPS betekent dat meestal: de server zelf, de back-ups van de provider en een versleutelde kopie ergens anders.

Weet waartegen je je beschermt

Verschillende risico's vragen om verschillende lagen. Daarom is één methode nooit genoeg voor belangrijke data.

Laag 1: back-ups en snapshots van de provider

Automatische back-ups

Bij Wolkra kun je per server dagelijkse automatische back-ups aanzetten. Ze kosten 20% van de serverprijs en bewaren 7 herstelpunten. Een back-up legt de hele server vast, dus bij herstel krijg je het besturingssysteem, de configuratie en de data in één keer terug. Daarmee is het de snelste weg terug na een serieuze vergissing.

Snapshots

Snapshots maak je op aanvraag en worden per GB gefactureerd. Gebruik ze:

• vóór een upgrade van het besturingssysteem, een database of een grote nieuwe appversie;
• vóór je gaat experimenteren met firewall- of netwerkinstellingen;
• als sjabloon: je kunt nieuwe servers maken vanaf een snapshot.

Zie back-ups en snapshots en de documentatie voor de stappen.

Kopieën op schijfniveau consistent maken

Een back-up van een draaiende server is als de stekker eruit trekken: bestanden zijn consistent op bestandssysteemniveau, maar een database die midden in een schrijfactie zat, moet zich misschien herstellen. Databases zijn daarop gebouwd, maar een schone dump (laag 2) neemt elke twijfel weg.

Laag 2: dumps op applicatieniveau

PostgreSQL

sudo mkdir -p /var/backups/db && sudo chown postgres: /var/backups/db
sudo -u postgres sh -c 'pg_dump -Fc mydb > /var/backups/db/mydb-$(date +%F-%H%M).dump'

-Fc is het gecomprimeerde custom-formaat; zet het terug met pg_restore.

MariaDB of MySQL

sudo sh -c 'mariadb-dump --single-transaction --routines --all-databases | gzip > /var/backups/db/all-$(date +%F-%H%M).sql.gz'

--single-transaction geeft een consistente dump van InnoDB-tabellen zonder ze te vergrendelen.

In Docker

docker compose exec -T db pg_dump -U app app | gzip > ~/backups/app-$(date +%F).sql.gz

Inplannen en opruimen

Zet de dump in een script, laat het draaien via een systemd-timer of cron en verwijder daarna oude bestanden:

find /var/backups/db -type f -mtime +14 -delete

Laag 3: versleutelde offsite kopieën met restic

restic versleutelt, dedupliceert en stuurt back-ups naar allerlei doelen: een andere server via SFTP, of elke S3-compatibele objectopslag.

Installeren

sudo apt install -y restic

Een repository kiezen

De voorbeelden gebruiken SFTP naar een back-upserver die jij beheert. Een S3-compatibele bucket werkt op dezelfde manier, met s3:-repository-URL's en inloggegevens in omgevingsvariabelen.

sudo mkdir -p /etc/restic && sudo chmod 700 /etc/restic
openssl rand -base64 32 | sudo tee /etc/restic/password >/dev/null
sudo chmod 600 /etc/restic/password

sudo tee /etc/restic/env >/dev/null <<'EOF'
RESTIC_REPOSITORY=sftp:[email protected]:/srv/restic/web-1
RESTIC_PASSWORD_FILE=/etc/restic/password
EOF
sudo chmod 600 /etc/restic/env

Root heeft een SSH-sleutel nodig waarmee hij kan inloggen op backup.example.com (zie SSH-sleutels). Bewaar het restic-wachtwoord ook ergens buiten de server. Zonder dat wachtwoord kan niemand de back-ups lezen, jij ook niet.

Initialiseren en draaien

sudo bash -c 'set -a; . /etc/restic/env; restic init'
sudo bash -c 'set -a; . /etc/restic/env; restic backup /etc /var/www /var/backups/db /home --exclude-caches'
sudo bash -c 'set -a; . /etc/restic/env; restic snapshots'

Bewaartermijn

sudo bash -c 'set -a; . /etc/restic/env; restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune'

Zo bewaar je een week aan dagelijkse back-ups, een maand aan wekelijkse en een half jaar aan maandelijkse.

Automatiseren met een systemd-timer

/etc/systemd/system/restic-backup.service:

[Unit]
Description=restic backup
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
EnvironmentFile=/etc/restic/env
ExecStart=/usr/bin/restic backup /etc /var/www /var/backups/db /home --exclude-caches
ExecStartPost=/usr/bin/restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

/etc/systemd/system/restic-backup.timer:

[Unit]
Description=Nightly restic backup

[Timer]
OnCalendar=*-*-* 03:30
RandomizedDelaySec=15m
Persistent=true

[Install]
WantedBy=timers.target

sudo systemctl daemon-reload
sudo systemctl enable --now restic-backup.timer
systemctl list-timers restic-backup.timer

Laat de databasedump vóór restic draaien, bijvoorbeeld met een regel ExecStartPre= die je dumpscript aanroept.

Bescherming tegen een gehackte server

Krijgt een aanvaller roottoegang, dan kan hij back-ups verwijderen die de server kan bereiken. Verklein dat risico:

• geef de back-upgebruiker op het doel append-only-toegang waar de tool dat ondersteunt (de REST-server van restic heeft een modus --append-only);
• laat het opruimen (prune) vanaf een andere machine draaien;
• bewaar minstens één kopie op een plek waarvoor de server geen inloggegevens heeft.

Waarvan maak je een back-up?

• /etc voor de configuratie.
• Applicatiecode en uploads: /var/www, /srv, /opt of je appmap.
• Databasedumps, niet de ruwe databasebestanden.
• Docker-volumes van containers met state, of hun dumps.
• TLS- en app-secrets, versleuteld.
• Een korte README die beschrijft hoe je de server opnieuw opbouwt.

Meestal heb je /var/cache, /tmp, pakketcaches en Docker-imagelagen die je opnieuw kunt ophalen niet nodig.

Blokopslagvolumes

Staat je data op een blokopslagvolume, dan kun je het volume ontkoppelen en aan een nieuwe server koppelen. Dat helpt als een server uitvalt. Het blijft wel één kopie, dus neem het mee in restic of dumps, net als andere data.

Test het herstel

Kies een vast ritme, bijvoorbeeld maandelijks, en doe een van deze tests:

1. Volledige server: maak een nieuwe server van een back-up of snapshot, start hem onder een testnaam en controleer of de app werkt.
2. Bestanden: zet ze terug in een tijdelijke map en vergelijk.

sudo bash -c 'set -a; . /etc/restic/env; restic restore latest --target /tmp/restore-test --include /etc/caddy'
sudo bash -c 'set -a; . /etc/restic/env; restic check'

3. Database: laad een dump in een nieuwe database en voer een paar queries uit.

Met facturering per uur kost een testserver voor een uur heel weinig. Noteer hoe lang het herstel duurde; dat is je echte hersteltijd.

Een eenvoudig plan om over te nemen

Pas de getallen aan op hoeveel data je kunt missen en hoe snel je weer online moet zijn. Voor de rest van de serverinrichting, zie eerste stappen op een nieuwe VPS en een Ubuntu-server beveiligen.