Utiliser le coupon WELCOME pour économiser 20 %

$ USD
  • $ USD
  • € EUR
  • £ GBP
  • $ AUD
  • R$ BRL
  • CHF CHF
  • ¥ JPY
Comment sauvegarder le serveur FiveM

Comment sauvegarder et restaurer un serveur FiveM

Une sauvegarde FiveM récupérable associe la base de données aux ressources et à la configuration correspondantes. Prouvez-le en restaurant cette paire sur un serveur isolé et en vérifiant l'état du joueur après un redémarrage.

Définir un point de récupération

Incluez server-data, server.cfg, les permissions, les profils txAdmin nécessaires, les ressources personnalisées et le relevé des versions. Notez les versions des artefacts et des frameworks ainsi que les dépendances externes. Conservez les secrets dans des sauvegardes privées, jamais dans des dépôts publics.

Pour obtenir un ensemble cohérent, prévoyez une maintenance et arrêtez FXServer ainsi que les autres applications qui écrivent dans la base avant l’export final de la base de données et la copie des fichiers. Ne modifiez pas le schéma pendant l’export. Les exemples ci-dessous utilisent MariaDB ; les installations MySQL doivent utiliser les outils et options correspondants de leur éditeur.

Préparer l'authentification de la base de données

Utilisez un compte de sauvegarde dédié avec les privilèges requis par les fonctionnalités de votre base de données. Stockez ses détails de connexion dans un fichier d'options MariaDB privé lisible uniquement par le compte de sauvegarde. Gardez-le en dehors de la racine web et du dépôt.

La documentation de mariadb-dump explique l’authentification et les limites des instantanés cohérents. --single-transaction fournit un instantané cohérent pour les tables transactionnelles ; cette option ne rend pas cohérentes les tables non transactionnelles.

Exemple Linux

Exécutez ceci en tant qu'utilisateur de sauvegarde autorisé après avoir coordonné les écritures. Remplacez le nom de la base de données et les chemins par votre installation réelle. Le fichier d'options privé doit déjà exister :

#!/usr/bin/env bash
set -euo pipefail
umask 077
stamp=$(date -u +%Y%m%dT%H%M%SZ)
dest="/srv/backups/fivem/$stamp"
install -d -m 0700 "$dest"
mariadb-dump --defaults-extra-file=/etc/fivem/backup.cnf \
  --single-transaction --routines --events --triggers \
  --databases fivem --result-file="$dest/database.sql"
test -s "$dest/database.sql"
tar -C /srv/fivem -czf "$dest/server-data.tar.gz" server-data
tar -tzf "$dest/server-data.tar.gz" > /dev/null
sha256sum "$dest/database.sql" "$dest/server-data.tar.gz" > "$dest/SHA256SUMS"

Ajoutez tous les chemins txAdmin/configuration requis en dehors de server-data à votre ensemble de sauvegarde. Testez la commande sous le même compte et environnement utilisés par cron ou un timer systemd. Alertez en cas de statut de sortie non nul.

Exemple Windows PowerShell

Utilisez le chemin réel vers mariadb-dump.exe et un fichier d'options privé. --result-file évite les modifications d'encodage de texte du shell vers le dump :

$ErrorActionPreference = "Stop"
$Stamp = (Get-Date).ToUniversalTime().ToString("yyyyMMddTHHmmssZ")
$Destination = "D:\FiveM-Backups\$Stamp"
New-Item -ItemType Directory -Path $Destination | Out-Null
& "C:\MariaDB\bin\mariadb-dump.exe" `
  "--defaults-extra-file=D:\FiveM-Private\backup.cnf" `
  --single-transaction --routines --events --triggers `
  --databases fivem "--result-file=$Destination\database.sql"
if ($LASTEXITCODE -ne 0) { throw "Database dump failed" }
if ((Get-Item "$Destination\database.sql").Length -eq 0) { throw "Empty dump" }
Copy-Item "D:\FXServer\server-data" "$Destination\server-data" -Recurse
Get-FileHash "$Destination\database.sql" | Format-List

Restreignez les autorisations Windows du répertoire de sauvegarde aux administrateurs de sauvegarde et de récupération. Dans le Planificateur de tâches, utilisez des chemins d'exécution explicites et un compte dédié ; vérifiez son historique et les alertes d'échec.

Restaurer sur un serveur isolé

  1. Choisissez une génération de sauvegarde complète et vérifiez ses sommes de contrôle ou l'intégrité de l'archive. Ne combinez jamais une base de données plus récente avec des ressources arbitraires plus anciennes.
  2. Extrayez les fichiers dans un emplacement de test séparé. Préparez un service de base de données isolé et restaurez database.sql avec le client MariaDB correspondant. Le dump contient le nom de la base de données, ne l'importez donc pas dans le service en direct.
  3. Définissez des identifiants et des points de terminaison de test uniquement et démarrez la combinaison artefact/framework enregistrée. Empêchez les ressources de test d'envoyer de vrais paiements, des webhooks ou des notifications aux joueurs.
  4. Rejoignez avec un joueur de test. Vérifiez le personnage, l'inventaire, les métiers, le logement et les autorisations ; reconnectez-vous et redémarrez, puis vérifiez à nouveau.
  5. Enregistrez la durée de la restauration et toute dépendance manquante. Conservez plusieurs générations, une copie chiffrée hors site et un compte de sauvegarde qui ne peut pas effacer toutes les générations distantes.

Reprenez les écritures normales seulement après que l'ensemble de sauvegarde soit complet. Une tâche planifiée réussie est une preuve utile ; une restauration réussie est la vérification qui rend la sauvegarde digne de confiance.

Laisser un commentaire