Server-Backup: Disaster-Recovery-Leitfaden für Gameserver

Auf einem Gameserver ist das Teuerste, das man verlieren kann, niemals die Hardware — es sind die Daten: Spielercharaktere, Inventare, Gildendaten, die Wirtschaft und monatelang aufgebauter Fortschritt. Ohne eine solide Server-Backup-Strategie kann ein einzelner Festplattenausfall, eine fehlerhafte DELETE-Abfrage oder ein Ransomware-Angriff Ihre Community über Nacht zerstreuen. Diese Anleitung zeigt, wie Sie automatische Backups, eine Offsite-Kopie und einen getesteten Wiederherstellungsplan zu einem stimmigen System verbinden.

Was Sie wirklich sichern müssen

Viele Admins sichern nur die Datenbank und stellen im Ernstfall fest, dass die Hälfte des Servers fehlt. Eine vollständige Wiederherstellung braucht all diese Ebenen:

• Datenbank: die Spieler-, Konten- und Wirtschaftsdaten in MySQL/MariaDB. Hier steckt der eigentliche Wert.
• Spieldateien: der Serverkern (Binary), Quest-Dateien, Einstellungen und Kartendaten.
• Konfiguration: nginx/systemd-Dienste, Firewall-Regeln, Cron-Definitionen.
• Hochgeladene Inhalte: Spieler-Logos, Website-Assets, Log-Archive.

Eine praktische Regel: Wenn Sie den Server von Grund auf neu aufbauen müssten, gehören genau die Dateien ins Backup, die nach dem Zurückspielen wieder alles zum Laufen bringen.

Die 3-2-1-Regel

Der Industriestandard ist einfach, aber wirkungsvoll: 3 Kopien Ihrer Daten, auf 2 verschiedenen Medien, davon 1 vollständig außerhalb des Servers. Ein Backup auf einem einzigen VPS ist kein echtes Backup — stirbt der Server, stirbt das Backup mit. Die Offsite-Kopie hält Sie am Leben, selbst wenn das Rechenzentrum Ihres Anbieters abbrennt.

Automatische Datenbank-Backups

Für die Datenbank ist mysqldump der zuverlässigste Ausgangspunkt. Verwenden Sie einen transaktionalen Dump, damit Sie eine konsistente Momentaufnahme erfassen statt Tabelle für Tabelle:

#!/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"

# Backups löschen, die älter als 14 Tage sind
find "$DEST" -name 'game_*.sql.gz' -mtime +14 -delete

--single-transaction erstellt eine konsistente Kopie, ohne Ihre InnoDB-Tabellen zu sperren, sodass Sie den Live-Server nie anhalten müssen. Führen Sie das Skript per cron aus:

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

Diese Zeile erstellt alle sechs Stunden ein Backup. Ein stark frequentierter Server möchte vielleicht stündlich, eine kleine Community täglich. Legen Sie Ihre Verlusttoleranz fest (RPO — die maximale Datenmenge, deren Verlust Sie sich leisten können) und wählen Sie das Intervall entsprechend.

Inkrementelle Backups für Dateien

Jedes Mal alles zu kopieren verschwendet Speicher und Bandbreite. rsync überträgt nur das Geänderte und erstellt mit --link-dest Snapshots, die unveränderte Dateien als Hardlinks teilen:

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

Jeder Snapshot sieht aus wie eine vollständige Kopie, belegt aber nur Platz für die tatsächlich geänderten Dateien.

Die Offsite-Kopie

Sobald Ihre lokalen Backups bereit sind, schieben Sie sie vom Server weg. rclone arbeitet mit Dutzenden Speicheranbietern wie Backblaze B2, Wasabi und S3 und kann die Übertragung verschlüsseln:

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

Nutzen Sie wo möglich clientseitige Verschlüsselung (rclone crypt), damit der Speicheranbieter den Inhalt Ihrer Dateien nie sieht. Wenn Ihre Synchronisierung dem Offsite-Ziel erlaubt, Backups zu löschen, aktivieren Sie die Objektversionierung oder Schreibsperre des Anbieters — so überlebt selbst dann eine ältere Version in der Cloud, wenn Ransomware Ihre lokalen Backups löscht.

Der wichtigste Schritt: die Wiederherstellung testen

Ein ungetestetes Backup ist kein Backup, sondern ein Wunsch. Führen Sie regelmäßig eine echte Wiederherstellungsübung durch: Spielen Sie das Backup auf einen leeren Testserver ein und bestätigen Sie, dass der Server tatsächlich wieder zum Leben erwacht.

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

Messen Sie bei dieser Übung drei Dinge: ob der Dump beschädigt ist (Integritätsprüfung mit gzip -t), wie lange der Import dauert (Ihr RTO — Wiederherstellungszeitziel) und ob Charakter- und Wirtschaftsdaten konsistent sind. Fünfzehn Minuten Probe einmal im Monat ersparen Ihnen im echten Ernstfall stundenlange Panik.

Häufige Fragen

Wie oft sollte ich Backups machen?

Das hängt davon ab, wie viel Datenverlust Sie akzeptieren können. Auf einem aktiven PvP-Server reagieren Spieler empfindlich auf stündlichen Fortschritt, also ist ein stündliches Datenbank-Backup sinnvoll. Auf ruhigeren Servern reicht ein Intervall von sechs Stunden oder täglich. Dateien müssen nur dann gesichert werden, wenn Sie sie tatsächlich ändern.

Reicht es, das Backup auf demselben Server zu behalten?

Nein. Ein Backup auf derselben Festplatte ist bei einem Festplattenausfall nutzlos, und ein Backup auf demselben VPS ist nutzlos, wenn der Server zusammenbricht. Mindestens eine Kopie muss an einem völlig anderen Ort liegen — Cloud-Speicher oder ein anderes Rechenzentrum.

Kann ich ein konsistentes Backup erstellen, ohne den Live-Server anzuhalten?

Ja. Für InnoDB-Tabellen liefert mysqldump --single-transaction eine konsistente Momentaufnahme, während der Server läuft. Auf der Dateiseite ist rsync mit einem laufenden Server kompatibel; viele einzelne Dateien statt einer einzigen riesigen, ständig beschriebenen Datei machen es lediglich reibungsloser.

Lassen Sie uns gemeinsam den Backup- und Wiederherstellungsplan Ihres Servers aufbauen. Um automatische Backups, eine verschlüsselte Offsite-Kopie und einen getesteten Wiederherstellungsablauf zu entwerfen, kontaktieren Sie mich.