Minecraft Server Backups: Daten bei Angriffen schützen

Dein Minecraft-Server laeuft seit Monaten. Spieler bauen Staedte, leveln ihre Charaktere, die Wirtschaft brummt. Dann kommt DDoS. Der Server crasht mitten im Autosave. Java wird vom OOM-Killer getoetet. Region-Dateien sind halb geschrieben. Level.dat ist auf null gesetzt. Du starrst auf 0-Byte-Dateien in playerdata/ und erkennst: Es gibt keine Backups.

Das passiert staendig. Admins verbringen Monate mit dem Serveraufbau, vergessen aber die Backups komplett. Oder machen sie einmal pro Woche manuell. Oder speichern sie auf derselben Festplatte wie den Server. All das ist gleichbedeutend mit keinem Backup.

Dieser Artikel zeigt dir, wie du ein zuverlaessiges Backup-System fuer deinen Minecraft-Server einrichtest. Ohne Theorie-Ballast, dafuer mit konkreten Skripten und Configs zum Kopieren und sofort Anwenden.

Warum Backups fuer MC-Server entscheidend sind

Minecraft speichert alles in Dateien auf der Festplatte. Welten, Inventare, Erfolge, Statistiken, Plugin-Configs, Berechtigungen. Einfache Dateien im Dateisystem, und sie sind verwundbar, wenn etwas schiefgeht.

Hauptrisiken:

Crash waehrend des Schreibens. Minecraft speichert die Welt periodisch auf die Festplatte. Wenn der Server in diesem Moment abstuerzt (DDoS, OOM, Kernel Panic), koennen Dateien in einem ungueltigen Zustand landen. Eine halb geschriebene Region-Datei kann einen gesamten 32x32 Chunk-Bereich ausloeschen. Das sind Hunderte Stunden Spielerarbeit, die in einem Moment verschwinden.

level.dat-Korruption. Diese Datei enthaelt kritische Metadaten: Weltzeit, Spawn-Position, Generator, Spielregeln. Ohne sie startet der Server nicht. Minecraft bewahrt zwar eine level.dat_old auf, aber wenn beide Dateien im selben Crash-Zyklus beschaedigt werden, hast du ein ernstes Problem.

Spielerdatenverlust. Dateien in world/playerdata/ speichern Inventar, Position, Gesundheit, XP jedes Spielers. Eine 0-Byte-Datei bedeutet kompletten Fortschrittsverlust fuer diesen Spieler. Stell dir vor, du musst einem Veteran-Spieler erklaeren, dass seine sechs Monate Fortschritt weg sind, weil ein DDoS-Angriff waehrend des Autosave kam.

Admin-Fehler. Versehentliches rm -rf, missratenes Plugin-Update, Tests in der Produktion. Menschliche Fehler vernichten Daten genauso oft wie Angriffe. Ein falscher Befehl im Serververzeichnis und Wochen an Konfigurationsarbeit sind weg.

Angriffe auf den Server. DDoS-Angriffe verursachen extreme TPS-Einbrueche, CPU- und Speicherueberlastung. Wenn der Server nicht mehr mitkommt, kann das OS den Java-Prozess toeten. Und wenn ein Angreifer durch eine Plugin-Schwachstelle Zugang erlangt hat, koennte er absichtlich Daten loeschen oder beschaedigen.

Was du sichern solltest

Nicht alles auf dem Server ist gleich wichtig. Priorisiere entsprechend.

Kritisch

• world/ (plus alle zusaetzlichen Welten: world_nether, world_the_end, Plugin-Welten)
• world/playerdata/ - Spieler-Inventare und Fortschritt
• world/advancements/ - Spieler-Erfolge
• world/stats/ - Spieler-Statistiken
• plugins/ - Configs und Daten aller Plugins
• server.properties, spigot.yml, paper-global.yml, paper-world-defaults.yml
• ops.json, whitelist.json, banned-players.json, banned-ips.json
• MySQL/MariaDB-Datenbanken (wenn Plugins SQL-Speicher nutzen)

Wichtig, aber ersetzbar

