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.
Identifier la distribution du serveur
Relevez versions Minecraft et Java, distribution Vanilla/Paper/Purpur ou Forge/Fabric/NeoForge, version exacte du chargeur et du modpack, options JVM et démarrage personnalisé. Vérifiez les prérequis de cette version. Séparez migration et mise à niveau pour mieux isoler les erreurs.
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.
- Minecraft version
- Java runtime
- Paper / Purpur
- Forge / Fabric / NeoForge
Retrouver tous les mondes et dimensions
Lisez level-name et l’organisation effective de votre distribution. Paper peut séparer Nether et End de manière différente de Vanilla ; les dimensions modifiées peuvent utiliser d’autres chemins. Sauvegardez tous les mondes réels, données joueurs, progrès et datapacks. Ne fusionnez pas aveuglément world_nether, world_the_end ou DIM-1/DIM1 ; suivez la conversion documentée sur une copie.
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.
- server.properties · level-name
- world / world_nether / world_the_end
- DIM-1 / DIM1 · distribution-dependent
- playerdata / advancements / datapacks
Préserver permissions, plugins et mods
Conservez server.properties, configuration, whitelist.json, ops.json, bannissements, permissions et données des plugins. Un JAR de plugin ne contient pas son dossier de données. Gardez mêmes versions, dépendances et licences. Exportez séparément les bases SQL externes des plugins et recréez uniquement les privilèges utiles.
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.
- whitelist.json / ops.json
- plugins/ + plugin data
- mods/ + config/
- external SQL
Sauvegarder après un arrêt propre
Prévenez les joueurs et arrêtez proprement la source avant la copie finale des mondes. Un monde actif change pendant l’export. Conservez une archive datée de tous les dossiers nécessaires et un original indépendant. Testez la restauration et l’espace temporaire : un téléchargement réussi ne prouve pas que toutes les dimensions sont présentes.
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.
- clean server stop
- complete archive
- independent original
- restore test
Restaurer en privé et tester la persistance
Installez distribution et environnement compatibles avant de restaurer : un installateur lancé ensuite peut écraser les fichiers. Lisez les journaux, connectez le bon client/modpack et vérifiez toutes les dimensions, inventaires, permissions et données des plugins. Sauvegardez, arrêtez puis redémarrez proprement. Gardez l’authentification des comptes pour un serveur public.
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.
- Overworld / Nether / End
- matching client and modpack
- permissions / inventories
- save + restart
Changer l’adresse après validation
Utilisez le port TCP attribué, qui n’est pas nécessairement 25565. Pour un domaine, vérifiez A/AAAA et SRV Java ; SRV ne remplace ni le routage ni l’ouverture du port réel. Annoncez la nouvelle adresse, surveillez connexions et sauvegardes et conservez les données de retour arrière avant résiliation.
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.
- assigned TCP port
- A / AAAA / SRV
- player joins
- backup retention
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.