Minecraft Server Backups: Anleitung & Restore 2026
Minecraft Server Backups richtig planen: sichere deine Welt regelmäßig, teste Wiederherstellungen und lerne praxistaugliche Backup-Strategien für 2026.
Minecraft Server Backups richtig planen: sichere deine Welt regelmäßig, teste Wiederherstellungen und lerne praxistaugliche Backup-Strategien für 2026.
Zuverlässige Minecraft-Server-Backups folgen drei Schritten: konsistente Hot-Backup-Sequenz per RCON (save-off → save-all flush → Kopie → save-on), tägliche Automatisierung und mindestens eine Offsite-Kopie auf EU- oder deutschem Speicher. Wer das umsetzt, schützt seine Welt vor Datenverlust durch Hardware-Ausfall, Fehlkonfiguration oder Ransomware.
Sofort-Checkliste:
Für selbstgehostete Server ist der Docker-Sidecar itzg/mc-backup die empfohlene Lösung. Für gemietete Server bietet ein Host-Panel mit automatischen, versionierten Backups den geringsten Wartungsaufwand.
Zuverlässige Minecraft-Server-Backups erfordern täglich automatisierte Sicherungen, die korrekte RCON-Sequenz für konsistente Kopien und mindestens eine verschlüsselte Offsite-Kopie in der EU.
| Thema | Details |
|---|---|
| Tägliche Automatisierung | Cron, systemd-Timer oder Docker-Sidecar täglich ausführen; manuell vor Updates. |
| RCON-Sequenz | save-off → save-all flush → Kopie → save-on verhindert korrupte Chunk-Dateien. |
| Offsite-Kopie (EU/DE) | Mindestens eine verschlüsselte Kopie außerhalb der primären Maschine in Deutschland oder der EU. |
| Retention-Staffelung | tägliche, wöchentliche und monatliche Kopien als bewährtes Aufbewahrungsschema. |
| Nexthosting | Automatische, versionierte Backups auf deutschen Servern, ohne eigene Infrastruktur. |
Wer nur die Weltordner sichert, verliert beim Ernstfall trotzdem die halbe Arbeit. Ein vollständiges Backup umfasst mehr als nur die Region-Dateien.
Weltordner (höchste Priorität):
world/, world_nether/, world_the_end/ inklusive der Unterordner region/, playerdata/, entities/, data/ und level.datServer-Konfiguration und Identität:
server.properties, whitelist.json, ops.json, banned-players.json, banned-ips.json, usercache.jsonMods, Plugins und Konfigurationen:
plugins/, mods/, config/ vollständig sichern; Versionstreue ist hier entscheidend, da ein Plugin-Update die Konfigurationsstruktur verändern kannDatenbanken und Berechtigungen:
mysqldump exportieren, bevor das Backup läuftWas du weglassen kannst:
logs/, crash-reports/ und das Server-JAR selbst sind nicht zwingend nötig. Dokumentiere aber die genutzte Serverversion (z. B. paper-1.21.4-build123.jar), damit du sie bei Bedarf neu herunterladen kannst.Profi-Tipp: Lege eine backup-manifest.txt ins Backup-Archiv: Serverversion, Datum, Liste der aktiven Plugins mit Versionsnummern. Das spart beim Wiederherstellen viel Zeit.
Es gibt vier praxiserprobte Ansätze. Welcher passt, hängt von deinem Setup ab.
Docker-Sidecar mit itzg/mc-backup
Der itzg/mc-backup-Container läuft als Sidecar neben dem Minecraft-Container, koordiniert Backups per RCON und unterstützt tar, rsync und rclone als Backup-Methode. PRE/POST-Hook-Variablen erlauben Datenbankdumps vor dem eigentlichen Backup. Gut für Container-Setups; erfordert aber grundlegende Docker-Kenntnisse und sorgfältige Volume-Konfiguration.
Spigot/Paper-Plugin „Server Backup“
Das Spigot-Plugin „Server Backup“ bietet Multithreaded-Backups mit Unterstützung für Dropbox, FTP und Google Drive als Ziel sowie dynamische Region-Backups zur Speicherplatzersparnis. Einfach zu installieren, aber prüfe genau, ob das Plugin auch playerdata/, plugins/ und Konfigurationsdateien vollständig mitsichert. Panel-Buttons sind nicht immer vollständig.
rclone und restic
rclone überträgt Dateien in Cloud-Backends wie Dropbox, S3-kompatible Objektspeicher oder WebDAV. Restic ergänzt das um clientseitige Verschlüsselung, Deduplizierung und Integritätsprüfung. Beide Tools lassen sich kombinieren: restic sichert lokal, rclone transportiert ins EU-Ziel. Für DSGVO-konforme Offsite-Backups nach Deutschland oder in die EU ist das die flexibelste Option.
Host-Panel-Backups
Viele Hosting-Anbieter bieten automatische, versionierte Backups direkt im Control-Panel. Das ist der komfortabelste Weg: keine eigene Infrastruktur, oft per API abrufbar. Prüfe dabei Retention-Tiefe, DSGVO-Konformität und ob der Backup-Endpoint in Deutschland oder der EU liegt.
| Methode | Komplexität | Datenresidenz-Kontrolle | Typisches RPO | Kosten-Tendenz |
|---|---|---|---|---|
| Docker-Sidecar | Mittel | Hoch | Stündlich bis täglich | Gering (eigene Infra) |
| Plugin (Panel) | Gering | Mittel | Täglich | Gering bis mittel |
| rclone + restic | Mittel bis hoch | Sehr hoch | Flexibel | Gering (Cloud-Storage) |
| Host-Panel | Sehr gering | Abhängig vom Anbieter | Täglich | Im Paket enthalten |
Wer den Server während des Betriebs kopiert, ohne die Schreibvorgänge zu stoppen, riskiert korrupte .mca-Dateien. Die korrekte Sequenz lautet: save-off → save-all flush → Kopie → save-on.
rcon-cli save-off deaktiviert das automatische Speichern. Der Server schreibt keine neuen Chunks mehr auf die Festplatte.rcon-cli save-all flush schreibt alle noch ausstehenden Daten physisch auf die Festplatte. Dieser Befehl blockiert, bis der Schreibvorgang abgeschlossen ist. Bei großen Welten kann das 10–30 Sekunden dauern; plane einen sleep 5-Puffer ein.tar -czf /backups/world_$(date +%Y%m%d_%H%M%S).tar.gz /srv/minecraft/world/ erstellt ein timestampbasiertes Archiv. Der Timestamp im Dateinamen verhindert, dass laufende Backups überschrieben werden.rcon-cli save-on gibt das automatische Speichern frei. Der Server läuft ohne Unterbrechung weiter.find /backups -name "world_*.tar.gz" -mtime +14 -delete löscht Kopien, die älter als 14 Tage sind, und verhindert volllaufende Laufwerke.Zugriffsrechte beachten: Das Backup-Skript sollte nur mit den minimal nötigen Rechten laufen. Lege einen dedizierten Backup-Nutzer an, der nur auf das Quellverzeichnis und das Backup-Ziel schreibt.
Profi-Tipp: Bei sehr großen Welten (über 5 GB) erhöhe den sleep-Puffer nach save-all flush auf 15–30 Sekunden und prüfe per rcon-cli save-all flush-Rückgabe, ob der Befehl wirklich abgeschlossen ist, bevor du mit dem Kopieren beginnst.
Der Sidecar-Ansatz trennt Backup-Logik sauber vom Spielserver. Ein minimales Compose-Setup besteht aus drei Services: dem Minecraft-Server selbst, dem Backup-Sidecar und einem optionalen Restore-Init-Container.
Wichtige Umgebungsvariablen:
BACKUP_INTERVAL: Intervall zwischen Backups, z. B. 24h für täglich oder 6h für alle sechs StundenRCON_HOST: Hostname des Minecraft-Containers, z. B. mc; der Sidecar koordiniert save-off/save-all/save-on automatischINITIAL_DELAY: Wartezeit nach Containerstart, bevor das erste Backup läuft; sinnvoll auf 2m setzen, damit der Minecraft-Server vollständig hochgefahren istBACKUP_NAME / NAME_WITH_VERSION: Dateiname des Archivs; mit NAME_WITH_VERSION=true wird die Serverversion automatisch in den Dateinamen eingebettetBACKUP_METHOD: tar für einfache Archive, rsync für inkrementelle Kopien, rclone für direkte Cloud-UploadsVolume-Konfiguration:
Das Daten-Volume des Minecraft-Servers wird im Sidecar als read-only eingebunden. Das Backup-Volume ist nur für den Sidecar beschreibbar. So kann der Sidecar keine Spielwelt versehentlich verändern.
PRE/POST-Hooks:
Mit PRE_BACKUP_SCRIPT lässt sich vor dem Backup ein Datenbankdump ausführen. POST_BACKUP_SCRIPT eignet sich für Benachrichtigungen oder Upload-Bestätigungen.
Profi-Tipp: rclone-Zugangsdaten gehören nicht in die Compose-Datei. Nutze Docker Secrets oder einen Host-seitigen Keyring (z. B. pass oder secret-tool), um API-Keys und Passwörter sicher zu verwalten.
Eine Wiederherstellung unter Druck ist kein guter Zeitpunkt für Experimente. Übe den Prozess vorher auf einer Testinstanz.
mv world world_broken_$(date +%Y%m%d) bewahrt die defekte Version als Fallback. Löschen ist endgültig; Umbenennen gibt dir eine zweite Chance.tar -xzf /backups/world_20260115_020000.tar.gz -C /srv/minecraft/ stellt die Welt am richtigen Pfad wieder her. Prüfe danach die Dateirechte.latest.log auf Chunk-Fehler oder fehlende Datenbankverbindungen.Selektive Wiederherstellung einzelner Spielerdaten:
Für einzelne playerdata/UUID.dat-Dateien benötigst du die UUID des Spielers (abrufbar per usercache.json). Kopiere nur die betroffene Datei aus dem Archiv, ohne die gesamte Welt zu überschreiben.
Restic-Workflow:
restic snapshots listet alle verfügbaren Snapshots mit IDs. restic restore SNAPSHOT_ID --target /srv/minecraft/ stellt den gewählten Stand wieder her. Mit restic check prüfst du die Integrität des Repositories vor dem Restore.
Verifikationscheckliste nach der Wiederherstellung:
Profi-Tipp: Stelle niemals direkt auf dem Live-Server wieder her, wenn du nicht sicher bist. Starte eine zweite Instanz auf einem anderen Port, lade das Backup dort und prüfe alles in Ruhe.
Für aktive Survival-Server gilt: täglich automatisiert, manuell vor jedem größeren Eingriff. Ein Server-Update, ein neues Plugin oder eine große Bauaktion sind gute Anlässe für ein manuelles Backup.
| Backup-Typ | Häufigkeit | Aufbewahrung |
|---|---|---|
| Täglich (Daily) | Jeden Tag | 14 Tage |
| Wöchentlich | Jeden Sonntag | 14 Tage |
| Monatlich (Archiv) | Erster des Monats | Monatliche Archivkopien |
Diese Retention-Staffelung folgt dem Prinzip, das auch Branchenempfehlungen für Backup-Strategien beschreiben: tägliche inkrementelle Kopien, wöchentliche vollständige Sicherungen und monatliche Archivkopien.
Automatisierung und Monitoring:
curl an Healthchecks.io) nach jedem erfolgreichen Backup aufrufenProfi-Tipp: Ein ungetestetes Backup ist kein Backup. Plane den monatlichen Restore-Test als festen Termin ein, nicht als optionale Aufgabe.
Snapshots sind punktuelle Abbildungen auf derselben Storage und schützen nicht zuverlässig vor Hardware-Ausfall oder Ransomware. Backups hingegen sind unabhängige Kopien an einem anderen Ort. Das ist kein Detailunterschied, sondern der entscheidende Punkt bei einem echten Datenverlust-Szenario.
Dazu kommt ein häufiges Missverständnis: Mojang-Entwicklungs-Snapshots (also Vorabversionen des Spiels) sind etwas völlig anderes als Storage-Snapshots. Automatisierte Snapshot-Pinner, die täglich neue Server-JARs herunterladen, verwalten Versionen, sichern aber keine Spielerdaten.
Empfohlene Strategie:
Die Wahl hängt davon ab, ob du deinen Server selbst hostest oder mietest.
Stack A: Gemieteter Gameserver
Stack B: Selbstgehosteter Docker-Server
BACKUP_METHOD=rcloneDSGVO-Hinweis:
Spielerdaten (UUID, IP-Adressen, Inventare) sind personenbezogene Daten im Sinne der DSGVO. Wähle Deutschland oder die EU als Backup-Ziel. Verschlüssele Backups sowohl während der Übertragung (TLS) als auch im Ruhezustand (restic, VeraCrypt oder ähnliches). Prüfe bei Cloud-Diensten, ob ein Auftragsverarbeitungsvertrag vorliegt.
Die meisten Community-Server scheitern nicht an fehlendem Backup-Wissen, sondern an fehlender Konsequenz. Ein perfektes Backup-Skript, das nach drei Wochen nicht mehr läuft, weil niemand den Fehler bemerkt hat, ist wertlos.
Meine Empfehlung für kleine bis mittlere Communitys: Kombiniere automatisierte Offsite-Backups mit gelegentlichen manuellen Snapshots vor risikoreichen Änderungen. Wer einen gemieteten Server betreibt, fährt mit einem Host-Panel besser als mit selbst gebauter Infrastruktur. Der Wartungsaufwand für Docker-Sidecar-Setups ist real und unterschätzt. Wer ihn nicht stemmen kann oder will, sollte ihn nicht auf sich nehmen.
Budget spielt eine Rolle, aber nicht die größte. Selbst günstiger EU-Objektspeicher kostet wenige Euro pro Monat für typische Minecraft-Weltgrößen. Die eigentliche Investition ist Zeit: für die Einrichtung, für monatliche Restore-Tests und für das Monitoring. Wer das nicht leisten kann, ist mit einem Managed-Angebot wie Nexthosting besser bedient, das Backups als Teil des Pakets mitliefert.
Ein letzter Punkt, der oft übersehen wird: Teste nicht nur, ob das Backup existiert, sondern ob der Server danach tatsächlich sauber startet. Chunk-Korruption zeigt sich manchmal erst beim Betreten bestimmter Bereiche, nicht beim Serverstart.
Wer keinen eigenen Backup-Stack betreiben möchte, bekommt bei Nexthosting automatische, versionierte Backups direkt im Control-Panel, deutsche Serverstandorte und eine einfache Wiederherstellung per Klick oder API. Kein Cron-Job, kein rclone-Setup, kein manuelles Monitoring.
Nexthosting-Minecraft-Server laufen auf NVMe-SSDs mit DDoS-Schutz und werden in Deutschland betrieben. Backups sind im Paket enthalten und lassen sich per API automatisiert abrufen. Für Betreiber, die mehr Kontrolle benötigen, stehen VPS-Optionen mit vollem Root-Zugriff bereit. Richte deinen Minecraft-Server bei Nexthosting ein und spare dir den Aufwand für eigene Backup-Infrastruktur.