Diese Website verwendet notwendige Cookies für den Betrieb der Seite. Zusätzliche Dienste wie Statistik, Marketing oder externe Widgets werden ohne JavaScript nicht geladen. Weitere Informationen findest du in unserer Datenschutzerklärung.
Zurück zum Blog
Nexthosting Guide

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.

08.08.2026 44 Aufrufe
Minecraft Server Backups: Anleitung & Restore 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:

  • Automatische Backups im Control-Panel oder per Cron/Docker-Sidecar aktivieren
  • Aufbewahrungsregeln prüfen: eine ausreichende Anzahl täglicher Kopien behalten
  • Eine Wiederherstellung testen, bevor du sie brauchst
  • Backup-Ziel auf EU/Deutschland prüfen (DSGVO-Konformität)

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.


Wichtige Erkenntnisse

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.

Inhaltsverzeichnis

Welche Dateien gehören zwingend in ein Minecraft-Server-Backup?

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.dat
  • Bei Paper-Servern liegen Nether und End oft als separate Ordner; prüfe die tatsächliche Verzeichnisstruktur

Server-Konfiguration und Identität:

  • server.properties, whitelist.json, ops.json, banned-players.json, banned-ips.json, usercache.json

Mods, Plugins und Konfigurationen:

  • plugins/, mods/, config/ vollständig sichern; Versionstreue ist hier entscheidend, da ein Plugin-Update die Konfigurationsstruktur verändern kann

Datenbanken und Berechtigungen:

  • MySQL/MariaDB-Datenbanken per mysqldump exportieren, bevor das Backup läuft
  • LuckPerms- oder PermissionsEx-Daten exportieren (Ingame-Befehl oder direkter Datei-Export)

Was 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.


Welche Methoden und Tools eignen sich für automatisierte Backups?

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

Wie führst du sichere Hot-Backups mit RCON durch?

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.

  1. save-off senden: rcon-cli save-off deaktiviert das automatische Speichern. Der Server schreibt keine neuen Chunks mehr auf die Festplatte.
  2. save-all flush abwarten: 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.
  3. Archiv erstellen: 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.
  4. save-on wieder aktivieren: rcon-cli save-on gibt das automatische Speichern frei. Der Server läuft ohne Unterbrechung weiter.
  5. Alte Backups rotieren: 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.


Wie richtest du itzg/mc-backup mit Docker Compose ein?

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 Stunden
  • RCON_HOST: Hostname des Minecraft-Containers, z. B. mc; der Sidecar koordiniert save-off/save-all/save-on automatisch
  • INITIAL_DELAY: Wartezeit nach Containerstart, bevor das erste Backup läuft; sinnvoll auf 2m setzen, damit der Minecraft-Server vollständig hochgefahren ist
  • BACKUP_NAME / NAME_WITH_VERSION: Dateiname des Archivs; mit NAME_WITH_VERSION=true wird die Serverversion automatisch in den Dateinamen eingebettet
  • BACKUP_METHOD: tar für einfache Archive, rsync für inkrementelle Kopien, rclone für direkte Cloud-Uploads

Volume-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.


Wie stellst du ein Backup zuverlässig wieder her?

Eine Wiederherstellung unter Druck ist kein guter Zeitpunkt für Experimente. Übe den Prozess vorher auf einer Testinstanz.

  1. Server stoppen: Fahre den Minecraft-Server vollständig herunter, bevor du irgendetwas anfasst.
  2. Vorhandene Welt umbenennen, nicht löschen: 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.
  3. Backup entpacken: tar -xzf /backups/world_20260115_020000.tar.gz -C /srv/minecraft/ stellt die Welt am richtigen Pfad wieder her. Prüfe danach die Dateirechte.
  4. Server starten und Logs prüfen: Starte den Server und beobachte latest.log auf Chunk-Fehler oder fehlende Datenbankverbindungen.
  5. Spieler-Inventare und Fortschritt verifizieren: Logge dich ein, prüfe Inventar, Spawn-Punkt und Achievements.

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:

  • Server startet ohne Fehler in den Logs
  • Spieler-Inventare und Fortschritte korrekt
  • Keine Chunk-Fehler beim Betreten bekannter Bereiche
  • Datenbankverbindungen (MySQL/MariaDB) funktionieren
  • Optional: SHA256-Prüfsumme des Archivs mit gespeichertem Manifest abgleichen

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.


Wie oft solltest du Backups erstellen und wie lange aufbewahren?

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:

  • Cron-Job oder systemd-Timer für tägliche Backups einrichten
  • Healthcheck-Endpunkt (z. B. per curl an Healthchecks.io) nach jedem erfolgreichen Backup aufrufen
  • Bei Fehlschlag: E-Mail- oder Discord-Benachrichtigung
  • Monatlich eine vollständige Wiederherstellung auf einer Testinstanz durchführen

Profi-Tipp: Ein ungetestetes Backup ist kein Backup. Plane den monatlichen Restore-Test als festen Termin ein, nicht als optionale Aufgabe.


Warum reichen Snapshots allein nicht aus?

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:

  • Snapshots für kurzfristige Rollbacks (z. B. nach einem fehlgeschlagenen Plugin-Update)
  • Verschlüsselte Offsite-Backups für Resilienz gegen Hardware-Ausfall, Ransomware und Standortverlust
  • 3-2-1-Regel: 3 Kopien, auf 2 verschiedenen Medientypen, davon 1 offsite

Welches Setup empfiehlt sich für Server in Deutschland?

Die Wahl hängt davon ab, ob du deinen Server selbst hostest oder mietest.

Stack A: Gemieteter Gameserver

  • Nexthosting-Gameserver mit automatischen, versionierten Backups und Download-Zugriff per Control-Panel
  • Backup-Region: Deutschland/EU prüfen und bestätigen
  • Kein eigener Wartungsaufwand; Wiederherstellung per Panel in wenigen Klicks.

Stack B: Selbstgehosteter Docker-Server

  • itzg/mc-backup als Sidecar mit BACKUP_METHOD=rclone
  • rclone-Ziel: S3-kompatibler EU-Objektspeicher (z. B. Hetzner Object Storage, Backblaze S3 EU-Region) oder eigenes Nextcloud/On-Premises
  • restic für Verschlüsselung und Integritätsprüfung des Backup-Repositories
  • Für mehr Kontrolle und eigene Docker-Umgebungen eignet sich ein Nexthosting VPS Pro

DSGVO-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.


Welche Konfiguration ich für Community-Server empfehle

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.


Nexthosting übernimmt die Backup-Infrastruktur für dich

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.


Quellen