Comment migrer un serveur Minecraft sans perte

Migrer un serveur ne consiste pas à déplacer un simple dossier. Votre monde, les inventaires, les permissions, les données de plugins et l’adresse utilisée par les joueurs forment un ensemble dépendant. Savoir comment migrer un serveur Minecraft proprement permet d’éviter le scénario le plus coûteux pour une communauté : une carte qui démarre, mais des joueurs sans inventaire, des plugins inactifs ou plusieurs heures de progression perdues.

La bonne méthode privilégie une coupure courte, une sauvegarde vérifiable et des tests avant de basculer l’adresse publique. Elle s’applique à un petit serveur entre amis comme à une infrastructure Paper, Purpur, Forge ou Fabric accueillant plusieurs dizaines de joueurs.

Préparer la migration avant de toucher aux fichiers

Une migration fiable commence par un inventaire. Identifiez l’édition utilisée - Java ou Bedrock - la version exacte du jeu, le logiciel serveur et sa version. Un serveur Paper 1.21.x ne doit pas être démarré au hasard avec une version différente de Paper, ni avec un JAR Vanilla. Cette précaution est encore plus importante sur un serveur moddé, où chaque mod et chaque dépendance doivent correspondre à l’environnement d’origine.

Relevez également la mémoire allouée, les paramètres de lancement Java, les règles de pare-feu, le port de jeu, la configuration anti-DDoS et les tâches automatiques. Certains réglages ne se trouvent pas dans le dossier Minecraft : ils sont définis dans le panel d’hébergement, sur un VPS ou dans le système d’exploitation. Les oublier peut créer des lags ou empêcher les joueurs de se connecter après le transfert.

Prévenez la communauté d’un créneau de maintenance. Une migration effectuée sans annonce pousse souvent les joueurs à se reconnecter pendant la copie, ce qui rend les données incohérentes. Bloquez les nouvelles connexions quelques minutes avant l’arrêt, puis vérifiez que personne n’est encore actif.

Contrôler l’espace et les versions du nouvel hébergement

Le nouveau serveur doit disposer de plus d’espace disque que le volume actuellement utilisé. Ne calculez pas seulement le poids du monde principal : ajoutez les dimensions Nether et End, les sauvegardes, les logs, les cartes Dynmap ou BlueMap, les dossiers de plugins et les fichiers de mods. Gardez une marge pour les sauvegardes futures et la génération de nouveaux chunks.

Côté performances, comparez surtout la qualité du processeur, la mémoire disponible et le stockage. Un serveur avec beaucoup de joueurs ou de redstone dépend davantage de bonnes performances par cœur que d’un chiffre de RAM artificiellement élevé. Pour un modpack lourd, la mémoire compte davantage, mais un CPU saturé restera un goulot d’étranglement.

Faire une sauvegarde cohérente du serveur Minecraft

Ne copiez jamais un monde pendant que le serveur écrit encore des données. Même si les fichiers semblent transférés correctement, vous risquez de récupérer un état partiel des régions, des inventaires ou des bases de données de plugins.

Commencez par exécuter la commande `save-all`. Ensuite, arrêtez le serveur avec `stop` depuis sa console ou son panel. Évitez de forcer l’arrêt du processus sauf en cas de blocage réel. Attendez la confirmation que le processus est fermé avant de télécharger ou d’archiver les fichiers.

Créez alors une archive complète du répertoire serveur. Une sauvegarde complète est plus sûre qu’une sélection faite à la main, car certains plugins stockent leurs données dans des emplacements peu évidents. Conservez cette archive hors du serveur source et, idéalement, sur un stockage distinct du nouvel hébergement.

Avant de poursuivre, vérifiez l’archive : sa taille doit être cohérente avec le dossier d’origine et elle doit pouvoir être ouverte sans erreur. Cette étape paraît basique, mais une archive corrompue découverte après la suppression de l’ancien serveur transforme une migration simple en incident de production.

Les dossiers à vérifier en priorité

Même avec une copie intégrale, contrôlez la présence des éléments essentiels. Pour un serveur Java, cela comprend généralement le dossier du monde indiqué dans `server.properties`, ainsi que ses dimensions associées, les répertoires `plugins`, `mods`, `config`, `libraries` si nécessaire et le fichier du JAR serveur. Les fichiers `ops.json`, `whitelist.json`, `banned-players.json`, `banned-ips.json` et les permissions doivent aussi suivre la migration.

Ne négligez pas `server.properties`, `bukkit.yml`, `spigot.yml`, `paper-global.yml` ou les fichiers de configuration propres à votre distribution. Les noms exacts changent selon la version et le logiciel utilisé. Copiez ce qui existe dans votre installation plutôt que de vous fier à une liste générique.

