Le serveur Minecraft a créé un nouveau monde : retrouver l'ancien

Voir un terrain neuf après un transfert ne signifie pas que l'ancien monde a disparu. Java crée souvent un autre dossier quand il ne trouve pas la cible, reçoit un autre nom ou échoue à lire la sauvegarde. Stoppez les écritures et conservez les deux mondes ainsi que le premier log anormal.

Arrêter et préserver les indices

Exécutez stop et confirmez la fin du processus. N'autorisez pas de progression dans le monde inattendu. Copiez hors de la racine active le monde voulu, le nouveau, server.properties et logs/latest.log. Notez noms, tailles, heures et action précédente.

Ne supprimez pas le nouveau dossier : son nom révèle ce que le serveur a tenté de charger. Désactivez le redémarrage automatique pendant le diagnostic.

Trouver la véritable racine

La racine contient directement level.dat. paris/paris/level.dat ajoute une couche ; un ZIP fermé ne se charge pas. Un petit dossier récent à côté d'un grand monde indique souvent un problème de nom ou de chemin.

Ne copiez pas seulement level.dat : régions, entités, joueurs et dimensions forment un ensemble. Vérifiez aussi la fin du transfert et de l'extraction.

Contrôler level-name et le panneau

Serveur arrêté, vérifiez :

level-name=mapmc-paris

La valeur correspond au dossier sans guillemets ni extension, avec la casse exacte sous Linux. Le panneau peut la réécrire. Un dossier créé nommé world pointe vers la valeur par défaut ; si le nom correspond mais le monde est neuf, examinez imbrication, droits et répertoire actif.

Identifier l'instance réellement exécutée

Un panneau peut proposer plusieurs instances, profils ou volumes. Consultez commande de lancement, chemin du JAR, nom d'instance et début du log. En auto-hébergement, vérifiez répertoire de travail et utilisateur du service.

Un déploiement ou une restauration planifiée peut remplacer des fichiers au démarrage. N'éparpillez pas la sauvegarde : identifiez le seul processus réel.

Lire la première erreur de chargement

Cherchez nom du monde, version de données, session lock, permissions, mods absents et exceptions sur level.dat ou les chunks. Le serveur peut échouer sur l'ancien monde, en créer un autre puis afficher « Done ». Sauvegardez la première erreur avant de relancer.

Si le monde vient d'une version plus récente, ne rétrogradez pas l'unique copie. Restaurez l'environnement adapté et testez un duplicata.

Corriger une seule copie privée

Dupliquez le monde avec un nom simple et ne corrigez que le fait démontré : couche en trop, transfert incomplet, level-name, dépendance ou chemin. Gardez la whitelist puis contrôlez log, spawn, constructions, dimensions et joueurs.

Arrêtez et redémarrez après une petite modification. Terrain proche ou même seed ne prouvent pas qu'il s'agit de la même sauvegarde.

Choisir la récupération selon les preuves

• Mauvais nom : corriger level-name en gardant les copies.
• Double dossier : placer la racine avec level.dat au bon niveau.
• Mauvaise instance : ajuster le processus ou sa racine documentée.
• Dépendance absente : reproduire la pile compatible.
• Dommage réel : restaurer un backup testé sous un autre nom.

Supprimer le nouveau monde ne force aucune détection ; Java peut le recréer et effacer l'indice principal.

Prévenir une nouvelle bascule silencieuse

Placez les backups hors de la racine active et testez les restaurations. Documentez level-name, racine, version, chargeur, mods et instance. Après migration, faites démarrage privé, contrôle des repères, arrêt propre et second démarrage.

Arrêter, copier, trouver la racine, vérifier nom et instance, lire le log puis tester un duplicata résout la majorité des cas sans détruire les données.