Automatiser les sauvegardes d'un serveur FiveM et tester la restauration

Un serveur FiveM sans sauvegarde automatique, c'est une communauté entière à un accident près de perdre ses personnages, son économie et ses ressources configurées sur des semaines. Ce guide montre comment automatiser les sauvegardes des fichiers et de la base de données d'un serveur FiveM sur Linux, et comment tester une vraie restauration avant d'en avoir besoin en urgence.

Il s'adresse au propriétaire d'un serveur FiveM ou d'un VPS Linux chez ElypseCloud, tournant sous Ubuntu 22.04/24.04 avec ESX Legacy, QBCore ou Qbox et une base de données MySQL/MariaDB. Toutes les opérations s'effectuent en ligne de commande via SSH.

Ce qu'il faut sauvegarder (et ce qu'on peut ignorer)

Un serveur FiveM sépare clairement les fichiers remplaçables des données irremplaçables. La sauvegarde ne concerne que les données, pour éviter toute perte de données irrémédiable.

Fichiers critiques à sauvegarder

resources/ : tous les scripts installés, leurs fichiers de configuration (config.lua), vos ressources personnalisées et les scripts achetés. Les scripts peuvent se réinstaller ; six mois de configuration ne peuvent pas.
server.cfg et ses fichiers inclus : convars, clé de licence, ordre des ensure, permissions ACE. Un fichier de sauvegarde de la configuration permet de remonter le serveur en quelques minutes.
Base de données MySQL/MariaDB : pour ESX, QBCore et Qbox, c'est ici que vivent les personnages, l'inventaire, les véhicules, l'économie et les bans. La sauvegarde de base de données est la priorité absolue. Une restauration des fichiers sans la base de données restaure un serveur vide.
txData/ : configuration txAdmin, comptes administrateurs, historique des joueurs et des bans. Les bans sont perdus lors d'une migration si ce dossier n'est pas dans la copie de sauvegarde.

Fichiers à ignorer pour économiser de l'espace

cache/ et cache_priv/ : régénérés automatiquement au démarrage. Leur inclusion dans les fichiers de sauvegarde gonfle les archives inutilement.
node_modules/ : dépendances npm réinstallables via npm install.
Binaires FXServer (artefacts) : téléchargeables à tout moment. Notez simplement le numéro de build utilisé.

Étape 1 : sauvegarder la base de données avec mysqldump

Le nom de votre base de données se lit dans server.cfg, dans la ligne set mysql_connection_string. Exemple :

set mysql_connection_string "mysql://fivem_user:motdepasse@localhost:3306/fivem_prod?charset=utf8mb4"

Le nom de base est le segment après le dernier / et avant ?, ici fivem_prod.

La commande recommandée utilise --single-transaction pour capturer l'état cohérent des tables InnoDB sans bloquer les joueurs connectés. Cette approche produit un fichier de sauvegarde cohérent de toute la base de données :

mysqldump -u fivem_user -p'motdepasse' \
  --single-transaction \
  --quick \
  --lock-tables=false \
  --routines \
  --triggers \
  fivem_prod | gzip -9 > /backups/fivem_db_$(date +%Y-%m-%d_%H%M).sql.gz

La compression par gzip -9 réduit la taille du fichier de sauvegarde d'un facteur 5 à 10 selon le contenu. Vérifiez que la sauvegarde de base de données n'est pas vide avant de continuer :

ls -lh /backups/fivem_db_*.sql.gz | tail -3

Étape 2 : sauvegarder les fichiers du serveur

Archivez le dossier server-data (ou votre répertoire de ressources) en excluant le cache et les dépendances npm. Le script utilise tar avec compression pour créer un fichier de sauvegarde en une seule ligne de commande :

tar -czf /backups/fivem_files_$(date +%Y-%m-%d_%H%M).tar.gz \
  --exclude='*/resources/[cache]' \
  --exclude='*/node_modules' \
  --exclude='*/.git' \
  /home/fivem/server-data

