Automatische Minecraft-Backups mit itzg/mc-backup einrichten

Warum sich genau dieses Muster lohnt

Backups sind erst dann wertvoll, wenn sie:

• automatisch laufen
• konsistent sind
• getestet wurden

itzg/mc-backup ist für Docker-basierte Minecraft-Server eine sehr gute Standardlösung, weil es als Begleitcontainer zu itzg/minecraft-server gedacht ist. Es koordiniert Backups über RCON, damit der Server vor dem Kopieren Speicherstände flushen und Schreibzugriffe kurz anhalten kann.

Empfohlener Aufbau

Nutze einen Container für den Minecraft-Server und einen zweiten Begleitcontainer für die Backups.

Das Daten-Volume des Servers wird:

• im Minecraft-Container read/write eingebunden
• im Backup-Container read-only eingebunden

Das eigentliche Backup-Ziel sollte getrennt vom Live-Weltverzeichnis liegen.

Compose-Beispiel

services:
  mc:
    image: itzg/minecraft-server:latest
    restart: unless-stopped
    ports:
      - "25565:25565"
    environment:
      EULA: "TRUE"
      TYPE: PAPER
      RCON_PASSWORD_FILE: /run/secrets/rcon_password
    volumes:
      - ./data:/data
    secrets:
      - rcon_password

  backup:
    image: itzg/mc-backup:latest
    restart: unless-stopped
    environment:
      RCON_HOST: mc
      RCON_PASSWORD_FILE: /run/secrets/rcon_password
      BACKUP_INTERVAL: 12h
      PRUNE_BACKUPS_DAYS: 7
    volumes:
      - ./data:/data:ro
      - ./backups:/backups
    secrets:
      - rcon_password

secrets:
  rcon_password:
    file: ./rcon_password

Erstelle vor dem Start neben der compose.yml die Datei rcon_password und lege darin ein langes zufälliges Passwort ab. Committe diese Datei nicht. Beide Container müssen dasselbe Secret lesen: Aktuelle Builds von itzg/minecraft-server erzeugen standardmäßig ein zufälliges RCON-Passwort. Unabhängige Standardwerte führen deshalb dazu, dass die Backup-Koordination bei der Anmeldung scheitert.

Warum RCON hier wichtig ist

Der Backup-Container verlässt sich auf die Koordination über RCON. Lass RCON im Hauptcontainer für die Backup-Koordination aktiviert.

Wenn dein Verwaltungszugang noch nicht funktioniert, bringe zuerst RCON in Ordnung, bevor du dich auf automatische Backups im Ernstfall verlässt.

Sinnvolle Standardwerte

Diese Werte sind in der Praxis ein guter Anfang:

• BACKUP_INTERVAL: 12h
• PRUNE_BACKUPS_DAYS: 7
• lokales Backup-Verzeichnis auf dem Host

Damit bekommst du:

• mehrere Wiederherstellungspunkte pro Woche
• kontrollierbares Speicherwachstum
• einen schnellen Sichtcheck, ob Backups tatsächlich geschrieben werden

Für feinere Planung unterstützt das Image auch Cron-Schedules und weitere Backup-Methoden.

Die Einrichtung sofort prüfen

Starte den Stack:

docker compose up -d

Dann prüfe die Logs des Backup-Containers:

docker compose logs -f backup

Du willst sehen:

• dass ein Backup-Job tatsächlich läuft
• dass unter ./backups Archive auftauchen
• dass keine RCON-Koordinationsfehler erscheinen

Für ein sofortiges Test-Backup:

docker compose exec backup backup now

Nutze dabei den Compose-Service-Namen backup; der von Compose erzeugte Container heißt nicht zwingend genauso. Bestätige danach ein neues Archiv und einen erfolgreichen Abschluss in den Logs, bevor du den Job als funktionierend betrachtest.

Retention und Speicher

Behalte nicht ungewollt alles für immer. Die Retention sollte zum Wert der Welt und zu deinem Speicherbudget passen.

Ein einfacher Start:

• alle 12 Stunden ein Backup
• lokal 7 Tage behalten
• später eine zweite externe Kopie ergänzen

Verlasse dich dabei nicht allein auf Infrastruktur-Snapshots. Auf Hetzner sind angehängte Volumes nicht Teil von Cloud Backups oder Snapshots, deshalb solltest du Infrastruktur-Snapshots nur als zweite Schutzschicht behandeln.

Häufige Fehler

FAQ

Sollte /data im Backup-Container nur lesend eingebunden sein?

Ja. Das ist die sichere Standardeinstellung, weil der Begleitcontainer keine Schreibrechte auf die Live-Weltdaten braucht.

Reicht ein lokales Backup-Verzeichnis?

Es ist besser als gar nichts, aber für wichtige Server nicht genug. Lokale Backups schützen dich nicht vor vollständigem Host-Verlust.

Nächste Schritte

• Beispiele für Cloud-Speicher und Discord-Meldungen findest du im Backup Guide.
• Probe den vollständigen Recovery-Pfad mit dem Docker-Restore-Runbook.
• Wenn du bei Hetzner hostest, lies, warum Infrastruktur-Snapshots angehängte Volumes nicht enthalten.
• Wenn sichere Stop-Befehle oder die Backup-Koordination noch nicht funktionieren, prüfe zuerst deinen RCON-Pfad, bevor du dem Backup-Job im produktiven Betrieb vertraust.