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ément | Contenu à vérifier |
|---|---|
resources/ | Scripts, frameworks, maps, véhicules et dépendances |
server.cfg | Ressources démarrées, ports, convars et connexion MySQL |
txData/ | Profils txAdmin, configuration, administrateurs et données associées |
| Base MySQL | Personnages, inventaires, métiers, véhicules et sanctions selon les scripts |
| Artifacts | Version de FXServer utilisée |
| Licence Cfx.re | Clé configurée avec sv_licenseKey |
| Automatisations | Cron, scripts de redémarrage et services systemd |
| Intégrations | Webhooks Discord, clés API et services externes |
| Fichiers annexes | Logos, 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
ensuredansserver.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 :
- annoncez une courte maintenance ;
- empêchez les nouvelles connexions sur l’ancien serveur ;
- arrêtez les scripts qui écrivent en base ;
- réalisez un dernier dump MySQL ;
- importez ce dump sur le nouveau serveur ;
- synchronisez les derniers fichiers modifiés ;
- testez une dernière connexion ;
- 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
ensureet 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.