Ajoutez txData/ si elle se trouve en dehors de server-data :

tar -czf /backups/fivem_txdata_$(date +%Y-%m-%d_%H%M).tar.gz \
  /home/fivem/txData

Pour les serveurs actifs, planifiez les sauvegardes de fichiers juste après un redémarrage automatique programmé dans txAdmin : l'archive correspond alors à un état propre et connu du serveur.

Étape 3 : script de sauvegarde automatisé

Ce script centralise la sauvegarde complète du serveur FiveM (base de données, fichiers, txData) avec logs et nettoyage automatique des sauvegardes anciennes :

sudo mkdir -p /opt/fivem-backup
sudo nano /opt/fivem-backup/backup.sh

Contenu du script :

#!/bin/bash
# backup.sh - Sauvegarde automatisee serveur FiveM
# Couvre : base de donnees MySQL, resources, txData

# Configuration
BACKUP_DIR="/backups/fivem"
SERVER_DATA="/home/fivem/server-data"
TXDATA_DIR="/home/fivem/txData"
DB_NAME="fivem_prod"
DB_USER="fivem_user"
DB_PASS="votre_mot_de_passe"
DB_HOST="localhost"
RETENTION_JOURS=7
LOGFILE="/var/log/fivem-backup.log"

# Preparation
mkdir -p "${BACKUP_DIR}"
DATE=$(date +%Y-%m-%d_%H%M%S)
log() { echo "[$(date +%Y-%m-%d_%H:%M:%S)] $1" >> "${LOGFILE}"; }

log "Debut de la sauvegarde FiveM"

# 1. Sauvegarde de base de donnees MySQL (dump compresse)
log "Dump base de donnees MySQL : ${DB_NAME}"
mysqldump -u "${DB_USER}" -p"${DB_PASS}" -h "${DB_HOST}" \
  --single-transaction --quick --lock-tables=false \
  --routines --triggers \
  "${DB_NAME}" | gzip -9 > "${BACKUP_DIR}/db_${DATE}.sql.gz"

if [ $? -eq 0 ]; then
  log "Sauvegarde de base OK : ${BACKUP_DIR}/db_${DATE}.sql.gz"
else
  log "ERREUR : echec du dump de la base de donnees"
  exit 1
fi

# 2. Copie de sauvegarde des fichiers server-data (sans cache)
log "Archive fichiers : ${SERVER_DATA}"
tar -czf "${BACKUP_DIR}/files_${DATE}.tar.gz" \
  --exclude='*/resources/[cache]' \
  --exclude='*/node_modules' \
  --exclude='*/.git' \
  "${SERVER_DATA}" 2>> "${LOGFILE}"
log "Copie de sauvegarde fichiers OK"

# 3. txData (config txAdmin, admins, bans)
if [ -d "${TXDATA_DIR}" ]; then
  log "Archive txData : ${TXDATA_DIR}"
  tar -czf "${BACKUP_DIR}/txdata_${DATE}.tar.gz" \
    "${TXDATA_DIR}" 2>> "${LOGFILE}"
  log "Archive txData OK"
fi

# 4. Nettoyage : retention des derniers jours seulement
log "Nettoyage des sauvegardes de plus de ${RETENTION_JOURS} jours"
find "${BACKUP_DIR}" -name "*.tar.gz" -mtime +${RETENTION_JOURS} -delete
find "${BACKUP_DIR}" -name "*.sql.gz" -mtime +${RETENTION_JOURS} -delete

log "Sauvegarde complete terminee avec succes"

Rendez le script exécutable et testez-le manuellement :

sudo chmod +x /opt/fivem-backup/backup.sh
sudo /opt/fivem-backup/backup.sh
cat /var/log/fivem-backup.log
ls -lh /backups/fivem/

Étape 4 : planifier avec cron

Une sauvegarde complète quotidienne à 4h du matin est un bon point de départ pour la plupart des serveurs FiveM :

sudo crontab -e

Ajoutez la ligne :

