Schnellfinder

Was suchst du?

⌘/Ctrl + K öffnet den Finder · Esc schließt ihn
Gameserver

Gameserver Backup-Strategie: 3-2-1, Offsite, Retention und konsistente Saves

Gameserver Backups richtig planen: Dateninventar, 3-2-1, Offsite-Kopie, Rotation, konsistente Saves, Datenbank-Dumps und Wiederherstellbarkeit.

Inhalt dieses Guides
Kurz erklärt

Gameserver Backups richtig planen: Dateninventar, 3-2-1, Offsite-Kopie, Rotation, konsistente Saves, Datenbank-Dumps und Wiederherstellbarkeit.

Interaktiv

Server-Arbeitsmodus

Arbeite den Guide kontrolliert ab und ändere immer nur eine Variable. Dein Fortschritt bleibt nur in diesem Browser gespeichert.

0/5erledigt
Bei aktiviertem JavaScript werden Fortschritt und Auswahl nur lokal in diesem Browser gespeichert.

Die häufigste Backup-Frage lautet „Wie oft?“. Die wichtigere Frage ist zunächst: Welche Daten müssen gemeinsam wiederhergestellt werden, damit der Server wirklich funktioniert? Eine Weltdatei ohne passende Datenbank, Mods oder Konfiguration kann nutzlos sein.

Dateninventar erstellen

Liste Welt-/Save-Daten, Konfiguration, Mods/Plugins/Resources, Datenbank, Benutzer-/Rechtesystem, Scheduler und Secrets getrennt auf. Kennzeichne, was sich automatisch neu installieren lässt und was einzigartig ist.

3-2-1 als robuste Orientierung

CISA verweist auf die 3-2-1-Strategie: drei Datenkopien auf zwei unterschiedlichen Medien, davon eine Kopie außerhalb des primären Standorts. Für private Gameserver muss das nicht teuer sein: lokale Snapshots plus verschlüsseltes Offsite-Backup sind bereits deutlich besser als nur ein zweiter Ordner auf derselben SSD.

Offline oder logisch getrennt

Ransomware und Fehlbedienung können erreichbare Backups mitlöschen. Mindestens eine Kopie sollte deshalb nicht dauerhaft mit denselben Schreibrechten verbunden sein. Object Storage mit Versionierung oder ein Ziel mit getrennten Credentials kann das Risiko reduzieren.

Konsistenz beachten

Ein Save während aktiver Schreibvorgänge kann je nach Spiel unvollständig sein. Nutze dokumentierte Save-/Shutdown-Kommandos, Dateisnapshots oder Datenbankfunktionen. Bei SQL-Datenbanken ist ein sauberer Dump oder anwendungskonsistenter Snapshot oft besser als das Kopieren offener Datenbankdateien.

Retention nach Fehlerarten planen

Ein einziges tägliches Backup hilft nicht, wenn ein Modfehler erst nach einer Woche bemerkt wird. Kombiniere beispielsweise mehrere kurzfristige Stände mit einigen wöchentlichen und monatlichen Kopien. Die genaue Zahl hängt von Änderungsrate, Speicherbedarf und gewünschtem Recovery Point Objective ab.

Backup-Monitoring

Prüfe Exit-Code, Dateigröße, Alter und Zielerreichbarkeit. „Cronjob lief“ ist nicht gleich „Backup ist lesbar“. Ergänze regelmäßige Restore-Tests unter Restore testen.

RPO bewusst festlegen

Das Recovery Point Objective beschreibt praktisch, wie viel Fortschritt du im schlimmsten Fall verlieren kannst. Wenn stündliche Backups zu teuer sind, akzeptierst du bewusst mehr möglichen Datenverlust. Für sehr aktive Welten kann eine Kombination aus häufigen lokalen Snapshots und selteneren Offsite-Kopien sinnvoll sein.

Dokumentiere außerdem Verschlüsselung und Schlüsselaufbewahrung. Ein perfekt verschlüsseltes Offsite-Backup ist wertlos, wenn der Entschlüsselungsschlüssel nur auf dem ausgefallenen Server lag. Schlüssel und Wiederherstellungsanleitung gehören in einen getrennten, geschützten Notfallpfad.

Quellen

Nächster Schritt

Passend dazu