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.
Confirmer l’édition Bedrock et les versions
Utilisez Bedrock Dedicated Server et relevez versions exactes du serveur et des clients. Mondes, plugins et permissions Java et Bedrock ne sont pas interchangeables. Une conversion ou un proxy est un projet distinct ; ce guide ne promet pas le chargement d’un monde Java sous Bedrock.
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.
- Bedrock Dedicated Server
- server / client versions
- Java ≠ Bedrock
Retrouver le monde sélectionné
Lisez level-name dans le véritable server.properties et retrouvez ce monde sous worlds. Incluez tous ses fichiers de base de données et packs de ressources ou de comportement nécessaires. Une copie de la base active ne prouve pas sa cohérence : arrêtez les écritures et conservez l’original complet.
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
- worlds/
- world database
- resource_packs/ / behavior_packs/
Conserver les réglages d’accès et permissions
Préservez allowlist.json, permissions.json, les réglages utiles de server.properties et dépendances des packs. Vérifiez permissions par défaut et allow-list. Exportez séparément outils externes, proxy et éventuelles bases. whitelist.json et ops.json de Java ne remplacent pas ces fichiers Bedrock.
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.
- allowlist.json
- permissions.json
- allow-list
- default-player-permission-level
Restaurer une copie complète et stable
Sauvegardez après un arrêt propre, préservez l’original et restaurez sur une version identique. Comparez tailles et sommes de contrôle de l’archive puis testez le monde en privé. Une mise à niveau peut convertir les sauvegardes : conservez une récupération correspondant à la version initiale.
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 stop
- stable archive
- matching server version
- private restore
Tester packs et ports UDP du jeu
Connectez un client compatible et vérifiez monde, permissions, packs et progression sauvegardée après redémarrage. Contrôlez les ports UDP attribués. Les valeurs par défaut Bedrock sont 19132 pour IPv4 et 19133 pour IPv6, mais allocation et configuration réelles prévalent ; un test TCP ne valide pas UDP.
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.
- UDP · server-port
- UDP · server-portv6
- client / pack compatibility
- save + restart
Publier la nouvelle adresse et surveiller
Communiquez adresse Bedrock et port UDP attribués, tenez compte des restrictions des clients et plateformes, et vérifiez les DNS utilisés. Ne supposez pas que tous les clients Bedrock gèrent les SRV Java. Surveillez connexions et persistance ; réconciliez les nouvelles écritures avant un retour arrière.
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 address + UDP port
- client platform restrictions
- persistence
- rollback
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.