• Server- und Plugin-JAR-Dateien (koennen erneut heruntergeladen werden)
• Logs (nuetzlich fuer Analyse, aber nicht kritisch fuer den Betrieb)
• Cache und temporaere Dateien (werden automatisch neu erstellt)

Kann uebersprungen werden

• .cache/, libraries/ (werden beim Start heruntergeladen)
• Alte crash-reports, die du bereits ausgewertet hast
• Komprimierte Log-Archive, die Backup-Speicher verschwenden

Die 3-2-1 Regel

Der Goldstandard der Backup-Strategie. Eine einfache Regel, die funktioniert:

• 3 Kopien der Daten (Original + 2 Backups)
• 2 verschiedene Medientypen (lokale Festplatte + Cloud, oder SSD + HDD)
• 1 Kopie an einem anderen physischen Ort (Offsite)

Fuer einen Minecraft-Server bedeutet das:

1. Originaldaten auf dem Server
2. Lokales Backup auf einer separaten Festplatte oder Partition
3. Remote-Backup im Cloud-Speicher (S3, Backblaze B2, Google Drive)

Warum genau dieses Setup? Lokale Backups geben dir Geschwindigkeit. Wenn die Welt beschaedigt wird, stellst du in Minuten wieder her. Remote-Backups schuetzen vor katastrophalen Szenarien: Der Hoster verliert deine Daten, die Festplatte stirbt physisch, der Server wird kompromittiert und der Angreifer loescht alles inklusive lokaler Backups.

Keines allein reicht aus. Ein reines lokales Backup stirbt, wenn der Server stirbt. Ein reines Cloud-Backup braucht Stunden zum Herunterladen, wenn du dringend wiederherstellen musst und Spieler im Discord warten.

Live-Backups: save-off / save-on

Die groesste Herausforderung bei Minecraft-Backups ist Konsistenz. Du kannst nicht einfach Dateien von einem laufenden Server kopieren. Wenn der Server Daten schreibt, waehrend du kopierst, kann dein Backup inkonsistente Daten enthalten: eine halb geschriebene Region-Datei, eine offene Playerdata-Datei, eine level.dat mitten im Update.

Loesung: die save-off und save-on Befehle.

#!/bin/bash
# minecraft-backup.sh - Live-Backup ohne Server-Stopp
# Erfordert: screen oder tmux Sitzung namens "minecraft"

SERVER_DIR="/opt/minecraft"
BACKUP_DIR="/backup/minecraft"
SCREEN_NAME="minecraft"
DATE=$(date +%Y-%m-%d_%H-%M-%S)
BACKUP_FILE="$BACKUP_DIR/mc-backup-$DATE.tar.gz"

mkdir -p "$BACKUP_DIR"

# Sicherstellen, dass save-on auch bei Fehler ausgefuehrt wird
trap 'screen -S "$SCREEN_NAME" -p 0 -X stuff "save-on$(printf "\r")"' EXIT

# Spieler benachrichtigen
screen -S "$SCREEN_NAME" -p 0 -X stuff "say Backup startet in 10 Sekunden...$(printf '\r')"
sleep 10

# Autosave deaktivieren
screen -S "$SCREEN_NAME" -p 0 -X stuff "save-off$(printf '\r')"
sleep 1

# Aktuellen Stand erzwingen
screen -S "$SCREEN_NAME" -p 0 -X stuff "save-all$(printf '\r')"
sleep 5

# Archiv erstellen
tar -czf "$BACKUP_FILE" \
    -C "$SERVER_DIR" \
    world/ world_nether/ world_the_end/ \
    plugins/ server.properties spigot.yml \
    paper-global.yml ops.json whitelist.json \
    banned-players.json banned-ips.json 2>/dev/null

# Autosave wieder aktivieren
screen -S "$SCREEN_NAME" -p 0 -X stuff "save-on$(printf '\r')"

# Spieler benachrichtigen
screen -S "$SCREEN_NAME" -p 0 -X stuff "say Backup abgeschlossen!$(printf '\r')"

echo "Backup: $BACKUP_FILE ($(du -sh "$BACKUP_FILE" | cut -f1))"

