Intermédiaire ⏱ 14 min Mis à jour le 29 juillet 2026

Migrer un serveur FiveM sans perdre ses données

Changer d'hébergeur FiveM fait peur : et si on perdait la base, les scripts, la progression des joueurs ? Voici la méthode pour tout transférer proprement, sans coupure surprise.

La règle d’or : préparer le nouveau serveur avant de couper l’ancien

Migrer un serveur FiveM sans perdre les données exige de maintenir l’ancien serveur intact jusqu’à la validation complète du nouveau. La base MySQL, les ressources et la configuration doivent être transférées et testées avant d’annoncer la nouvelle adresse aux joueurs.

Respectez cet ordre :

Inventaire de l'ancien serveur

Sauvegarde des fichiers et de MySQL

Préparation du nouvel hébergement

Transfert et reconfiguration

Tests par connexion directe

Dernière synchronisation

Bascule des joueurs

Conservation temporaire de l'ancien serveur

Ne supprimez pas l’ancien service dès que les fichiers sont copiés. Une ressource peut démarrer correctement tout en rencontrant ensuite une erreur de base de données, de licence, de dépendance ou de permission.

Pour un serveur actif, prévoyez une courte maintenance lors de la synchronisation finale. Sans cela, un joueur pourrait enregistrer sa progression sur l’ancien serveur après votre premier export MySQL.

Le nouvel hébergement doit être validé avant la bascule. L’ancien serveur constitue votre solution de retour arrière tant que la migration n’est pas terminée.

Faire l’inventaire de tout ce qu’il faut transférer

Une migration FiveM ne se limite pas au dossier resources/. Relevez précisément l’emplacement et la version de chaque composant.

ÉlémentContenu à vérifier
resources/Scripts, frameworks, maps, véhicules et dépendances
server.cfgRessources démarrées, ports, convars et connexion MySQL
txData/Profils txAdmin, configuration, administrateurs et données associées
Base MySQLPersonnages, inventaires, métiers, véhicules et sanctions selon les scripts
ArtifactsVersion de FXServer utilisée
Licence Cfx.reClé configurée avec sv_licenseKey
AutomatisationsCron, scripts de redémarrage et services systemd
IntégrationsWebhooks Discord, clés API et services externes
Fichiers annexesLogos, fichiers audio, captures ou contenus envoyés

Localisez les fichiers importants :

find /chemin/fivem \
  -type f \
  \( -name "server.cfg" -o -name "*.sql" -o -name ".env" \)

Affichez les dossiers de ressources :

find /chemin/fivem/resources \
  -mindepth 1 \
  -maxdepth 2 \
  -type d

Notez également :

  • la distribution et sa version ;
  • la version de MariaDB ou MySQL ;
  • le framework utilisé : ESX, QBCore ou autre ;
  • la ressource MySQL : oxmysql ou une autre bibliothèque ;
  • le numéro de port du serveur ;
  • le profil txAdmin utilisé ;
  • la version des artifacts ;
  • l’ordre des lignes ensure dans server.cfg.

txAdmin conserve ses profils dans le dossier txData. Le chemin exact dépend du mode d’installation et peut être personnalisé avec le paramètre txDataPath.

Sauvegarder complètement l’ancien serveur

Arrêtez de préférence le serveur FiveM avant de produire l’archive définitive des fichiers :

sudo systemctl stop fivem

Adaptez la commande si le serveur est géré par un panel ou lancé manuellement.

Créez une archive :

tar \
  -czf "/var/backups/fivem-fichiers-$(date +%F_%H-%M).tar.gz" \
  /chemin/fivem/resources \
  /chemin/fivem/server.cfg \
  /chemin/fivem/txData

Le chemin de server.cfg peut se trouver dans un profil txAdmin ou dans un dossier de données distinct. Vérifiez-le avant de créer l’archive.

Contrôlez son contenu :

tar -tzf /var/backups/fivem-fichiers-AAAA-MM-JJ_HH-MM.tar.gz | head

Sauvegardez ensuite la base MySQL séparément. Une archive des fichiers FiveM ne contient pas automatiquement les personnages et inventaires enregistrés en base.

Des sauvegardes automatiques sont incluses pour vous aider à restaurer. Conservez aussi vos propres exports réguliers : vous restez responsable de vos données.

Conservez une copie hors de l’ancien et du nouveau serveur. Consultez également la stratégie de sauvegarde serveur.

Transférer les fichiers FiveM

Vous pouvez transférer les fichiers avec SFTP, SCP ou rsync. Pour une quantité importante de ressources, rsync facilite la reprise et les synchronisations suivantes.