# Sauvegarde FiveM quotidienne a 4h00
0 4 * * * /opt/fivem-backup/backup.sh

Sauvegarde incrémentale avec rsync

Pour les serveurs avec de nombreuses ressources, une sauvegarde incrémentale par rsync complète efficacement l'approche tar. rsync ne copie que les fichiers modifiés depuis la dernière sauvegarde, réduisant la durée et l'espace disque consommé :

# Synchronisation incrementale des resources vers un repertoire de backup
rsync -aHAX --delete \
  --exclude='cache' --exclude='cache_priv' --exclude='node_modules' \
  /home/fivem/server-data/ /backups/fivem/rsync-latest/

Combinez la sauvegarde incrémentale rsync (quotidienne) avec un dump complet hebdomadaire de la base de données pour une stratégie de sauvegarde robuste.

Étape 5 : copier les sauvegardes hors site avec rclone

Stocker les fichiers de sauvegarde uniquement sur le même VPS est risqué. Utilisez rclone pour exporter les archives vers un stockage distant (Backblaze B2, Amazon S3, Google Drive) et vous protéger de la perte de données totale :

sudo apt install rclone -y
rclone config  # Configuration interactive du fournisseur distant

Ajoutez ces lignes au script après l'étape 3 :

# Exporter les sauvegardes hors site
rclone copy "${BACKUP_DIR}/db_${DATE}.sql.gz" "remote:fivem-backups/" \
  --transfers=2 2>> "${LOGFILE}"
rclone copy "${BACKUP_DIR}/files_${DATE}.tar.gz" "remote:fivem-backups/" \
  --transfers=2 2>> "${LOGFILE}"
log "Copie hors site terminee"

Étape 6 : tester la restauration

Une sauvegarde jamais testée est une hypothèse, pas une garantie. Effectuez un test de restauration mensuel ou avant toute mise à jour majeure. Voici la procédure complète de sauvegarde et restauration :

Importer la sauvegarde de la base de données

# Decompression du fichier de sauvegarde SQL
gunzip /backups/fivem/db_2026-10-01_040000.sql.gz

# Sur un nouveau serveur : creer la base de donnees d'abord
mysql -u root -p -e "CREATE DATABASE fivem_prod CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;"

# Importer le dump SQL dans la base de donnees
mysql -u fivem_user -p'motdepasse' fivem_prod < /backups/fivem/db_2026-10-01_040000.sql

Restaurer les fichiers depuis la copie de sauvegarde

# Extraction de l'archive des fichiers serveur
tar -xzf /backups/fivem/files_2026-10-01_040000.tar.gz -C /home/fivem/

# Restaurer txData si necessaire
tar -xzf /backups/fivem/txdata_2026-10-01_040000.tar.gz -C /home/fivem/

Vérifier après restauration

Après redémarrage du serveur FiveM, vérifiez dans la console txAdmin :

Absence d'erreurs ensure (ressources non chargées)
Connexion à la base de données active (log [mysql-async] ou [oxmysql])
Personnages et données économiques accessibles en jeu
Comptes admin et liste des bans txAdmin intacts

Consultez notre guide dédié pour sauvegarder et restaurer la base de données MySQL d'un serveur FiveM pour les cas avancés (restauration partielle, import sélectif de tables).

Sécurité des archives de sauvegarde

Vos archives contiennent la totalité de votre dossier resources/, y compris les scripts achetés et protégés, ainsi que server.cfg avec la clé de licence, les webhooks et les clés API. Protégez-les :

Restreignez les permissions du répertoire de sauvegarde : chmod 700 /backups/fivem
Pour les copies hors site, utilisez le chiffrement rclone ou référez-vous au guide chiffrer les sauvegardes Linux avant envoi hors site.
Ne partagez jamais une archive avec quelqu'un qui n'a pas besoin d'y accéder.

Guides complémentaires

Hébergez votre serveur FiveM sur un VPS Linux ElypseCloud avec accès SSH complet pour mettre en place ces sauvegardes dès aujourd'hui.

Voir les offres serveur FiveM