Serverback-up: gids voor disaster recovery van gameservers

Op een gameserver is het duurste wat je kunt verliezen nooit de hardware — het zijn de data: spelerpersonages, inventarissen, gildegegevens, de economie en maanden aan opgebouwde voortgang. Zonder een degelijke serverback-up-strategie kan één schijfstoring, een verkeerde DELETE-query of een ransomware-aanval je community in één nacht uiteenslaan. Deze gids laat zien hoe je geautomatiseerde back-ups, een offsite kopie en een geteste herstelprocedure combineert tot één samenhangend systeem.

Wat moet je echt back-uppen?

Veel beheerders back-uppen alleen de database en ontdekken tijdens een ramp dat de helft van de server ontbreekt. Een volledig herstel vereist al deze lagen:

• Database: de speler-, account- en economiegegevens in MySQL/MariaDB. Hier zit de echte waarde.
• Spelbestanden: de serverkern (binary), questbestanden, instellingen en kaartdata.
• Configuratie: nginx/systemd-services, firewallregels, cron-definities.
• Geüploade inhoud: spelerlogo's, website-assets, logarchieven.

Een praktische regel: als je de server vanaf nul moest opbouwen, dan horen de bestanden die alles weer laten werken zodra je ze terugzet, thuis in je back-up.

De 3-2-1-regel

De industriestandaard is eenvoudig maar krachtig: 3 kopieën van je data, op 2 verschillende media, waarvan 1 volledig buiten de server. Een back-up op één enkele VPS is geen echte back-up — als de server sterft, sterft de back-up mee. De offsite kopie houdt je in leven, zelfs als het datacenter van je provider afbrandt.

Geautomatiseerde databaseback-ups

Voor de database is mysqldump het betrouwbaarste startpunt. Gebruik een transactionele dump zodat je een consistente momentopname vastlegt in plaats van tabel voor tabel:

#!/bin/bash
set -euo pipefail
STAMP=$(date +%F_%H%M)
DEST=/var/backups/db
mkdir -p "$DEST"

mysqldump --single-transaction --quick --routines \
  --databases player account log \
  | gzip > "$DEST/game_$STAMP.sql.gz"

# back-ups ouder dan 14 dagen verwijderen
find "$DEST" -name 'game_*.sql.gz' -mtime +14 -delete

--single-transaction maakt een consistente kopie zonder je InnoDB-tabellen te vergrendelen, dus je hoeft de live server nooit te stoppen. Draai het script met cron:

# crontab -e
0 */6 * * * /opt/scripts/db_backup.sh >> /var/log/db_backup.log 2>&1

Deze regel maakt elke zes uur een back-up. Een drukke server wil misschien per uur, een kleine community dagelijks. Bepaal je tolerantie voor verlies (RPO — de maximale hoeveelheid data die je je kunt veroorloven te verliezen) en kies het interval daarop af.

Incrementele back-ups voor bestanden

Elke keer alles kopiëren verspilt ruimte en bandbreedte. rsync verplaatst alleen wat veranderd is, en met --link-dest maakt het momentopnames die ongewijzigde bestanden delen als hard links:

rsync -a --delete \
  --link-dest=/var/backups/files/latest \
  /srv/gameserver/ \
  /var/backups/files/$(date +%F_%H%M)/
ln -sfn /var/backups/files/$(date +%F_%H%M) /var/backups/files/latest

Elke momentopname ziet eruit als een volledige kopie, maar neemt alleen ruimte in voor de bestanden die daadwerkelijk veranderden.

De offsite kopie

Zodra je lokale back-ups klaar zijn, stuur je ze van de server af. rclone werkt met tientallen opslagproviders zoals Backblaze B2, Wasabi en S3, en kan de overdracht versleutelen:

rclone sync /var/backups remote:game-backup \
  --transfers 4 --checksum --log-file /var/log/rclone.log

Gebruik waar mogelijk client-side versleuteling (rclone crypt), zodat de opslagprovider de inhoud van je bestanden nooit ziet. Als je synchronisatie het offsite doel back-ups laat verwijderen, zet dan de objectversiebeheer- of write-lock-functie van de provider aan — zo overleeft een oudere versie in de cloud, zelfs als ransomware je lokale back-ups wist.

De meest kritieke stap: test het herstel

Een ongeteste back-up is geen back-up, het is een wens. Doe regelmatig een echte herstelproef: pak de back-up uit op een lege testserver en bevestig dat de server echt weer tot leven komt.

gunzip < game_2026-06-28_0600.sql.gz | mysql -u root -p

Meet drie dingen tijdens deze proef: is de dump beschadigd (integriteitscontrole met gzip -t), hoe lang duurt de import (je RTO — hersteltijddoel), en zijn personage- en economiegegevens consistent. Vijftien minuten oefenen, één keer per maand, bespaart je uren paniek tijdens een echte ramp.

Veelgestelde vragen

Hoe vaak moet ik back-uppen?

Dat hangt af van hoeveel dataverlies je kunt accepteren. Op een actieve PvP-server zijn spelers gevoelig voor voortgang per uur, dus een uurlijkse databaseback-up is logisch. Op rustigere servers is een interval van zes uur of dagelijks genoeg. Bestanden hoeven alleen geback-upt te worden wanneer je ze daadwerkelijk wijzigt.

Is de back-up op dezelfde server bewaren voldoende?

Nee. Een back-up op dezelfde schijf is nutteloos bij een schijfstoring, en een back-up op dezelfde VPS is nutteloos als de server crasht. Minstens één kopie moet op een totaal andere locatie staan — cloudopslag of een ander datacenter.

Kan ik een consistente back-up maken zonder de live server te stoppen?

Ja. Voor InnoDB-tabellen geeft mysqldump --single-transaction een consistente momentopname terwijl de server draait. Aan de bestandskant is rsync compatibel met een draaiende server; veel losse bestanden in plaats van één enorm, continu beschreven bestand maakt het alleen maar soepeler.

Laten we samen het back-up- en herstelplan van je server opbouwen. Om geautomatiseerde back-ups, een versleutelde offsite kopie en een geteste herstelflow te ontwerpen, neem contact met me op.