Depuis l’ancien serveur :

rsync -avz \
  --progress \
  /chemin/fivem/resources/ \
  utilisateur@NOUVEAU_SERVEUR:/chemin/fivem/resources/

Transférez la configuration :

rsync -avz \
  /chemin/fivem/server.cfg \
  utilisateur@NOUVEAU_SERVEUR:/chemin/fivem/server.cfg

Puis les profils txAdmin :

rsync -avz \
  /chemin/fivem/txData/ \
  utilisateur@NOUVEAU_SERVEUR:/chemin/fivem/txData/

Si le nouvel hébergeur a déjà créé un profil txAdmin, sauvegardez-le avant de copier l’ancien :

mv /chemin/fivem/txData \
   /chemin/fivem/txData.initial

Les dossiers avec des crochets doivent être manipulés avec prudence :

resources/[core]/
resources/[esx]/
resources/[local]/

Dans un shell, les crochets peuvent être interprétés comme des motifs. Placez le chemin entre guillemets :

rsync -avz \
  "/chemin/fivem/resources/[local]/" \
  utilisateur@NOUVEAU_SERVEUR:"/chemin/fivem/resources/[local]/"

Vérifiez ensuite les propriétaires :

sudo chown -R fivem:fivem /chemin/fivem

Remplacez fivem:fivem par le compte réellement utilisé sur le nouvel hébergement.

Le guide pour transférer des fichiers vers un VPS détaille SFTP, SCP et rsync.

Migrer la base de données MySQL

Exporter la base sur l’ancien serveur

Placez temporairement le serveur en maintenance afin d’éviter de nouvelles écritures pendant l’export final.

Créez un dump :

mysqldump \
  --single-transaction \
  --routines \
  --triggers \
  -u fivem_user \
  -p \
  fivem_db \
  | gzip > "/var/backups/fivem-db-$(date +%F_%H-%M).sql.gz"

Le mot de passe est demandé de manière interactive.

Vérifiez l’archive :

gzip -t /var/backups/fivem-db-AAAA-MM-JJ_HH-MM.sql.gz

Transférez-la :

scp \
  /var/backups/fivem-db-AAAA-MM-JJ_HH-MM.sql.gz \
  utilisateur@NOUVEAU_SERVEUR:/tmp/

Créer la base sur le nouveau serveur

Connectez-vous à MySQL :

sudo mysql

Créez une base et un utilisateur dédié :

CREATE DATABASE fivem_db
  CHARACTER SET utf8mb4
  COLLATE utf8mb4_unicode_ci;

CREATE USER 'fivem_user'@'localhost'
  IDENTIFIED BY 'REMPLACEZ_PAR_UN_SECRET_FORT';

GRANT ALL PRIVILEGES
  ON fivem_db.*
  TO 'fivem_user'@'localhost';

FLUSH PRIVILEGES;
EXIT;

Importez le dump :

gunzip -c /tmp/fivem-db-AAAA-MM-JJ_HH-MM.sql.gz \
  | mysql \
      -u fivem_user \
      -p \
      fivem_db

Contrôlez les tables :

mysql \
  -u fivem_user \
  -p \
  -e "SHOW TABLES;" \
  fivem_db

Adaptez ensuite la chaîne de connexion dans server.cfg. Avec oxmysql, elle peut prendre cette forme :

set mysql_connection_string "mysql://fivem_user:MOT_DE_PASSE@127.0.0.1:3306/fivem_db?charset=utf8mb4"

Ne publiez jamais la chaîne de connexion complète, la clé Cfx.re ou un webhook dans Git, une capture d’écran, un tutoriel ou un ticket public.

Si le mot de passe contient des caractères réservés dans une URL, encodez-les correctement ou utilisez une syntaxe prise en charge par votre bibliothèque MySQL.

Consultez le guide sur oxmysql et la base de données FiveM.

Reconfigurer la licence, les artifacts et server.cfg

Vérifiez la clé présente dans la configuration :

sv_licenseKey "VOTRE_CLE_CFX"

La clé doit rester privée. Selon la configuration de votre compte Cfx.re et les caractéristiques de la nouvelle adresse, vous devrez peut-être adapter ou recréer l’enregistrement de serveur correspondant.

Consultez le guide sur la licence Cfx.re avant la première mise en production.

Vérifiez aussi les endpoints :

endpoint_add_tcp "0.0.0.0:30120"
endpoint_add_udp "0.0.0.0:30120"

Le port réel doit correspondre à celui attribué par le nouvel hébergement.