Der Algorithmus ist einfach: Autosave deaktivieren, finales save-all erzwingen, Dateien kopieren, Autosave wieder aktivieren. Zwischen save-off und save-on aendern sich die Weltdateien nicht, und du erhaeltst einen konsistenten Snapshot.

Der trap-Befehl ist entscheidend. Wenn das Skript nach save-off abstuerzt, bleibt Autosave deaktiviert. Ohne trap geht bei einem spaeteren Servercrash alles verloren, das seit dem letzten save-all passiert ist, weil Autosave nie wieder eingeschaltet wurde. Mit trap wird save-on in jedem Fall ausgefuehrt, egal was mit dem Skript passiert.

Werkzeuge: rsync, borgbackup, rclone

rsync

Das Arbeitspferd der inkrementellen Dateikopie. rsync uebertraegt nur Dateien, die sich seit dem letzten Lauf geaendert haben. Fuer taegliche Backups grosser Welten spart das enorm Zeit und Bandbreite.

#!/bin/bash
# rsync-backup.sh - inkrementelles Backup via rsync

SERVER_DIR="/opt/minecraft"
BACKUP_DIR="/backup/minecraft/latest"
LOG="/var/log/mc-backup.log"

rsync -a --delete \
    --exclude='.cache/' \
    --exclude='libraries/' \
    --exclude='logs/*.gz' \
    --exclude='crash-reports/' \
    "$SERVER_DIR/" "$BACKUP_DIR/"

echo "$(date '+%Y-%m-%d %H:%M:%S') rsync backup completed" >> "$LOG"

Das --delete Flag entfernt Dateien aus dem Backup, die auf dem Server nicht mehr existieren. Das haelt das Backup aktuell, aber Vorsicht: Wenn Dateien versehentlich auf dem Server geloescht werden, entfernt --delete sie auch aus dem Backup. Kombiniere rsync deshalb mit Rotation (mehrere Versionen aufbewahren).

borgbackup

borgbackup (borg) erstellt inkrementelle Backups mit Deduplizierung. Eine 10 GB Welt, von der sich nur 200 MB geaendert haben? Borg speichert nur diese 200 MB. Trotzdem sieht jedes Backup bei der Wiederherstellung wie eine vollstaendige Kopie aus. Du kannst jedes einzelne Backup unabhaengig wiederherstellen, ohne die gesamte Kette zu brauchen.

# Initialisierung (einmalig)
borg init --encryption=repokey /backup/borg-mc

# Backup erstellen
borg create \
    --stats \
    --compression zstd,3 \
    --exclude '*.log.gz' \
    --exclude '.cache' \
    --exclude 'libraries' \
    /backup/borg-mc::mc-{now:%Y-%m-%d_%H-%M} \
    /opt/minecraft/world \
    /opt/minecraft/plugins \
    /opt/minecraft/server.properties \
    /opt/minecraft/ops.json \
    /opt/minecraft/whitelist.json

# Automatisches Aufraeumen
borg prune \
    --keep-hourly=6 \
    --keep-daily=7 \
    --keep-weekly=4 \
    --keep-monthly=6 \
    /backup/borg-mc

Hauptvorteile von borg fuer Minecraft-Server:

• Deduplizierung: Identische Chunks werden nicht zwischen Backups dupliziert
• zstd-Kompression: Schnell und effektiv fuer binaere Weltdaten
• Verschluesselung: Backups mit AES-256 verschluesselt, Schluessel lokal gespeichert
• Punktgenaue Wiederherstellung: Einzelne Datei aus jedem Backup in der Historie extrahieren

rclone fuer Cloud-Speicher

rclone funktioniert mit Dutzenden Cloud-Anbietern. Einmal konfigurieren, dauerhaft fuer Offsite-Backups nutzen.

# Konfiguration (interaktiv, einmalig)
rclone config

# Beispiel-Config fuer Backblaze B2 (~/.config/rclone/rclone.conf)
# [b2-backup]
# type = b2
# account = DEIN_KEY_ID
# key = DEIN_APP_KEY

