Avant de commencer
Créez une sauvegarde complète datée et une copie indépendante. Arrêtez les écritures ou utilisez une sauvegarde cohérente avec l’application : copier un dossier actif ne garantit pas la cohérence SQL. Testez la restauration sur une destination isolée. Préservez l’original jusqu’à validation.
Inventorier FXServer et toutes ses configurations
Relevez l’artifact FXServer, la version ESX ou QBCore, le connecteur SQL et les arguments de lancement. Incluez server.cfg, chaque configuration chargée par exec, resources, scripts, maps, assets diffusés et chemins personnalisés. Le seul dossier resources ne constitue pas une sauvegarde complète.
Relevez les versions exactes, le démarrage, le stockage réellement utilisé et les dépendances externes. Inventoriez comptes, permissions, tâches planifiées, bases, licences, certificats et services hors du dossier de fichiers. Vérifiez les possibilités d’export chez l’ancien prestataire avant toute résiliation.
- server.cfg
- resources/
- exec
- ESX / QBCore
- oxmysql / MySQL / MariaDB
Conserver tous les profils txAdmin
server.cfg ne contient pas l’état administratif de txAdmin. Retrouvez le chemin txData réellement utilisé et le profil choisi au démarrage. Sauvegardez tout txData : profils, configuration, administrateurs, permissions et données de modération. Relevez les versions txAdmin/FXServer et ne créez pas un nouveau profil sur l’unique copie existante.
Créez une sauvegarde complète datée et une copie indépendante. Arrêtez les écritures ou utilisez une sauvegarde cohérente avec l’application : copier un dossier actif ne garantit pas la cohérence SQL. Testez la restauration sur une destination isolée. Préservez l’original jusqu’à validation.
- txData/
- serverProfile
- txDataPath
- txAdmin administrators / moderation
Exporter séparément les données ESX ou QBCore
Identifiez en privé le véritable serveur MySQL ou MariaDB. Exportez de manière cohérente personnages, inventaires, véhicules et tables personnalisées. Relevez utilisateurs, privilèges, jeu de caractères et collation. Restaurer les ressources ne restaure pas une base distante. Testez la sauvegarde puis le rechargement d’un personnage.
Préparez une destination compatible avec les logiciels, assez d’espace pour les données restaurées et les archives temporaires, les ports et les permissions nécessaires. Conservez les versions lors de la première restauration ; séparez les mises à niveau. Une quantité identique de RAM ou de vCPU ne prouve pas des performances équivalentes.
- characters / inventories / vehicles
- custom SQL tables
- users / privileges / collation
Respecter dépendances, licences et secrets
Restaurez d’abord les mêmes artifacts, framework et dépendances. Vérifiez les restrictions et licences des assets sans supposer leur transférabilité. Configurez clé Cfx.re, accès SQL et webhooks en privé à destination : aucune valeur dans cet assistant, une checklist, un dépôt ou une capture.
Planifiez un gel des écritures et un export final cohérent. Transférez séparément fichiers et exports SQL lorsque nécessaire. Comparez nombres de fichiers, tailles et sommes de contrôle d’une même archive stable. Une somme identique prouve l’intégrité du transfert, pas la cohérence ni l’exhaustivité des données.
- FXServer artifacts
- Cfx.re licence key
- webhooks
- SQL connector
Tester le serveur RP en privé
Contrôlez démarrage, console des ressources, connexion txAdmin et permissions, personnages, inventaires, véhicules et persistance après redémarrage propre. Testez séparément connexion directe et liste FiveM. Une page d’administration accessible ne valide pas le jeu TCP/UDP. Vérifiez allocation et périmètre de protection avec le prestataire sans test de flood.
Testez en privé avant ouverture : journaux de démarrage, authentification, permissions, données représentatives, persistance après redémarrage propre et dépendances externes. Vérifiez certificats et ports TCP/UDP sans exposer publiquement les interfaces d’administration. Consignez les contrôles et les écarts restant à résoudre.
- TCP + UDP game endpoint
- txAdmin access restrictions
- character save / reload
- FiveM server list
Basculer et garder une possibilité de retour
Gelez les écritures pour l’export final des fichiers et de SQL. Changez l’adresse du jeu ou les DNS concernés et informez les joueurs. Surveillez journaux, sauvegardes et écritures SQL. Si la destination a reçu des données nouvelles, prévoyez leur réconciliation avant de revenir à l’ancien serveur. Ne résiliez pas après un simple démarrage réussi.
Ne basculez l’adresse publiée ou les DNS qu’après les tests privés. Tenez compte des TTL et caches ; un changement de prestataire implique généralement une nouvelle IP. Surveillez erreurs, ressources et nouvelles écritures. Fixez un point de décision de retour arrière : après de nouvelles écritures, il faut réconcilier les données, pas simplement rétablir les DNS.
- final files + SQL export
- private acceptance test
- address / DNS
- rollback decision
Selon votre situation
| Situation | Prochaine vérification |
|---|---|
| Avant la migration | Ne commencez pas la bascule tant qu’une sauvegarde complète n’a pas été restaurée avec succès lors d’un test privé. |
| Pendant le transfert | Une copie à chaud peut manquer des changements simultanés. Préparez une réplication adaptée à l’application et une synchronisation finale avec un administrateur compétent ; aucune migration sans interruption n’est promise. |
| Après la bascule | Conservez l’ancien hébergeur et les sauvegardes originales jusqu’aux contrôles des données, connexions et sauvegardes. Définissez qui autorise la bascule et comment traiter les écritures créées après celle-ci. |
Sources officielles
Ces documents décrivent les protocoles et logiciels concernés. Les conditions de votre service et sa configuration restent à vérifier.