Minecraft-Server sichern: Backup und Restore

Ein Backup ist ein Versprechen an dein späteres Ich, und das hat selten gute Laune, wenn es einlöst. Diese Anleitung macht das Versprechen prüfbar.

Kurz gesagt

Ein Minecraft-Server-Backup ist eine Kopie des Serververzeichnisses, gezogen in einem konsistenten Zustand der Weltdateien, auf einem zweiten Rechner abgelegt und einmal testweise zurückgespielt. Auf einem laufenden Java-Server lautet die Folge save-off, save-all flush, kopieren, save-on [1][2]. Schick diese Befehle per RCON aus einem Skript. Halte das RCON-Passwort aus dem Skript heraus und sorg dafür, dass save-on auch dann läuft, wenn das Kopieren scheitert. Unsere Einschätzung: Der Restore-Test macht aus einer Datei erst ein Backup, mach ihn also, bevor du ihn brauchst. Alles hier gilt für deine eigenen Welten und Server.

So funktioniert’s

1. Was gesichert wird. Die Welt liegt in dem Ordner, den level-name nennt, standardmäßig world [3]. Das Minecraft Wiki empfiehlt, das ganze Serververzeichnis zu kopieren, weil du so auch server.properties, die Sperrlisten und die übrige Konfiguration bekommst [2]. Wir schließen uns an, mit zwei Ausnahmen, die sich neu erzeugen lassen: Logs und Crash-Reports. Der Aufbau der Welt änderte sich mit Minecraft 26.1. Vorher lag bei Vanilla die Oberwelt im Weltordner, Nether und End in DIM-1 und DIM1, und Paper führte sie in eigenen Ordnern world_nether und world_the_end [18]. Seit 26.1 liegen alle Standarddimensionen unter dimensions/minecraft/ im Weltordner, und die Spielerdateien wanderten in einen Ordner players mit data, stats und advancements [5][6]. Papers Weltkonfiguration folgt demselben Muster, in world/dimensions/<Namensraum>/<Dimension>/paper-world.yml [8]. Kopierst du das ganze Verzeichnis, musst du dich um den Aufbau nicht kümmern. Plugins mit externer Datenbank brauchen einen eigenen Dump: Eine Kopie des Serverordners enthält diese Datenbank nicht.
2. Warum eine einfache Kopie kaputtgehen kann. Der Server schreibt Gelände in Region-Dateien, und eine Kopie mitten im Schreiben kann halb alte, halb neue Daten enthalten [18]. Dafür gibt es die Speicherbefehle. save-off hindert den Server daran, in die Level-Dateien zu schreiben, damit du sie kopieren kannst, stellt Änderungen derweil in eine Warteschlange und wird beim Neustart zurückgesetzt. Spieler-, Fortschritts- und Statistikdateien deckt es nicht ab [1]. save-all flush schreibt alle Spieler und Chunks sofort auf den Datenträger und friert den Server kurz ein. Das einfache save-all markiert Chunks nur als speicherbedürftig [1]. save-on schaltet das Schreiben wieder an [1]. Alle drei brauchen Berechtigungsstufe 4 und laufen nur auf einem dedizierten Server [1]. Bei der Reihenfolge sind sich die Quellen uneins. syntaxmine.com nennt save-off, dann save-all flush [18], nicompter.de führt den Flush zuerst aus [19]. Wir nehmen save-off zuerst: Danach erreicht nichts Neues die Dateien, der folgende Flush schreibt also den endgültigen Stand. Das ist unsere Überlegung, keine belegte Aussage. Weil Spieler-, Fortschritts- und Statistikdateien außerhalb von save-off liegen [1], kann sich eine Datei während des Kopierens trotzdem ändern, und das spielt in Schritt 6 eine Rolle. Führe die Befehle einmal von Hand aus und sieh in die Konsole, bevor du dem Skript traust: Wir haben keine Quelle gefunden, die sagt, wie schnell nach save-all flush die RCON-Antwort zurückkommt, die Reihenfolge des Skripts (erst Flush, dann kopieren) ist also unsere Annahme.
3. Online oder offline. Beendest du den Server mit /stop, speichert er die Welt, und du kopierst das Verzeichnis einfach [2]. Das ist der einfachste und sicherste Weg, und für einen Server, der nachts schlafen darf, reicht er. Für einen Server, der rund um die Uhr läuft, nimm die Online-Folge. Der Flush friert den Server kurz ein [1], plane ihn also in eine ruhige Stunde.
4. RCON, ohne das Passwort zu verraten. RCON ist die Fernkonsole. Du schaltest sie mit enable-rcon=true, rcon.port und rcon.password in der server.properties ein, der Standardport ist 25575 [3][4]. Das Wiki warnt, dass RCON nicht verschlüsselt ist, das Passwort in unsicheren Netzen abgefangen werden kann und man sich idealerweise nur von localhost verbindet [3]. Gib den Port nie ins Internet frei. broadcast-rcon-to-ops (Standard true) schickt die Befehlsausgabe an online befindliche Operatoren, jedes Backup würde also in deren Chat auftauchen, solange du es nicht auf false setzt [3][4]. Der Kommandozeilen-Client mcrcon nimmt Host, Port und Passwort als Optionen und liest außerdem MCRCON_HOST, MCRCON_PORT und MCRCON_PASS aus der Umgebung. Kommandozeilenoptionen überstimmen die Umgebung, und Befehle mit Leerzeichen brauchen Anführungszeichen [9]. Nimm die Umgebung. Ein Passwort mit -p wird Teil der Kommandozeile des Prozesses, und die Linux-Dokumentation sagt, dass diese Zeile für alle lesbar ist, solange das System /proc nicht mit hidepid einbindet [10]. Leg das Passwort in eine Umgebungsdatei mit Modus 600, die systemd über EnvironmentFile= liest [11]. Derselbe Wert steht in der server.properties, das Backup-Archiv enthält das RCON-Passwort also ebenfalls. Schütze das Archiv wie einen Schlüssel: lokal mit restriktiven Rechten (umask 077 im Skript) und außer Haus auf einem verschlüsselten Ziel.
5. save-on unvermeidbar machen. Stirbt das Skript zwischen save-off und save-on, läuft der Server weiter, ohne die Welt zu schreiben. Das Wiki sagt, die Einstellung werde beim Neustart zurückgesetzt [1], ein Absturz macht sie also nicht dauerhaft, aber ein laufender Server könnte stundenlang Änderungen aufstauen. Bash kann beim Beenden der Shell einen Befehl ausführen: Ein trap auf EXIT führt den Befehl aus, bevor die Shell endet, auch nach einem Fehler [13]. Ein nicht abfangbares Signal wie SIGKILL entkommt trotzdem, ebenso ein Stromausfall. nicompter.de nutzt dieselbe Idee [19]. Unser Skript merkt sich außerdem, ob es das Speichern abgeschaltet hat, und schickt so kein überflüssiges save-on.
6. Archivieren, prüfen, außer Haus kopieren. tar beendet sich mit 0 bei Erfolg, mit 2 bei einem schweren Fehler und mit 1, wenn sich Dateien änderten, während sie archiviert wurden [14]. Exit-Code 1 ist hier deshalb plausibel, wegen der Dateien, die save-off nicht abdeckt. Wir behandeln 1 als Warnung, die der Restore-Test bestätigen muss, und 2 als Fehler. Starte tar unter nice -n 19, damit das Backup dem Spiel den Vortritt lässt [15]. ionice -c 3 lassen wir bewusst weg: Die Idle-Klasse bekommt nur Plattenzeit, wenn sonst niemand sie will [16], und solange das Speichern aus ist, staut der Server Änderungen im Speicher auf, ein gedehntes Backup hat also einen Preis. Liste das Archiv danach mit tar -tzf auf, um zu sehen, dass es lesbar ist, schreib eine SHA-256-Prüfsumme daneben und kopiere beides von der Maschine weg. Die Anleitung von syntaxmine.com sagt es klar: Eine Kopie auf demselben Datenträger wie die Welt ist eine zweite Kopie desselben Risikos [18]. rsync schiebt über eine Remote-Shell nach [USER@]HOST:DEST [17].
7. Zeitplan. Ein systemd-Timer startet standardmäßig einen Dienst gleichen Namens. OnCalendar= legt die Zeit fest, und Persistent=true holt einen verpassten Lauf nach, wenn die Maschine aus war [12]. Für einen Dienst, der ein Skript ausführt und endet, passt Type=oneshot [20]. Prüfe einmal pro Woche, ob das neueste Archiv aktuell ist, denn ein Backup, das still scheitert, sieht aus wie eines, das funktioniert.
8. Restore in drei Größen. Ein vollständiger Restore: Server stoppen, die kaputte Welt zur Seite schieben statt löschen, weil sie neuere Spielerdaten enthalten kann, das Backup so entpacken, dass der Ordner dort liegt, wo der alte lag, und starten. Sag den Rollback-Zeitraum ehrlich an [18]. Ein einzelner Spieler: Server stoppen oder sicherstellen, dass dieser Spieler offline ist [2], und nur die Datei dieses Spielers aus dem Backup kopieren. Sie heißt nach der UUID des Spielers: players/data/<uuid>.dat seit 26.1, vorher playerdata/<uuid>.dat [5][6][18]. Die UUID findest du in der usercache.json [18]. Statistiken und Fortschritte sind eigene Dateien daneben [5]. Ein Gebiet: Region-Dateien heißen r.X.Z.mca und enthalten 32 mal 32 Chunks, das sind 512 mal 512 Blöcke. Chunk- oder Blockkoordinaten ergeben die Region, indem du durch 32 bzw. 512 teilst und abrundest [7]. Seit Entitäts- und Points-of-Interest-Daten aus den Region-Dateien ausgelagert sind, gibt es eine Region in den Ordnern region, entities und poi einer Dimension, und du stellst alle drei zum selben X.Z wieder her [7]. Alles in der Region wird zurückgesetzt, Kisten eingeschlossen [18]. Unserer Einschätzung nach kann eine Struktur, die über die Regionsgrenze reicht, abgeschnitten werden, sieh dir die Grenze danach also an.
9. Restore-Test als Pflicht. Ein Restore, den du nicht probiert hast, ist eine Hoffnung. Entpacke das neueste Archiv in ein eigenes Verzeichnis, ändere in der server.properties dieser Kopie server-port und schalte RCON ab (sonst will sie dieselben Ports belegen), starte sie, tritt bei und prüfe, was dir fehlen würde: deine Basis, eine Kiste, dein Inventar, die Plugin-Daten. Schreib das Datum und die Dauer auf. Ein Backup einer älteren Minecraft-Version, das auf einem neueren Server liegt, wird vom neueren Server hochgezogen und kann nicht zurück [18]. Mojangs Patchnotes zu 26.1 Snapshot 6 sagen, dass Welten auf den neuen Ordneraufbau umgestellt werden und sich danach in keiner älteren Version mehr laden lassen [6]; teste ein älteres Backup also zuerst an einer Kopie. Dies ist der eine Schritt, den du nicht überspringen darfst.