# Backup in die Cloud synchronisieren
rclone sync /backup/minecraft b2-backup:mc-server-backup \
    --transfers=4 \
    --checkers=8 \
    --fast-list \
    --log-file=/var/log/rclone-backup.log \
    --log-level=NOTICE

# Fuer Google Drive:
# rclone sync /backup/minecraft gdrive:mc-backup --drive-chunk-size=64M

Backblaze B2 kostet $0.005/GB pro Monat. Fuer einen durchschnittlichen Minecraft-Server mit einer 5-10 GB Welt sind das etwa $0.05 im Monat. Minimale Kosten fuer Datensicherheit.

Automatisierung mit cron

Ein Backup, das manuell gestartet werden muss, wird nicht gestartet. In der ersten stressigen Woche wird es vergessen. Automatisiere alles.

# crontab -e

# Lokales Backup alle 4 Stunden
0 */4 * * * /opt/scripts/minecraft-backup.sh >> /var/log/mc-backup.log 2>&1

# Cloud-Upload taeglich um 4 Uhr
0 4 * * * /opt/scripts/cloud-upload.sh >> /var/log/mc-cloud.log 2>&1

# Volles borg-Backup jeden Sonntag um 5 Uhr
0 5 * * 0 /opt/scripts/borg-backup.sh >> /var/log/mc-borg.log 2>&1

# Alte Backups woechentlich aufraeumen
0 6 * * 1 /opt/scripts/backup-cleanup.sh >> /var/log/mc-cleanup.log 2>&1

Im vollstaendigen Pipeline-Skript sollte save-on so frueh wie moeglich wieder aktiviert werden. save-off ausfuehren, rsync starten, sofort save-on wieder einschalten. Dann borg und rclone aus der lokalen Kopie ausfuehren. Der Server pausiert Schreibvorgaenge nur fuer die rsync-Dauer, typischerweise unter einer Minute bei inkrementellen Kopien.

Hier ist die vollstaendige Pipeline:

#!/bin/bash
# full-backup-pipeline.sh
set -euo pipefail

SERVER_DIR="/opt/minecraft"
BACKUP_DIR="/backup/minecraft"
BORG_REPO="/backup/borg-mc"
SCREEN_NAME="minecraft"
RCLONE_REMOTE="b2-backup:mc-server-backup"
DATE=$(date +%Y-%m-%d_%H-%M-%S)
LOG="/var/log/mc-backup-pipeline.log"

log() { echo "$(date '+%Y-%m-%d %H:%M:%S') $1" >> "$LOG"; }

trap 'screen -S "$SCREEN_NAME" -p 0 -X stuff "save-on$(printf "\r")" 2>/dev/null' EXIT

log "=== Pipeline gestartet ==="

# 1. save-off + save-all
screen -S "$SCREEN_NAME" -p 0 -X stuff "save-off$(printf '\r')"
sleep 1
screen -S "$SCREEN_NAME" -p 0 -X stuff "save-all$(printf '\r')"
sleep 5

# 2. rsync in lokales Verzeichnis
rsync -a --delete --exclude='.cache/' --exclude='libraries/' \
    "$SERVER_DIR/" "$BACKUP_DIR/latest/"

# 3. Autosave sofort wieder aktivieren
screen -S "$SCREEN_NAME" -p 0 -X stuff "save-on$(printf '\r')"
log "save-on wiederhergestellt"

# 4. borg-Backup aus lokaler Kopie
borg create --stats --compression zstd,3 \
    "$BORG_REPO"::mc-"$DATE" "$BACKUP_DIR/latest/" 2>> "$LOG"

# 5. borg prune
borg prune --keep-hourly=6 --keep-daily=7 \
    --keep-weekly=4 --keep-monthly=3 "$BORG_REPO" 2>> "$LOG"

# 6. rclone in die Cloud
rclone sync "$BACKUP_DIR/latest/" "$RCLONE_REMOTE" \
    --transfers=4 --fast-list 2>> "$LOG"

log "=== Pipeline abgeschlossen ==="

Beachte: save-on wird direkt nach rsync wiederhergestellt, nicht am Ende. Borg und rclone arbeiten mit der lokalen Kopie, der Server laeuft normal weiter.

