Een server draaien zonder Metin2 backup-strategie is gewoon wachten tot de crash gebeurt. Een schijffout, een onvoorzichtige DELETE-query of een mislukte tabelwijziging kan maandenlange voortgang van spelers in seconden wissen. Het goede nieuws: met MySQL's eigen tools, gratis en in een paar regels shell, zet je volledig automatische, gecomprimeerde en geplande back-ups op. In deze gids loop ik door welke databases je moet back-uppen en hoe, met mysqldump en cron op een Linux-gebaseerde Metin2-server.
Welke databases gebruikt Metin2?
In een klassieke Metin2-installatie is de spellogica meestal verdeeld over meerdere aparte schema's. De exacte namen verschillen per distributie, maar typisch zie je:
- account — gebruikersaccounts, wachtwoorden, e-mail en ban-gegevens.
- player — personages, inventaris, items, gilde-data, queststatus. Dit is het meest kritieke en meest veranderende schema.
- common — item-proto, shop, mob en gedeelde configuratietabellen.
- log — handels-, drop- en spelerbewegingsregistraties. Vaak groot, maar verlies ervan stopt het spel niet.
In de praktijk zijn de account- en player-schema's goud waard; bij dataverlies hangt de reactie van spelers daar direct van af. Back-up ook common, want de enige kopie van je handmatige item-aanpassingen kan daar staan.
Een eenmalige back-up maken met mysqldump
Laten we eerst een handmatige back-up nemen om te bevestigen dat de tool werkt. mysqldump dumpt een heel schema naar een consistent SQL-bestand zonder de draaiende server te stoppen:
mysqldump -u root -p \
--single-transaction --quick \
--routines --triggers \
player > player.sql
De belangrijke vlaggen:
--single-transaction: maakt op InnoDB-tabellen een consistente momentopname zonder de tabellen te vergrendelen. Cruciaal zodat het spel niet bevriest terwijl je de live data in het Metin2 player-schema back-upt.--quick: streamt grote tabellen rij voor rij in plaats van ze in RAM te bufferen.--routines --triggers: neemt ook stored procedures en triggers mee.
Om meerdere schema's in één bestand te bundelen, gebruik je --databases:
mysqldump -u root -p --single-transaction --quick \
--routines --triggers \
--databases account player common > metin2_full.sql
Let op: heb je MyISAM-tabellen, dan garandeert --single-transaction daarvoor geen consistentie; dan heb je weinig schrijfverkeer op het back-upmoment nodig, of --lock-tables.
Een back-upscript schrijven
Voor automatisering maken we een herbruikbaar shellscript. We zetten de gedateerde bestandsnaam, compressie en het opruimen van oude back-ups op één plek. Sla het op als /usr/local/bin/metin2-backup.sh:
#!/bin/bash
set -euo pipefail
BACKUP_DIR="/var/backups/metin2"
DBS="account player common"
KEEP_DAYS=14
STAMP=$(date +%F_%H%M)
mkdir -p "$BACKUP_DIR"
for DB in $DBS; do
mysqldump --defaults-extra-file=/root/.my.cnf \
--single-transaction --quick \
--routines --triggers "$DB" \
| gzip > "$BACKUP_DIR/${DB}_${STAMP}.sql.gz"
done
# back-ups ouder dan 14 dagen verwijderen
find "$BACKUP_DIR" -name '*.sql.gz' -mtime +$KEEP_DAYS -delete
In plaats van het wachtwoord hard in het script te zetten, lezen we het uit een apart inlogbestand met --defaults-extra-file. /root/.my.cnf ziet er zo uit en mag alleen door root leesbaar zijn:
[client]
user=root
password=EEN_STERK_WACHTWOORD
chmod 600 /root/.my.cnf
chmod 700 /usr/local/bin/metin2-backup.sh
De regel set -euo pipefail maakt het script veilig: als een commando faalt, stopt het script, zodat er niet stilletjes een beschadigde of halve back-up wordt geproduceerd.
Plannen met cron
Nadat je het script handmatig hebt uitgevoerd en met ls -lh /var/backups/metin2 hebt bevestigd dat de .sql.gz-bestanden verschijnen, kunnen we naar het plannen. Bewerk de crontab van root:
crontab -e
Voor een volledige back-up elke nacht om 04:00 plus een extra elke 6 uur:
# min uur dag mnd weekdag commando
0 4 * * * /usr/local/bin/metin2-backup.sh >> /var/log/metin2-backup.log 2>&1
0 */6 * * * /usr/local/bin/metin2-backup.sh >> /var/log/metin2-backup.log 2>&1
De uitvoer naar een logbestand sturen (>> ... 2>&1) is belangrijk; de dag dat een back-up faalt, zie je daar waarom. Plaats de volledige back-up op het moment dat het spelersverkeer het laagst is om de drukke uren te vermijden.
Off-site kopie en verificatie
Een back-up op dezelfde machine gaat met je mee ten onder als de machine sterft. Kopieer de back-ups naar een andere server of naar object storage. Je kunt een eenvoudige rsync-regel aan het einde van het script toevoegen:
rsync -az "$BACKUP_DIR/" backup@backup-server:/metin2/
De meest overgeslagen stap is de hersteltest. Een back-up die nooit getest is, is geen back-up. Maak er een gewoonte van om de back-up één keer per maand terug te zetten in een lege testdatabase en erin te kijken:
gunzip < player_2026-06-28_0400.sql.gz | mysql -u root -p player_test
Als het aantal tabellen, de nieuwste personages en de item-records zijn zoals je verwacht, weet je dat de back-up echt werkt.
Veelgestelde vragen
Moet ik de server uitschakelen om een back-up te maken?
Voor InnoDB-tabellen niet. Omdat --single-transaction een consistente momentopname maakt, kan het spel online blijven. Voor MyISAM-tabellen is een korte lock of een moment met weinig verkeer beter voor volledige consistentie.
Hoe vaak moet ik back-uppen?
Het player-schema moet minstens dagelijks worden geback-upt, idealiter elke 6 uur, want daar wordt verlies het sterkst gevoeld. Omdat common en account minder vaak veranderen, is een dagelijkse back-up meestal genoeg. Stem het interval af op hoeveel uur dataverlies je kunt tolereren.
Schaadt compressie de prestaties?
gzip draait tijdens de dump en gebruikt CPU, maar omdat het de schijfschrijfacties sterk vermindert, is het netto-effect meestal positief. Voor zeer grote schema's kun je de tijd merkbaar verkorten door het parallelle pigz te gebruiken in plaats van gzip.
Wil je je server wapenen tegen dataverlies? Heb je hulp nodig bij het opzetten van automatische back-ups, monitoring en disaster recovery voor je Metin2-infrastructuur, neem dan contact met me op — laat me je helpen rustig te slapen zonder je data te verliezen.