Ein Beispiel zum Nachbauen (Befehle, kein Test)

So könnte ein Aufbau aussehen. Pfade, Host und Dateinamen sind Beispiele, und wir haben das für diesen Artikel nicht gegen einen echten Minecraft-Server ausgeführt. Wir haben nur den Ablauf in einer Sandbox mit einem Ersatz für mcrcon geprüft: Simulierten wir einen Fehler bei save-off, beim Flush und bei tar, wurde save-on jedes Mal trotzdem gesendet. Angenommen, der Server liegt in /srv/minecraft, läuft als Benutzer minecraft, hat enable-rcon=true auf 127.0.0.1:25575, und mcrcon ist installiert.

Zuerst die Umgebungsdatei mit den Geheimnissen, nur für den Besitzer lesbar:

sudo touch /etc/mc-backup.env
sudo chmod 600 /etc/mc-backup.env
sudoedit /etc/mc-backup.env

Sie enthält zwei Zeilen. Die erste ist der Wert von rcon.password, die zweite das Ziel der Kopie außer Haus, in der Form [USER@]HOST:DEST:

MCRCON_PASS=der-wert-von-rcon.password
OFFSITE=backup@backup-host.example:/srv/mc-backups/

Dann das Skript in /usr/local/sbin/mc-backup.sh, ausführbar, im Besitz von root und für den Serverbenutzer nicht beschreibbar:

#!/usr/bin/env bash
# Braucht MCRCON_PASS und OFFSITE aus der Umgebungsdatei. Das Passwort gehört nie hierher.
set -euo pipefail
umask 077

SERVER_PARENT=/srv
SERVER_NAME=minecraft
DEST=/srv/backups/minecraft
: "${MCRCON_PASS:?MCRCON_PASS ist nicht gesetzt}"
: "${OFFSITE:?OFFSITE ist nicht gesetzt}"
export MCRCON_HOST=127.0.0.1 MCRCON_PORT=25575 MCRCON_PASS

NAME="mc-$(date +%F_%H-%M).tar.gz"
ARCHIVE="$DEST/$NAME"
saving_off=0

cleanup() {
  if [ "$saving_off" = 1 ]; then
    mcrcon save-on || echo "WARNUNG: save-on von Hand ausführen" >&2
  fi
}
trap cleanup EXIT

mkdir -p "$DEST"
saving_off=1
mcrcon save-off
mcrcon "save-all flush"

status=0
nice -n 19 tar -C "$SERVER_PARENT" -czf "$ARCHIVE" \
  --exclude="$SERVER_NAME/logs" --exclude="$SERVER_NAME/crash-reports" \
  "$SERVER_NAME" || status=$?

mcrcon save-on
saving_off=0

