FiveM Server Backup-Strategien: Automatisierte MySQL und Ressourcen

Framework hub

Browse QBCore-ready scripts

Move into the QBCore landing page to compare verified scripts, framework fit, and install-ready products built for modern FiveM servers.

Verwende dies als deine Basis-Inventur:

Verschwende keinen Speicherplatz für Cache-Verzeichnisse, temporäre Build-Ausgaben, Paket-Ordner wie node_modules oder jede alte Artifact-Binärdatei. Bewahre genug Informationen zum Wiederaufbau auf, nicht jedes entbehrliche Byte.

Die 3-2-1-Regel ohne Überkomplizierung

Das klassische Backup-Modell funktioniert immer noch:

• Drei Kopien wichtiger Daten.
• Zwei verschiedene Speichertypen oder -orte.
• Eine Kopie extern.

Für einen kleinen FiveM-Server kann das einfach sein:

1. Live-Server-Daten auf dem VPS.
2. Lokaler Backup-Ordner auf dem VPS für schnelles Rollback.
3. Externe Kopie in S3-kompatiblem Storage, Backblaze B2, einem anderen Server oder einem privaten NAS.

Die externe Kopie ist diejenige, die zählt, wenn der Host das Konto sperrt, eine Festplatte ausfällt, Ransomware die Box verschlüsselt oder jemand das falsche Verzeichnis löscht.

Hier treffen sich auch Sicherheitsplanung und Backup-Planung. Wenn du Firewall-Regeln, Reverse-Proxys oder Anbieterschutz änderst, lies den FiveM DDoS-Schutzleitfaden, bevor du annimmst, dass derselbe Host-Level-Snapshot jeden Fehlermodus abdeckt.

Datenbank-Backup-Strategie

Die meisten Roleplay-Frameworks speichern kritischen Zustand in MySQL oder MariaDB. Ein logischer Dump reicht normalerweise für kleine und mittlere Communities. Er ist portabel, leicht zu inspizieren und einfach in Staging wiederherzustellen.

Für MariaDB-11- und neuere Umgebungen bevorzuge mariadb-dump, wo verfügbar. Viele Systeme stellen weiterhin mysqldump bereit, aber die aktuelle MariaDB-Dokumentation verweist Administratoren auf mariadb-dump. MySQL-Server sollten mysqldump aus dem passenden MySQL-Client-Paket verwenden.

Erstelle einen eingeschränkten Backup-Benutzer anstelle von root:

CREATE USER 'fivem_backup'@'localhost' IDENTIFIED BY 'change-this-password';
GRANT SELECT, SHOW VIEW, TRIGGER, EVENT, LOCK TABLES ON fivem.* TO 'fivem_backup'@'localhost';
FLUSH PRIVILEGES;

Verwende dann einen Dump-Befehl wie diesen:

#!/usr/bin/env bash
set -euo pipefail

BACKUP_DIR="/opt/fivem/backups/mysql"
DB_NAME="fivem"
STAMP="$(date -u +%Y%m%dT%H%M%SZ)"
OUT="$BACKUP_DIR/${DB_NAME}-${STAMP}.sql.gz"

mkdir -p "$BACKUP_DIR"

mariadb-dump \
  --single-transaction \
  --routines \
  --events \
  --triggers \
  --default-character-set=utf8mb4 \
  "$DB_NAME" | gzip -9 > "$OUT"

find "$BACKUP_DIR" -type f -name "${DB_NAME}-*.sql.gz" -mtime +14 -delete

Verwende --single-transaction für InnoDB-Tabellen, damit der Dump konsistent ist, ohne den gesamten Server länger als nötig zu sperren. Wenn deine Datenbank nicht-InnoDB-Tabellen verwendet, teste sorgfältig, da sich das Sperrverhalten ändert.

Mit Cron automatisieren

Für einen moderaten Server führe Datenbank-Backups alle sechs Stunden durch und behalte tägliche externe Kopien. Beispiel-Cron:

15 */6 * * * /opt/fivem/scripts/backup-db.sh >> /opt/fivem/logs/backup-db.log 2>&1
35 3 * * * /opt/fivem/scripts/sync-backups-offsite.sh >> /opt/fivem/logs/backup-sync.log 2>&1

Plane Backups nicht genau zur vollen Stunde, wenn dein Anbieter Snapshots oder Monitoring-Jobs zur gleichen Zeit ausführt. Wähle ungerade Minuten, damit deine Arbeitslast weniger wahrscheinlich mit geteilten Infrastruktur-Aufgaben kollidiert.

Überprüfe nach der Ausführung des Jobs die Logs genauso, wie du einen Server-Absturz untersuchen würdest. Der FiveM-Server-Debugging-Leitfaden ist ein nützlicher Begleiter, da fehlgeschlagene Backups normalerweise als langweilige Berechtigungs-, Pfad-, Festplatten- oder Verbindungsfehler auftauchen.

Externer Upload mit rclone

rclone funktioniert mit vielen Storage-Backends, einschließlich S3-kompatibler Anbieter. Konfiguriere die Remote-Verbindung interaktiv auf dem Server und halte die Zugangsdaten nur für den Backup-Benutzer lesbar.

Beispiel-Sync-Script:

#!/usr/bin/env bash
set -euo pipefail

LOCAL="/opt/fivem/backups"
REMOTE="fivem-backups:prod-server-01"

rclone sync "$LOCAL" "$REMOTE" \
  --fast-list \
  --transfers 4 \
  --checkers 8 \
  --log-file /opt/fivem/logs/rclone-backup.log \
  --log-level INFO

Verwende eine Bucket-Lebenszyklusrichtlinie oder einen separaten Bereinigungsjob für die langfristige Aufbewahrung. Wenn du jede Nacht eine einzelne Remote-Datei überschreibst, hast du keinen Verlauf. Du hast eine Kopie, die durch ein beschädigtes Backup ersetzt werden kann.

Ressourcen- und Konfigurations-Backups

Behandle Ressourcen, die du schreibst, als Code. Lege sie in Git ab, überprüfe Änderungen und tagge bekannte gute Releases. Das gibt dir Verlauf, Diffs, Rollback und eine saubere Möglichkeit zu sehen, was sich vor einem Absturz geändert hat.

Für Marketplace-Ressourcen, escrow-geschützte Assets oder Scripts, die manuell installiert werden, bewahre ein privates Archiv der installierten Version und Kauf-/Download-Belege auf. Gehe nicht davon aus, dass der Link eines Verkäufers in einem Notfall noch funktioniert.

Ein einfaches Datei-Backup kann so aussehen:

#!/usr/bin/env bash
set -euo pipefail

ROOT="/opt/fivem"
BACKUP_DIR="$ROOT/backups/files"
STAMP="$(date -u +%Y%m%dT%H%M%SZ)"

mkdir -p "$BACKUP_DIR"

tar \
  --exclude="$ROOT/server-data/cache" \
  --exclude="$ROOT/server-data/resources/**/node_modules" \
  --exclude="$ROOT/backups" \
  -czf "$BACKUP_DIR/fivem-files-$STAMP.tar.gz" \
  "$ROOT/server-data" \
  "$ROOT/txData"

find "$BACKUP_DIR" -type f -name "fivem-files-*.tar.gz" -mtime +30 -delete

Führe dies nach Ressourcen-Änderungen, vor Framework-Upgrades und vor großen Content-Importen aus. Wenn deine Ressourcen groß sind, verwende inkrementelle Dateisystem-Snapshots oder rsync --link-dest anstelle von vollständigen Archiven jede Stunde.

Aufbewahrungsplan, der tatsächlich hilft