Pour les artifacts, relevez d’abord la version utilisée sur l’ancien serveur. Pendant le test, conserver une version compatible peut faciliter l’identification des différences liées à la migration.

Ne conservez toutefois pas durablement une version arrivée en fin de support. Les artifacts obsolètes peuvent perdre la prise en charge officielle ou rencontrer des restrictions de visibilité et de connexion. Une fois la migration validée, planifiez une mise à jour séparée et testée.

Consultez le guide pour mettre à jour les artifacts FiveM.

Contrôlez enfin :

Chemins de resources/
Ordre des ensure
Ports
Connexion MySQL
Nom du profil txAdmin
Webhooks
Clés API
Permissions ACE
Fichiers de configuration des scripts

Pour reprendre la gestion du serveur, consultez le guide démarrer avec txAdmin.

Tester avant de rediriger les joueurs

Démarrez le nouveau serveur depuis txAdmin et surveillez la console.

Recherchez notamment :

Couldn't find resource
Access denied
Unable to connect to database
Unknown column
Table doesn't exist
Failed to verify license key
Address already in use

Connectez-vous directement depuis la console F8 du client FiveM :

connect ADRESSE_IP:30120

Testez avec un compte réel ou un personnage de test :

  • chargement du personnage ;
  • inventaire ;
  • argent et comptes bancaires ;
  • métiers et grades ;
  • véhicules possédés ;
  • logements ;
  • sanctions et whitelist ;
  • téléphone ;
  • scripts dépendant de MySQL ;
  • permissions administrateur ;
  • redémarrage des ressources ;
  • reconnexion après un restart.

Contrôlez aussi la base pendant les tests :

SHOW TABLES;
SELECT COUNT(*) FROM users;

Adaptez les noms de tables au framework.

Ne communiquez pas encore la nouvelle adresse à toute la communauté. Limitez les tests à l’équipe technique et à quelques personnes de confiance.

Basculer proprement vers le nouvel hébergement

Lorsque tous les tests sont concluants :

  1. annoncez une courte maintenance ;
  2. empêchez les nouvelles connexions sur l’ancien serveur ;
  3. arrêtez les scripts qui écrivent en base ;
  4. réalisez un dernier dump MySQL ;
  5. importez ce dump sur le nouveau serveur ;
  6. synchronisez les derniers fichiers modifiés ;
  7. testez une dernière connexion ;
  8. ouvrez le nouveau serveur aux joueurs.

Si vous utilisez un domaine ou une entrée DNS pour la connexion, mettez-la à jour après le test final. La propagation DNS peut créer une période pendant laquelle les deux destinations sont encore utilisées.

Communiquez clairement :

Nouvelle adresse de connexion
Date et heure de la bascule
Éventuelle durée de maintenance
Canal de signalement des problèmes

Gardez l’ancien hébergement quelques jours sans le modifier. Ne le réouvrez pas aux joueurs, au risque de créer deux versions divergentes de la base.

Conservez également :

  • le dump MySQL final ;
  • l’archive des fichiers ;
  • l’ancienne configuration ;
  • la version des artifacts ;
  • une copie des logs de migration.

En résumé

  • Pour migrer un serveur FiveM, préparez et testez le nouveau avant de couper l’ancien.
  • Inventoriez resources/, server.cfg, txData/, MySQL, les artifacts et les automatisations.
  • Notez les versions du framework, de MySQL et des ressources principales.
  • Réalisez une archive complète des fichiers et un dump séparé de la base.
  • Conservez une copie indépendante des deux hébergements.
  • Transférez les fichiers avec SFTP, SCP ou rsync.
  • Placez entre guillemets les chemins contenant des dossiers comme [local].
  • Importez MySQL dans une base et un utilisateur dédiés.
  • Adaptez la chaîne de connexion sans exposer ses identifiants.
  • Gardez la clé Cfx.re et les webhooks strictement secrets.
  • Vérifiez les ports, chemins, lignes ensure et permissions.
  • Testez le nouveau serveur avec connect IP:port.
  • Contrôlez les personnages, inventaires, métiers, véhicules et écritures MySQL.
  • Effectuez un dernier export pendant une courte maintenance.
  • Ne laissez pas les joueurs utiliser simultanément deux bases divergentes.
  • Gardez l’ancien serveur quelques jours comme solution de retour arrière.
  • Pour migrer un serveur FiveM vers un hébergement en France avec stockage NVMe, protection Anti-DDoS L3/L4/L7 incluse, panel de gestion et support francophone, découvrez les offres FiveM TalCloud.