Trasferire un server Minecraft Java su un nuovo hosting senza perdere progressi

Migrare un server Java significa trasferire terreno, inventari, dimensioni, permessi, plugin, mod e identità dei giocatori come un unico stato. Il vecchio hosting deve restare spento ma disponibile per il rollback finché il nuovo non supera un collaudo privato completo.

Fai l'inventario prima della manutenzione

Annota Minecraft, Java, software e build server, loader, mod, plugin, datapack, memoria, argomenti, porta, online-mode, proxy e impostazioni del pannello. Elenca ogni mondo e dimensione: Paper, multiworld e mod possono usare strutture diverse.

Registra indirizzo pubblico, DNS e porta. Trasforma economia, claim, home e permessi in verifiche concrete.

Crea un backup autorevole a server spento

Annuncia la manutenzione, blocca gli ingressi, salva se necessario ed esegui stop. Archivia l'intera directory solo dopo la chiusura. Conserva il file fuori da entrambi gli hosting, annota la dimensione e confronta gli hash quando possibile.

Non disdire né riaprire il vecchio servizio. Una copia a caldo può combinare momenti diversi.

Prepara una destinazione compatibile

Installa le stesse versioni di Java, server, loader, mod e plugin. Passando fra Vanilla, Spigot, Paper, Fabric o Forge, segui il layout documentato dal software di destinazione. Avvia a vuoto solo se il pannello deve creare la struttura, poi arresta e archivia i file di prova.

Controlla spazio, proprietario, comando, porta e vera radice. Un upload corretto nell'istanza sbagliata sembra un upload mancante.

Trasferisci mondi, identità e impostazioni insieme

Carica ed estrai lo snapshot con il metodo supportato. Verifica level-name, mondo principale, Nether, End, giocatori, progressi, statistiche, datapack, whitelist, ban, operatori, permessi e database plugin.

Non pubblicare password o chiavi nell'archivio; ruota ciò che è stato esposto. Mantieni coerenti online-mode e inoltro identità del proxy, altrimenti un UUID nuovo sembra perdita di inventario.

Collauda su un indirizzo privato

Non cambiare ancora il DNS. Limita l'accesso con whitelist o indirizzo temporaneo e leggi tutto l'avvio. Correggi dipendenze, versioni e permessi. Prova con amministratore e utente normale spawn, costruzioni, dimensioni, inventari, economia, claim, portali e comandi.

Fai una modifica, arresta e riavvia. Una sola connessione riuscita non prova il salvataggio persistente.

Effettua il passaggio con un solo server scrivibile

Dopo l'approvazione, lascia spento il vecchio e cambia DNS, proxy o indirizzo. Non aprire entrambe le copie: i progressi divergono subito e non esiste una fusione generale sicura.

Sorveglia log e connessioni nella prima sessione. La cache DNS può portare alcuni utenti al vecchio host. Mantieni backup e servizio precedente fino a un vero riavvio e alla verifica delle automazioni.

Esegui il rollback come operazione completa

Se la destinazione rovina dati o non esegue lo stack, fermala prima. Il ritorno pulito ripristina lo snapshot autorevole sul vecchio host e riporta l'indirizzo, invece di scambiare file singoli nelle due direzioni.

Documenta errore e test fallito. Cambiare contemporaneamente versione, layout e file nasconde la causa.

Criteri di completamento

• Ambiente, mondi e pannello sono inventariati.
• L'archivio nasce da un arresto pulito ed è conservato altrove.
• La destinazione replica lo stack o segue un percorso documentato.
• Mondi, identità, permessi e impostazioni viaggiano insieme.
• Il test privato copre log, giocatori, dimensioni, salvataggio e riavvio.
• Durante il passaggio scrive un solo server pubblico.
• Il vecchio host resta disponibile nel periodo di rischio.

La migrazione termina quando la storia della comunità continua ed esiste un ritorno verificato, non quando il pannello nuovo diventa verde.