Eine Minecraft-Welt ist ein Verzeichnis voller Dateien, und es liegt nahe, es einfach zu kopieren. Das geht meistens gut, bis es einmal nicht gut geht: Der Server schreibt gerade Chunks auf die Platte, während die Kopie läuft, und die gesicherte Welt hat Löcher, zurückgesetzte Bereiche oder lädt gar nicht. Der Grund ist, dass der Server Änderungen gesammelt und zeitversetzt schreibt. Die Lösung sind zwei Befehle vor und einer nach der Kopie.
Was gesichert wird#
| Pfad | Inhalt | Wichtig? |
|---|---|---|
world/ | Oberwelt (bei Vanilla auch Nether und End als Unterordner) | ja |
world_nether/, world_the_end/ | Nether und End bei Paper, Spigot, Purpur | ja |
server.properties, ops.json, whitelist.json, banned-*.json | Einstellungen und Listen | ja, klein |
plugins/ bzw. mods/, config/ | Erweiterungen und ihre Daten | ja |
logs/, crash-reports/ | Protokolle | nein |
cache/, libraries/, die Server-JAR | herunterladbar | nein |
Wie der Server selbst aufgesetzt wird, steht in Minecraft-Server auf einem VPS, für Modpacks in Modpack-Server für Minecraft.
Der sichere Ablauf#
Drei Befehle an die Server-Konsole:
save-off # automatisches Speichern anhalten
save-all flush # alles Ausstehende jetzt auf die Platte schreiben, und warten
# … Kopie anfertigen …
save-on # automatisches Speichern wieder einschalten
save-off verhindert, dass der Server während der Kopie Dateien verändert. save-all flush schreibt vorher alles, was noch im Arbeitsspeicher hängt, und wartet, bis es fertig ist. Das Spiel läuft währenddessen weiter; Spieler merken nichts davon.
Wichtig: save-on muss auch dann kommen, wenn die Kopie fehlschlägt. Sonst speichert der Server nicht mehr, und beim nächsten Absturz ist alles seit der Sicherung verloren.
Befehle von außen: RCON#
Damit ein Skript die Befehle schicken kann, braucht der Server RCON:
# server.properties
enable-rcon=true
rcon.port=25575
rcon.password=<langes zufälliges passwort>
RCON gibt vollen Zugriff auf die Server-Konsole, das Passwort geht unverschlüsselt über die Leitung. Der Port gehört in der Firewall gesperrt; das Skript läuft auf demselben Server und spricht über 127.0.0.1. Mehr zur Firewall in Firewall auf dem VPS.
Als Werkzeug dient ein kleines RCON-Programm wie mcrcon oder rcon-cli. Ob es als Paket verfügbar ist, hängt von der Distribution ab; sonst bringt das Projekt fertige Programmdateien mit.
Das Sicherungsskript#
#!/bin/bash
# /usr/local/bin/mc-sicherung.sh
set -euo pipefail
SERVER=/srv/minecraft
ZIEL=/srv/sicherung/minecraft
RCON="mcrcon -H 127.0.0.1 -P 25575 -p $(cat /etc/minecraft-rcon.pw)"
STEMPEL=$(date +%F_%H%M)
aufraeumen() { $RCON "save-on" >/dev/null || true; }
trap aufraeumen EXIT # save-on kommt auch, wenn etwas schiefgeht
$RCON "save-off"
$RCON "save-all flush"
sleep 5
mkdir -p "$ZIEL"
tar -C "$SERVER" --zstd -cf "$ZIEL/welt-$STEMPEL.tar.zst" \
world world_nether world_the_end plugins config \
server.properties ops.json whitelist.json 2>/dev/null || true
# nur die letzten 14 lokal behalten
ls -1t "$ZIEL"/welt-*.tar.zst | tail -n +15 | xargs -r rm --
Das trap ist der wichtigste Teil: Es sorgt dafür, dass save-on in jedem Fall ausgeführt wird. Fehlende Ordner (etwa plugins bei Vanilla) ignoriert der tar-Aufruf. Das Passwort liegt in einer Datei, die nur root lesen kann, nicht im Skript.
Regelmäßig und nicht nur lokal#
Gestartet wird das Skript per systemd-Timer, zum Beispiel alle sechs Stunden mit OnCalendar=*-*-* 00/6:00:00. Mit Persistent=true holt er einen verpassten Lauf nach.
Die lokalen Archive schützen vor einem kaputten Chunk oder einem gesprengten Spawn. Sie schützen nicht vor einem Ausfall des Servers. Dafür gehören die Archive zusätzlich auf eine andere Maschine, am besten verschlüsselt mit Restic. Ob die Sicherung wirklich läuft, meldet dir ein Push-Monitor in Uptime Kuma.
Zurückspielen#
systemctl stop minecraft
cd /srv/minecraft
mv world world.defekt-$(date +%F) # nie überschreiben, erst beiseitelegen
tar --zstd -xf /srv/sicherung/minecraft/welt-2026-09-19_0600.tar.zst world world_nether world_the_end
chown -R minecraft:minecraft world*
systemctl start minecraft
Übe das einmal, bevor du es brauchst, am besten auf einer Kopie des Servers mit einem anderen Port. Beim ersten Versuch stellt sich oft heraus, dass ein Ordner fehlte oder die Rechte nicht stimmen. Das ist der Zeitpunkt, an dem du es erfahren willst, nicht wenn die Spieler warten.
Häufige Fragen#
Kann ich die Welt nicht einfach bei gestopptem Server sichern?#
Doch, das ist die sicherste Methode, kostet aber jedes Mal eine Unterbrechung. Für eine nächtliche Vollsicherung auf einem kleinen Server ist ein kurzer Neustart vertretbar; für häufige Sicherungen ist save-off der bessere Weg.
Wie groß werden die Sicherungen?#
Das hängt von der erkundeten Fläche ab und wächst mit der Zeit. zstd verkleinert Weltdaten deutlich, weil die Chunk-Dateien viel Wiederholung enthalten. Miss nach der ersten Sicherung nach und plane den Platz danach.
Mein Panel hat eine Backup-Funktion. Reicht die?#
Panels wie Pterodactyl bieten Sicherungen per Knopfdruck. Prüfe zwei Dinge: ob sie vorher speichern lassen (sonst gilt das Problem von oben) und wo sie liegen. Liegen sie auf demselben Server, fehlt dir die zweite Kopie.
Was ist mit Bedrock-Servern?#
Das Prinzip ist gleich, die Befehle heißen anders: save hold, dann save query, bis der Server meldet, dass die Dateien bereit sind, und danach save resume.
Kurz gesagt#
- Eine Welt im laufenden Betrieb zu kopieren, kann sie beschädigen.
save-off,save-all flush, kopieren,save-on, per RCON und Skript.trapsorgt dafür, dasssave-onauch nach Fehlern kommt.- RCON-Port nie öffnen, Passwort in einer Datei nur für root.
- Archive zusätzlich auf eine andere Maschine, und das Zurückspielen einmal üben.
Geschrieben aus dem laufenden Betrieb: MRMedia betreibt eigene Proxmox- Hosts, einen Backup-Server und Kundendienste in der EU. Fehler in einer Anleitung sind Fehler im eigenen Betrieb. Korrekturen bitte über Discord.