if [ "$status" -gt 1 ]; then
  echo "tar ist mit Exit-Code $status fehlgeschlagen" >&2
  exit "$status"
fi
if [ "$status" -eq 1 ]; then
  echo "tar meldet geänderte Dateien; per Restore-Test bestätigen" >&2
fi

tar -tzf "$ARCHIVE" > /dev/null
( cd "$DEST" && sha256sum "$NAME" > "$NAME.sha256" )
rsync -a -- "$ARCHIVE" "$ARCHIVE.sha256" "$OFFSITE"

# Beispielwert: zwei Wochen lokal behalten. Wähle ihn danach, wie lange ein Schaden unbemerkt bleiben könnte.
find "$DEST" -name 'mc-*.tar.gz*' -mtime +14 -delete

Der Dienst und der Timer, als /etc/systemd/system/mc-backup.service und /etc/systemd/system/mc-backup.timer:

[Unit]
Description=Minecraft world backup

[Service]
Type=oneshot
User=minecraft
EnvironmentFile=/etc/mc-backup.env
ExecStart=/usr/local/sbin/mc-backup.sh

[Unit]
Description=Nightly Minecraft backup

[Timer]
OnCalendar=*-*-* 04:15:00
Persistent=true

[Install]
WantedBy=timers.target

Aktiviere ihn, führe ihn einmal von Hand aus und lies das Ergebnis:

sudo systemctl daemon-reload
sudo systemctl enable --now mc-backup.timer
sudo systemctl start mc-backup.service
journalctl -u mc-backup.service

Der Restore-Test, mit einem Beispiel-Archivnamen:

mkdir -p /tmp/mc-restore-test
tar -xzf /srv/backups/minecraft/mc-2026-10-25_04-15.tar.gz -C /tmp/mc-restore-test
cd /tmp/mc-restore-test/minecraft
sed -i 's/^server-port=.*/server-port=25566/; s/^enable-rcon=.*/enable-rcon=false/' server.properties

Starte den Server aus diesem Verzeichnis mit deinem üblichen Befehl, zum Beispiel java -jar server.jar --nogui für die Jar, die du betreibst, und tritt über Port 25566 bei. Sprechen deine Plugins mit einer gemeinsamen Datenbank oder einem externen Dienst, schalte das in der Testkopie ebenfalls ab.

Für ein einzelnes Gebiet: Block (1500, -600) ist Chunk (93, -38) und damit Region (2, -2), nach unserer Rechnung mit der Formel aus dem Wiki [7]. Du würdest r.2.-2.mca aus region, entities und poi der richtigen Dimension zurückspielen, bei gestopptem Server.

Willst du Versionen, Deduplizierung und Verschlüsselung statt einfacher Archive, ersetze den tar-Schritt durch einen restic- oder Borg-Lauf. Das behandelt der Artikel zum Homelab-Backup mit restic oder Borg, die Seite außer Haus der Artikel zum Offsite-Backup fürs Homelab. Die 3-2-1-Regel rahmt das Ganze.

Prüfliste

• Sichere das ganze Serververzeichnis, nicht nur den Weltordner, und lass Logs und Crash-Reports weg.
• Führe save-off, dann save-all flush, Kopie und save-on aus, oder stoppe den Server und kopiere.
• Schick die Befehle über RCON an localhost und gib den RCON-Port nie ins Internet frei.
• Leg das RCON-Passwort in eine Datei mit Modus 600 und lies es über die Umgebung, nie im Skript oder mit -p.
• Setze einen trap auf EXIT, damit save-on nach einer gescheiterten Kopie läuft, und teste ihn, indem du die Kopie einmal absichtlich scheitern lässt.
• Prüfe den tar-Exit-Code: 2 ist ein Fehler, 1 eine Warnung, die einen Restore-Test braucht.
• Liste das Archiv mit tar -tzf auf, schreib eine Prüfsumme und kopiere beides auf einen zweiten Rechner.
• Schütze das Archiv wie einen Schlüssel, denn es enthält die server.properties mit dem RCON-Passwort.
• Entpacke das neueste Archiv in ein Testverzeichnis, ändere server-port, schalte RCON ab und tritt bei.
• Schreib Datum, Archivnamen und Dauer des Restores auf und wiederhole den Test nach jeder großen Änderung und regelmäßig.
• Prüfe wöchentlich, ob das neueste Archiv aktuell ist und die Kopie außer Haus angekommen ist.