Inkrementelle vs. vollstaendige Backups

Vollstaendiges Backup kopiert jedes Mal alles. Einfach, zuverlaessig, aber platzhungrig. Eine 20 GB Welt bedeutet 20 GB pro Backup.

Inkrementelles Backup kopiert nur, was sich seit dem letzten Lauf geaendert hat. Schnell und speichereffizient, aber fuer die Wiederherstellung braucht man die gesamte Backup-Kette.

Die optimale Strategie fuer Minecraft:

• Woechentliches Voll-Backup als Basis (Sonntag)
• Inkrementelle Backups alle 4 Stunden unter der Woche

borgbackup loest dieses Problem elegant. Jedes Backup ist technisch inkrementell (speichert nur neue Datenbloecke), aber bei der Wiederherstellung verhaelt sich jedes wie ein vollstaendiges Backup. Das Beste aus beiden Welten.

Rotation und Aufbewahrung

Man kann Backups nicht ewig aufbewahren. Speicherplatz ist endlich. Lege eine Aufbewahrungsrichtlinie fest:

• Letzte 24 Stunden: Backup alle 4 Stunden (6 Kopien)
• Letzte Woche: taegliches Backup (7 Kopien)
• Letzter Monat: woechentliches Backup (4 Kopien)
• Letzte 3 Monate: monatliches Backup (3 Kopien)

Das ergibt etwa 20 Wiederherstellungspunkte, die 3 Monate Geschichte abdecken. Aktuelle Ereignisse haben feinkoernige Abdeckung (du kannst zu jedem 4-Stunden-Fenster von heute zurueckgehen), waehrend aeltere Geschichte noch in niedrigerer Aufloesung verfuegbar ist.

Fuer tar-basierte Backups nutze ein Rotationsskript:

#!/bin/bash
# backup-rotation.sh
BACKUP_DIR="/backup/minecraft"

# Backups aelter als 7 Tage loeschen (ausser Sonntags-Backups)
find "$BACKUP_DIR" -name "mc-backup-*.tar.gz" -mtime +7 \
    -not -name "*_Sun_*" -delete

# Sonntags-Backups aelter als 30 Tage loeschen
find "$BACKUP_DIR" -name "*_Sun_*.tar.gz" -mtime +30 -delete

echo "Backup-Speicherverbrauch:"
du -sh "$BACKUP_DIR"

Fuer borg verwende den eingebauten prune-Befehl, der oben bereits gezeigt wurde. Er handhabt Rotation zuverlaessiger als manuelle find/delete-Skripte.

Datenbank-Backups fuer MySQL/MariaDB

Wenn deine Plugins SQL-Speicher verwenden (LuckPerms, ShopGUI+, CMI, Plan, Dynmap), erfassen Datei-Backups die Datenbank nicht. Du brauchst einen separaten Dump.

#!/bin/bash
# mysql-backup.sh
DB_NAME="minecraft"
DB_USER="mc_backup"
DB_PASS="sicheres_passwort_hier"
BACKUP_DIR="/backup/mysql"
DATE=$(date +%Y-%m-%d_%H-%M-%S)

mkdir -p "$BACKUP_DIR"

mysqldump \
    --user="$DB_USER" \
    --password="$DB_PASS" \
    --single-transaction \
    --routines \
    --triggers \
    "$DB_NAME" | gzip > "$BACKUP_DIR/mc-db-$DATE.sql.gz"

echo "Database backup: $BACKUP_DIR/mc-db-$DATE.sql.gz"

# Dumps aelter als 14 Tage loeschen
find "$BACKUP_DIR" -name "mc-db-*.sql.gz" -mtime +14 -delete

Das Flag --single-transaction ist entscheidend. Es erstellt einen konsistenten Snapshot ohne Tabellensperren. Ohne es koennte der Dump Daten aus verschiedenen Zeitpunkten enthalten (eine Tabelle wurde aktualisiert, waehrend eine andere noch gedumpt wurde). Verwende dieses Flag immer.

