aslain.dev
0%
01 Hizmetler 02 Hakkımda 03 Projeler 04 Stack 05 Blog 06 İletişim
← Tüm makaleler Metin2

Metin2 Backup: automatische Sicherung mit mysqldump und Cron

Einen Server ohne Metin2-Backup-Strategie zu betreiben, heißt einfach, auf den Crash zu warten. Ein Festplattenfehler, eine unachtsame DELETE-Abfrage oder eine misslungene Tabellenänderung kann monatelangen Spielerfortschritt in Sekunden auslöschen. Die gute Nachricht: Mit MySQLs eigenen Tools, kostenlos und in wenigen Zeilen Shell, richtest du vollständig automatische, komprimierte und geplante Backups ein. In dieser Anleitung gehe ich durch, welche Datenbanken du sichern solltest und wie, mit mysqldump und cron auf einem Linux-basierten Metin2-Server.

Welche Datenbanken verwendet Metin2?

In einer klassischen Metin2-Installation ist die Spiellogik meist auf mehrere getrennte Schemata verteilt. Die genauen Namen variieren je nach Distribution, aber typischerweise siehst du:

  • account — Benutzerkonten, Passwörter, E-Mail und Bann-Daten.
  • player — Charaktere, Inventar, Items, Gilden-Daten, Quest-Status. Das ist das kritischste und sich am häufigsten ändernde Schema.
  • common — Item-Proto, Shop, Mob und gemeinsame Konfigurationstabellen.
  • log — Handels-, Drop- und Spielerbewegungs-Protokolle. Oft groß, aber sein Verlust stoppt das Spiel nicht.

In der Praxis sind die Schemata account und player Gold wert; bei einem Datenverlust hängt die Spielerreaktion direkt davon ab. Sichere auch common, denn die einzige Kopie deiner manuellen Item-Anpassungen kann dort liegen.

Ein einmaliges Backup mit mysqldump

Nehmen wir zunächst ein manuelles Backup, um zu bestätigen, dass das Tool funktioniert. mysqldump exportiert ein ganzes Schema in eine konsistente SQL-Datei, ohne den laufenden Server zu stoppen:

mysqldump -u root -p \
  --single-transaction --quick \
  --routines --triggers \
  player > player.sql

Die wichtigen Optionen:

  • --single-transaction: erstellt bei InnoDB-Tabellen einen konsistenten Snapshot, ohne die Tabellen zu sperren. Entscheidend, damit das Spiel nicht einfriert, während du die Live-Daten im Metin2-player-Schema sicherst.
  • --quick: streamt große Tabellen zeilenweise, statt sie im RAM zu puffern.
  • --routines --triggers: schließt auch Stored Procedures und Trigger mit ein.

Um mehrere Schemata in einer Datei zu bündeln, verwende --databases:

mysqldump -u root -p --single-transaction --quick \
  --routines --triggers \
  --databases account player common > metin2_full.sql

Hinweis: Hast du MyISAM-Tabellen, garantiert --single-transaction für sie keine Konsistenz; dann brauchst du wenig Schreibverkehr zum Backup-Zeitpunkt oder --lock-tables.

Ein Backup-Skript schreiben

Für die Automatisierung erstellen wir ein wiederverwendbares Shell-Skript. Wir bündeln den datierten Dateinamen, die Komprimierung und das Aufräumen alter Backups an einer Stelle. Speichere es 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

# Backups älter als 14 Tage löschen
find "$BACKUP_DIR" -name '*.sql.gz' -mtime +$KEEP_DAYS -delete

Statt das Passwort fest ins Skript zu schreiben, lesen wir es mit --defaults-extra-file aus einer separaten Zugangsdatei. /root/.my.cnf sieht so aus und darf nur von root lesbar sein:

[client]
user=root
password=EIN_STARKES_PASSWORT
chmod 600 /root/.my.cnf
chmod 700 /usr/local/bin/metin2-backup.sh

Die Zeile set -euo pipefail macht das Skript sicher: Schlägt ein Befehl fehl, stoppt das Skript, sodass kein beschädigtes oder halbes Backup stillschweigend erzeugt wird.

Planung mit cron

Nachdem du das Skript manuell ausgeführt und mit ls -lh /var/backups/metin2 bestätigt hast, dass die .sql.gz-Dateien erscheinen, können wir zur Planung übergehen. Bearbeite die Crontab von root:

crontab -e

Für ein vollständiges Backup jede Nacht um 04:00 plus ein weiteres alle 6 Stunden:

# Min Std Tag Mon Wochentag  Befehl
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

Die Ausgabe in eine Logdatei umzuleiten (>> ... 2>&1) ist wichtig; an dem Tag, an dem ein Backup fehlschlägt, siehst du dort den Grund. Lege das vollständige Backup auf die Zeit, in der der Spielerverkehr am geringsten ist, um die Stoßzeiten zu vermeiden.

Off-site-Kopie und Überprüfung

Ein Backup auf derselben Maschine geht mit dir unter, wenn die Maschine stirbt. Kopiere die Backups auf einen anderen Server oder in einen Objektspeicher. Du kannst eine einfache rsync-Zeile am Ende des Skripts ergänzen:

rsync -az "$BACKUP_DIR/" backup@backup-server:/metin2/

Der am häufigsten übersprungene Schritt ist der Wiederherstellungstest. Ein nie getestetes Backup ist kein Backup. Mach es dir zur Gewohnheit, das Backup einmal im Monat in eine leere Testdatenbank zurückzuspielen und hineinzuschauen:

gunzip < player_2026-06-28_0400.sql.gz | mysql -u root -p player_test

Wenn die Tabellenanzahl, die neuesten Charaktere und die Item-Datensätze deinen Erwartungen entsprechen, weißt du, dass das Backup wirklich funktioniert.

Häufige Fragen

Muss ich den Server für ein Backup herunterfahren?

Für InnoDB-Tabellen nein. Da --single-transaction einen konsistenten Snapshot erstellt, kann das Spiel online bleiben. Für MyISAM-Tabellen ist für volle Konsistenz eine kurze Sperre oder ein Moment mit wenig Verkehr vorzuziehen.

Wie oft sollte ich sichern?

Das player-Schema sollte mindestens täglich gesichert werden, idealerweise alle 6 Stunden, denn dort wird der Verlust am stärksten spürbar. Da sich common und account seltener ändern, reicht meist ein tägliches Backup. Passe das Intervall daran an, wie viele Stunden Datenverlust du tolerieren kannst.

Schadet die Komprimierung der Leistung?

gzip läuft während des Dumps und beansprucht CPU, aber da es die Festplattenschreibvorgänge stark reduziert, ist der Nettoeffekt meist positiv. Bei sehr großen Schemata kannst du die Zeit deutlich verkürzen, indem du das parallele pigz statt gzip verwendest.

Willst du deinen Server gegen Datenverlust wappnen? Wenn du Hilfe beim Einrichten von automatischen Backups, Monitoring und Disaster Recovery für deine Metin2-Infrastruktur brauchst, nimm Kontakt mit mir auf — lass mich dir helfen, ruhig zu schlafen, ohne deine Daten zu verlieren.

Bu kategorideki tüm yazılar →

Devamı için