Die Aufbewahrung sollte daran ausgerichtet sein, wie schnell Probleme entdeckt werden. Ein defektes Inventar-Script wird möglicherweise mehrere Stunden lang nicht bemerkt. Ein schlechter Economy-Exploit erfordert möglicherweise ein Rollback von gestern. Ein rechtlicher Streit oder Moderationsvorfall erfordert möglicherweise ältere Logs.

Verwende diesen Ausgangspunkt:

Für größere Communities füge wöchentliche und monatliche Archive hinzu. Für kleine Testserver reicht täglich möglicherweise aus. Der Schlüssel ist, die Regel aufzuschreiben und zu automatisieren.

Wiederherstellungstests

Ein Wiederherstellungstest ist der Unterschied zwischen Vertrauen und Hoffnung. Plane einen monatlich und führe immer einen vor einem großen Launch durch.

Stelle in Staging wieder her, nicht in Produktion:

1. Erstelle eine frische Datenbank.
2. Importiere den neuesten SQL-Dump.
3. Entpacke das neueste Ressourcen-/Konfigurations-Archiv.
4. Starte FXServer mit einem Staging-Lizenzschlüssel und Staging-Ports.
5. Verbinde dich mit einem Test-Account.
6. Überprüfe Charaktere, Inventar, Geld, Jobs, Housing, Fahrzeuge, Berechtigungen und wichtige Admin-Befehle.
7. Notiere die Wiederherstellungszeit und alle manuellen Schritte.

Dein Ziel ist nicht nur „der Import war erfolgreich". Dein Ziel ist „ein Staff-Mitglied kann dem Runbook folgen und Spieler würden ihren Status wiedererkennen".

Disaster-Szenarien, für die du planen solltest

Versehentliche Datenbanklöschung

Stoppe den Server, bewahre den aktuellen defekten Zustand zur Untersuchung auf, stelle den neuesten bekannten guten Dump in Staging wieder her und entscheide dann, ob du die Produktion wiederherstellst oder gezielt bestimmte Tabellen kopierst.

Schlechtes Ressourcen-Update

Setze die Ressource aus Git oder dem Datei-Archiv zurück. Wenn das Update Datenbanktabellen migriert hat, prüfe, ob du auch eine Datenbankwiederherstellung benötigst. Führe kein Downgrade von Scripts gegen ein neueres Schema durch, ohne es zu überprüfen.

Host-Ausfall

Stelle einen neuen Host bereit, installiere Abhängigkeiten, stelle Dateien und Datenbank wieder her, aktualisiere DNS oder Verbindungsinformationen und teste dann Staff-Login und Spielerverbindung. Deshalb müssen externe Backups Konfigurationen enthalten und nicht nur SQL.

Ransomware oder kompromittiertes Admin-Konto

Gehe davon aus, dass lokale Backups kompromittiert sind. Rotiere Zugangsdaten, stelle aus dem externen Backup wieder her, überprüfe den Staff-Zugriff und prüfe auf modifizierte Ressourcen, bevor du live gehst.

Backup-Checkliste

Verwende dies als minimalen Betriebsstandard:

• Datenbank-Backups laufen automatisch.
• Backup-Logs werden überprüft oder alarmiert.
• Externe Synchronisation ist erfolgreich.
• Konfigurations- und Ressourcen-Änderungen werden vor Updates gesichert.
• Secrets werden in einem Passwort-Manager gespeichert, nicht nur in Server-Dateien.
• Ein Wiederherstellungstest wurde in den letzten 30 Tagen abgeschlossen.
• Mindestens ein weiterer vertrauenswürdiger Admin kennt den Wiederherstellungsprozess.
• Der Backup-Bucket oder Remote-Speicher ist nicht von jedem Staff-Mitglied beschreibbar.

Backups sind nicht glamourös, aber sie sind eines der wenigen Systeme, die am meisten zählen, wenn alles andere bereits kaputt ist. Halte das Setup einfach, automatisiere es, teste es und dokumentiere den Wiederherstellungspfad, bevor deine Community davon abhängt.