Fuege dieses Skript deiner Backup-Pipeline hinzu und starte es vor dem Datei-Backup, damit der SQL-Dump in deinem borg-Archiv enthalten ist.

Backups testen

Ein ungetestetes Backup ist kein Backup. Das ist kein Klischee, sondern der haeufigste Backup-Fehler ueberhaupt. Admins richten automatische Backups ein, vergessen sie, und sechs Monate spaeter stellen sie fest, dass das Skript vor drei Monaten kaputt ging. Oder die Backups existieren, koennen aber wegen Berechtigungen, fehlenden Dateien oder Korruption nicht wiederhergestellt werden.

Teste die Wiederherstellung regelmaessig. Mindestens monatlich.

#!/bin/bash
# test-restore.sh - Backup-Integritaet ueberpruefen
TEST_DIR="/tmp/mc-restore-test"
BORG_REPO="/backup/borg-mc"

rm -rf "$TEST_DIR" && mkdir -p "$TEST_DIR"

LATEST=$(borg list "$BORG_REPO" --last 1 --format '{archive}')
echo "Wiederherstellung: $LATEST"
borg extract "$BORG_REPO"::"$LATEST" --target "$TEST_DIR"

echo "=== Kritische Dateien pruefen ==="

# level.dat
if [ -f "$TEST_DIR/latest/world/level.dat" ]; then
    SIZE=$(stat -c%s "$TEST_DIR/latest/world/level.dat")
    if [ "$SIZE" -gt 100 ]; then
        echo "[OK] level.dat ($SIZE bytes)"
    else
        echo "[FAIL] level.dat zu klein ($SIZE bytes)"
    fi
else
    echo "[FAIL] level.dat fehlt!"
fi

# Region-Dateien
REGION_COUNT=$(find "$TEST_DIR/latest/world/region/" -name "*.mca" 2>/dev/null | wc -l)
EMPTY_REGIONS=$(find "$TEST_DIR/latest/world/region/" -name "*.mca" -empty 2>/dev/null | wc -l)
echo "[INFO] Region-Dateien: $REGION_COUNT gesamt, $EMPTY_REGIONS leer"

# Spielerdaten
PLAYER_COUNT=$(find "$TEST_DIR/latest/world/playerdata/" -name "*.dat" 2>/dev/null | wc -l)
echo "[INFO] Spielerdaten: $PLAYER_COUNT Dateien"

# server.properties
[ -f "$TEST_DIR/latest/server.properties" ] && echo "[OK] server.properties" || echo "[FAIL] server.properties"

rm -rf "$TEST_DIR"
echo "=== Wiederherstellungstest abgeschlossen ==="

Fuehre das woechentlich per cron aus und sende die Ergebnisse an deinen Discord-Webhook. Wenn der Test fehlschlaegt, erfaehrst du es, bevor du das Backup wirklich brauchst.

Schnelle Wiederherstellung nach einem Angriff

DDoS hat deine Weltdaten beschaedigt. Spieler warten. Jede Minute Ausfallzeit kostet dich Publikum. Hier ist der schnelle Weg zurueck zum Normalbetrieb:

# 1. Server stoppen (falls noch laeuft)
screen -S minecraft -p 0 -X stuff "stop$(printf '\r')"
sleep 10

# 2. Beschaedigte Daten verschieben (nicht loeschen!)
mv /opt/minecraft/world /opt/minecraft/world_corrupted_$(date +%Y%m%d)

# 3. Aus letztem Backup wiederherstellen
# Option A: aus rsync-Kopie (schnellste)
cp -a /backup/minecraft/latest/world /opt/minecraft/world

# Option B: aus borg
# borg extract /backup/borg-mc::ARCHIVE_NAME --target /opt/minecraft

# Option C: aus tar-Archiv
# tar -xzf /backup/minecraft/mc-backup-LATEST.tar.gz -C /opt/minecraft world/

# 4. Datenbank wiederherstellen (falls noetig)
# gunzip < /backup/mysql/mc-db-LATEST.sql.gz | mysql minecraft

# 5. Berechtigungen korrigieren
chown -R minecraft:minecraft /opt/minecraft/world

