javaadvancedtutorial

Migrer un serveur Minecraft Java vers un nouvel hébergeur sans perdre la progression

Transférez mondes, joueurs et réglages avec une sauvegarde serveur arrêté, un environnement compatible, des tests privés et un retour possible.

Mis à jour 2026-08-12 · MapMC Editorial

Migrer un serveur Java ne consiste pas à copier uniquement le terrain. Inventaires, dimensions, permissions, plugins, mods et identité des joueurs constituent un même état. L'ancien hébergeur doit rester arrêté mais disponible jusqu'à la validation privée du nouveau.

Inventorier avant la maintenance

Relevez Minecraft, Java, logiciel et build serveur, chargeur, mods, plugins, datapacks, mémoire, arguments, port, online-mode, proxy et réglages propres au panneau. Listez tous les mondes et dimensions ; Paper, les plugins multiworld et les mods peuvent utiliser des structures différentes.

Notez aussi domaine, DNS et port public. Transformez économie, claims, homes et permissions en points de recette concrets.

Produire une sauvegarde hors ligne de référence

Annoncez la maintenance, bloquez les connexions, sauvegardez si nécessaire puis exécutez stop. Compressez le répertoire complet après l'arrêt. Stockez l'archive hors des deux hébergeurs, notez sa taille et comparez les empreintes si possible.

Ne résiliez pas l'ancien service et ne le rouvrez pas. Une copie à chaud peut réunir des données de moments distincts.

Préparer une destination compatible

Installez les mêmes versions de Java, serveur, chargeur, mods et plugins. Pour un passage entre Vanilla, Spigot, Paper, Fabric ou Forge, suivez la disposition documentée par le logiciel cible. Ne démarrez à vide que si le panneau doit créer sa structure, puis arrêtez et archivez ces fichiers de test.

Contrôlez espace, propriétaire, commande, port et vraie racine. Un transfert réussi vers une instance inactive ressemble à un transfert absent.

Transférer mondes, identités et configuration ensemble

Téléversez et extrayez le snapshot par la méthode prise en charge. Vérifiez level-name, monde principal, Nether, End, joueurs, progrès, statistiques, datapacks, whitelist, bannissements, opérateurs, permissions et bases de plugins.

N'exposez pas mots de passe ou clés dans une archive publique ; renouvelez toute valeur divulguée. Préservez online-mode et le transfert d'identité du proxy, sinon un nouvel UUID peut faire croire à une perte d'inventaire.

Faire une recette sur une adresse privée

Ne basculez pas encore le domaine. Limitez l'accès par liste blanche ou adresse temporaire et lisez tout le démarrage. Corrigez dépendances, versions et droits. Testez avec un administrateur et un joueur normal : spawn, constructions, dimensions, inventaires, économie, claims, portails et commandes.

Faites un petit changement, arrêtez et redémarrez. Une connexion réussie ne garantit pas une écriture durable.

Basculer sans deux mondes modifiables

Après validation, laissez l'ancien éteint et changez DNS, proxy ou adresse publiée. N'ouvrez jamais les deux copies aux vrais joueurs : la progression diverge immédiatement et aucune fusion générale n'est sûre.

Surveillez logs et erreurs durant la première session. Le cache DNS peut encore envoyer certains joueurs vers l'ancien serveur. Conservez backups et ancien service jusqu'à un vrai redémarrage et la vérification des automatisations.

Revenir en arrière comme une opération globale

Si la destination abîme les données ou ne supporte pas la pile, arrêtez-la d'abord. Le retour propre restaure le snapshot de référence chez l'ancien hébergeur et rebascule l'adresse, plutôt que d'échanger quelques fichiers dans les deux sens.

Documentez l'erreur et le test échoué. Modifier simultanément version, structure et sélection de fichiers masque la cause.

Conditions de fin

  • Environnement, mondes et réglages du panneau sont inventoriés.
  • L'archive vient d'un arrêt propre et se trouve hors hébergeurs.
  • La cible reproduit la pile ou suit une migration documentée.
  • Mondes, identité, permissions et configuration ont voyagé ensemble.
  • La recette privée couvre logs, joueurs, dimensions, sauvegarde et redémarrage.
  • Un seul serveur public était modifiable pendant la bascule.
  • L'ancien reste disponible pendant la période de risque.

La migration se termine lorsque l'histoire commune continue et qu'un retour éprouvé existe, pas lorsque le nouveau panneau passe au vert.

Sources et base de vérification

Nous privilégions la documentation officielle et affichons les références utilisées.

À utiliser avec MapMC