Automatische Minecraft-Backups mit itzg/mc-backup einrichten

So arbeitet der Backup-Container

itzg/mc-backup läuft als Begleitcontainer zu itzg/minecraft-server. 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

Das Beispiel verwendet:

• 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

Lege eine Aufbewahrungsfrist fest, damit alte Archive das Backup-Laufwerk nicht füllen.

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

Nächste Schritte

• Beispiele für Cloud-Speicher und Discord-Meldungen findest du im Backup Guide.
• 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.