# 6. Server starten
screen -S minecraft -X stuff "/opt/minecraft/start.sh$(printf '\r')"

Aus einer rsync-Kopie dauert die Wiederherstellung Minuten. Aus borg mit Deduplizierung etwas laenger, aber immer noch schnell. Aus dem Cloud-Backup kann es erhebliche Download-Zeit erfordern, weshalb die lokale Kopie so wichtig ist.

Behalte die beschaedigten Daten. Loesche sie nicht sofort. Vielleicht willst du spaeter etwas daraus extrahieren, zum Beispiel Spielerdaten, die nach dem letzten Backup erstellt wurden.

Backup-Sicherheit

Backups enthalten alles: Datenbank-Passwoerter, RCON-Zugangsdaten, API-Tokens von Plugins, IP-Adressen der Spieler. Wenn jemand Zugang zu deinem Backup bekommt, hat er die volle Kontrolle ueber deinen Server und moeglicherweise sensible Spielerinformationen.

Verschluesselung. borgbackup verschluesselt mit AES-256 ab Werk, wenn du mit --encryption=repokey initialisierst. Fuer tar-Archive nutze gpg:

# Verschluesseln
tar -czf - /opt/minecraft/world /opt/minecraft/plugins | \
    gpg --symmetric --cipher-algo AES256 \
    --output /backup/mc-encrypted-$(date +%Y%m%d).tar.gz.gpg

# Entschluesseln
gpg --decrypt /backup/mc-encrypted-20260403.tar.gz.gpg | \
    tar -xzf - -C /opt/minecraft

Zugriffskontrolle. Beschraenke die Berechtigungen des Backup-Verzeichnisses. Erstelle einen dedizierten Backup-Benutzer mit Leserechten auf Serverdateien und Vollzugriff auf das Backup-Verzeichnis. Wenn der Server kompromittiert wird, kann der Angreifer mit minecraft-Benutzerrechten keine Backups loeschen, die einem anderen Benutzer gehoeren.

chmod 700 /backup/minecraft
chown root:root /backup/minecraft
chmod 600 ~/.config/rclone/rclone.conf

# Dedizierten Backup-Benutzer erstellen
useradd -r -s /bin/bash -d /backup mc-backup
setfacl -R -m u:mc-backup:rx /opt/minecraft
chown -R mc-backup:mc-backup /backup/minecraft

Plugin-basierte Backups

Wenn Bash-Skripte nicht dein Ding sind, koennen Plugins Backups innerhalb von Minecraft erledigen.

DriveBackupV2 sichert automatisch auf Google Drive, OneDrive oder FTP nach Zeitplan. Die Konfiguration ist einfaches YAML. eBackup handhabt lokale Backups mit SFTP-Unterstuetzung. Beide funktionieren gut fuer kleinere Server, wo der Admin sich mit Minecraft-Plugin-Konfiguration wohler fuehlt als mit Linux-Skripting.

Fuer ernsthafte Infrastruktur verwende System-Tools (borg + rclone + cron). Sie arbeiten auf OS-Ebene, haengen nicht vom Java-Prozess ab und geben dir die volle Kontrolle ueber jeden Aspekt des Backup-Prozesses. Wenn dein Server wegen eines DDoS-Angriffs crasht, kann ein Plugin-basiertes Backup nicht laufen. Ein Cron-Job auf dem Host-System schon.

Offsite-Speicher: Wohin die Backups senden

Backblaze B2: Guenstigste Option. $0.005/GB Speicher, $0.01/GB Download. Erste 10 GB kostenlos. Fuer die meisten Minecraft-Server liegt die Monatsrechnung unter $1.

Amazon S3 / S3-kompatibel: Teurer, aber weit unterstuetzt. Erwaege Wasabi fuer S3-kompatiblen Speicher zu niedrigeren Preisen.

Google Drive via rclone: 15 GB kostenlos. Genuegt fuer einen kleinen Server. Einfach mit rclone einzurichten.

Starte mit Backblaze B2. Minimale Kosten, hohe Zuverlaessigkeit, gute Geschwindigkeit.