Pour Bedrock, transférez le monde, les packs de comportement et de ressources, ainsi que les fichiers de configuration. Le principe reste identique : la version du serveur Bedrock doit rester compatible avec les données déplacées.

Déployer les fichiers sur le nouveau serveur

Installez d’abord la même version du logiciel serveur sur la nouvelle machine. Acceptez l’EULA, démarrez une première fois si votre panel le demande, puis arrêtez-le. Ce démarrage initial crée l’arborescence attendue et permet de vérifier que l’environnement Java, la mémoire et les droits de fichiers sont corrects.

Transférez ensuite l’archive via le gestionnaire de fichiers du panel, SFTP ou une méthode de copie adaptée à votre infrastructure. Pour une carte volumineuse, compresser les fichiers avant le transfert limite le nombre d’opérations et réduit le risque d’oublier un dossier. Décompressez dans le répertoire racine du serveur, sans créer par erreur un second dossier parent du type `serveur/serveur/world`.

Sur une offre spécialisée comme celles de HebergTonServ, le panel de gestion simplifie le déploiement et le contrôle du serveur, mais il ne remplace pas la vérification des fichiers. Une migration reste une opération d’administration : validez les versions et les chemins avant l’ouverture au public.

Si vous passez d’un VPS à un hébergement de jeu administré, certains paramètres de lancement système ne seront plus modifiables de la même façon. C’est normal. Conservez les réglages fonctionnels utiles, mais ne tentez pas de reproduire des arguments Java non compatibles avec le panel. À l’inverse, un passage vers un VPS peut demander l’ouverture manuelle du port, la configuration du service de démarrage et une protection réseau adaptée.

Tester avant la bascule publique

Démarrez le nouveau serveur avec une liste blanche active. Consultez la console dès les premières secondes. Une erreur de version Java, de dépendance de plugin ou de mod absent doit être corrigée avant tout changement DNS. Les messages d’avertissement mineurs sont fréquents, mais les erreurs répétées, les mondes non chargés et les plugins désactivés ne le sont pas.

Connectez-vous avec un compte de test et contrôlez les zones qui comptent réellement : spawn, dimensions, coffres, inventaire, homes, économies, grades, claims et mondes additionnels. Testez aussi les commandes staff et les plugins qui s’appuient sur une base de données externe. Si MySQL, Redis ou une base distante est utilisée, il faudra autoriser la nouvelle adresse IP ou mettre à jour les identifiants de connexion.

Les proxys Velocity et BungeeCord méritent une attention particulière. Vérifiez l’adresse des serveurs backend, les secrets de forwarding, les ports internes et les règles pare-feu. Une mauvaise configuration peut exposer directement un serveur backend ou empêcher les joueurs de rejoindre le réseau.

Changer l’adresse sans perdre les joueurs

Quand les tests sont validés, modifiez l’enregistrement DNS du sous-domaine utilisé par les joueurs pour qu’il pointe vers la nouvelle adresse IP. Si vous utilisez un enregistrement SRV, vérifiez également le port cible. Réduire le TTL avant la migration peut accélérer la propagation, mais tous les résolveurs ne respectent pas cette valeur de façon immédiate. Gardez donc l’ancien serveur disponible pendant la période de bascule.

Évitez de faire jouer la communauté sur les deux machines en même temps. Dès que la nouvelle adresse est active, stoppez l’ancien serveur ou activez une maintenance claire. Sinon, des progrès peuvent être enregistrés sur deux copies différentes du même monde, ce qui rend toute fusion risquée.

Résoudre les problèmes les plus fréquents

Un monde qui semble neuf provient souvent d’un mauvais nom dans `level-name` ou d’un dossier placé au mauvais niveau. Un Nether ou un End manquant indique généralement que les répertoires de dimensions n’ont pas été transférés avec le monde principal. Des inventaires vides peuvent signaler une différence entre les UUID en mode online et offline, un plugin d’authentification mal configuré ou une base de données non reconnectée.

Si les joueurs subissent du lag après la migration, ne concluez pas immédiatement que l’hébergement est en cause. Vérifiez la distance de rendu, les plugins de cartes, la génération de chunks, les fermes intensives et les tâches planifiées. Une nouvelle machine peut aussi reconstruire des caches lors du premier démarrage. Mesurez l’utilisation CPU, la mémoire, les TPS et les erreurs console avant de modifier la configuration.

Enfin, ne supprimez pas l’ancien environnement dès la première connexion réussie. Conservez-le arrêté, avec sa sauvegarde intacte, le temps de confirmer que les joueurs, les données critiques et le DNS fonctionnent normalement. Une migration réussie ne se juge pas au démarrage du serveur, mais à la continuité réelle de votre communauté.