DDoS und Backups

DDoS-Angriffe schaffen perfekte Bedingungen fuer Datenverlust. Server ueberlastet, TPS bei null, OOM-Killer jederzeit bereit. Wenn in genau diesem Moment Autosave laeuft, werden Daten beschaedigt.

Schuetze dich:

1. Nutze DDoS-Schutz. Dienste wie MineGuard filtern Angriffe, bevor der Traffic deinen Server erreicht. Keine Ueberlastung, keine Abstuerze, keine Beschaedigung. Praevention ist immer besser als Wiederherstellung.

2. Erhoehe die Backup-Frequenz bei Bedrohung. Alle 2 statt 4 Stunden halbiert deinen maximalen Datenverlust (RPO). Wenn dein Server regelmaessig angegriffen wird, erwaege stuendliche Backups.

3. Verlasse dich nicht nur auf Autosave. Autosave ueberschreibt dieselben Dateien. Wenn sie beschaedigt werden, schreibt Autosave die beschaedigte Version ueber die gute. Ein richtiges Backup-System bewahrt mehrere historische Kopien auf.

4. Halte lokale Backups auf einer separaten Festplatte. Wenn die primaere Festplatte unter der schweren I/O-Last eines Angriffs ausfaellt, sterben Backups auf derselben Festplatte mit.

Mehr zur Wiederherstellung nach Angriffen findest du in unserem Post-DDoS Recovery Guide. Zur allgemeinen Serverhaertung empfehlen wir die Sicherheits-Checkliste 2026. Und wenn du wissen willst, was du tun sollst, wenn dein Server gerade aktiv unter Beschuss steht, haben wir auch dafuer einen Guide.

Backup-Monitoring

Backups sind nutzlos, wenn sie leise kaputtgehen. Fuege Monitoring hinzu:

#!/bin/bash
# check-backup-health.sh
BACKUP_DIR="/backup/minecraft/latest"
MAX_AGE_HOURS=6
DISCORD_WEBHOOK="https://discord.com/api/webhooks/DEIN_WEBHOOK"

LATEST_MOD=$(stat -c %Y "$BACKUP_DIR/world/level.dat" 2>/dev/null || echo 0)
NOW=$(date +%s)
AGE_HOURS=$(( (NOW - LATEST_MOD) / 3600 ))

if [ "$AGE_HOURS" -gt "$MAX_AGE_HOURS" ]; then
    curl -s -H "Content-Type: application/json" \
        -d "{\"content\":\"[ALARM] MC Backup ist $AGE_HOURS Stunden alt (max: $MAX_AGE_HOURS). Backup-System pruefen!\"}" \
        "$DISCORD_WEBHOOK"
fi

Zu cron hinzufuegen: 0 */2 * * * /opt/scripts/check-backup-health.sh. Wenn das Backup seit ueber 6 Stunden nicht aktualisiert wurde, bekommst du eine Discord-Benachrichtigung, bevor die Katastrophe einschlaegt.

Schnell-Setup-Checkliste (30 Minuten)

1. [5 Min] Erstelle /backup/minecraft und das Backup-Skript aus diesem Artikel
2. [3 Min] Zu cron hinzufuegen (alle 4 Stunden)
3. [5 Min] borgbackup installieren (apt install borgbackup), Repository initialisieren
4. [5 Min] rclone installieren (apt install rclone), Backblaze B2 konfigurieren (kostenlos bis 10 GB)
5. [5 Min] Cloud-Upload-Skript einrichten + cron
6. [5 Min] Erstes Backup manuell ausfuehren und ueberpruefen
7. [2 Min] Monitoring einrichten (Discord-Webhook bei Fehler)

30 Minuten jetzt sparen Wochen Arbeit spaeter. Einen Server kann man an einem Tag von Grund auf neu aufbauen. Eine Welt, an der Spieler sechs Monate lang gebaut haben, kann man nicht neu erstellen. Die Bauwerke, die Farmen, die Erinnerungen, das Community-Investment. Alles weg, weil niemand 30 Minuten fuer Backups investiert hat. Sei nicht dieser Admin.