Für einen kontrollierten Hosterwechsel erfasst du die vollständige Einrichtung, sicherst Welt und Spielerdaten, testest eine getrennte Zielkopie und stellst erst danach die Adresse um. Behalte die bisherige Installation als Rückweg. Ändere beim Umzug nicht gleichzeitig Minecraft-Version, Server-Software und Modpack: Sonst wird unklar, ob ein Fehler von der Übertragung oder von einer Versionsänderung stammt.
Vor dem Kopieren den kompletten Stand erfassen
Schreibe auf, welche Version auf dem alten Server wirklich läuft. Notiere Minecraft-Version, Server-Software samt Build, Java-Version, Startdatei und Startparameter. Bei einem Modpack gehören auch Loader-Version und genaue Pack-Version dazu. Erstelle dazu eine Liste der Plugins oder Mods, ihrer Abhängigkeiten, Datapacks und Konfigurationsordner. Die Software-Übersicht hilft, wenn du erst klären musst, ob du Paper, Fabric oder NeoForge betreibst.
Inventarisiere danach die Dateien und Einstellungen:
- Weltordner und Weltnamen aus
server.properties; prüfe auch Nether, Ende und weitere Dimensionen sowieplayerdata,advancementsundstats. server.properties,eula.txt,whitelist.json,ops.json,banned-players.jsonundbanned-ips.json.plugins,mods,config,datapacks,libraries, Loader- und Startdateien sowie plugin- oder mod-eigene Datenbanken.- Zeitpläne, automatische Neustarts, Backup-Aufträge, Resourcepack-URLs, Port und Netzwerkzuweisung.
- Authentifizierung und Netzwerkweg:
online-mode, gegebenenfalls Velocity oder BungeeCord, Weiterleitungsmodus und die Stelle, an der ein Weiterleitungs-Secret sicher hinterlegt ist.
Das ist besonders wichtig, wenn du nicht Vanilla einsetzt. Paper dokumentiert, dass ein Wechsel der Server-Software die Weltablage verändern kann und Paper keine Fabric- oder Forge-Mods lädt. Führe so einen Plattformwechsel deshalb als eigenes Projekt mit eigener Prüfung durch, statt ihn in den Hosterwechsel zu mischen (PaperMC: Migration zu oder von Paper). Für Fabric gehören zum manuellen Serveraufbau je nach Installationsart unter anderem Launcher, server.jar, server.properties und libraries; die gewählte Minecraft- und Loader-Version ist beim ausführbaren Server-Launcher mit festgelegt (Fabric Wiki: Installing Fabric). Bei NeoForge solltest du zusätzlich Startskript und user_jvm_args.txt erfassen (NeoForged: Installing a NeoForge Server).
Eine getrennte Zielkopie aufbauen und prüfen
Erstelle zuerst ein vollständiges Backup, das sich öffnen oder auf einer Testkopie wiederherstellen lässt. Kopiere die inventarisierten Dateien zum neuen Hoster und vergleiche die übertragenen Ordner und Dateien mit deiner Liste. Wenn dein Übertragungswerkzeug Prüfsummen anbietet, vergleiche sie für Weltarchive und grosse Dateien; sonst prüfe mindestens, ob Archive lesbar sind und erwartete Ordner und Dateien vorhanden sind. Für den Dateiwechsel hilft die Anleitung Gameserver-Dateien sicher mit SFTP übertragen.
Starte die Zielkopie zunächst ohne öffentlichen Spielerzugang. Nutze dieselbe Minecraft-Version, Server-Software, Loader-Version, Java-Laufzeit und dieselben Erweiterungen wie auf dem alten Server. Prüfe das Startprotokoll auf fehlende Dateien, inkompatible Erweiterungen und Fehler beim Laden der Welt. Verbinde dich mit einem Testkonto und kontrolliere bekannte Bauwerke in mehreren Dimensionen, Inventar, Endertruhe, Berechtigungen, Whitelist sowie die wichtigsten Plugin- oder Mod-Funktionen. Stelle sicher, dass ein Port oder eine Netzwerkzuweisung beim neuen Hoster korrekt eingerichtet ist. Einen Server, der dieselbe Welt enthält, darfst du nicht parallel öffentlich bespielen lassen.
Spieleridentität beim Wechsel erhalten
Übertrage die Spielerdaten und Listen unverändert. Schalte online-mode nicht pauschal als Fehlerumgehung ab. Bei unterstützten Paper-Versionen hinter Velocity mit modernem Forwarding ist online-mode=false im Backend laut PaperMC nötig, weil Velocity die Anmeldung übernimmt. Forwarding-Modus und Secret müssen passend konfiguriert sein; bewahre das Secret geschützt auf und sichere den Backend-Port zusätzlich per Firewall so ab, dass nur der Proxy zugreifen kann. PaperMC empfiehlt eine Firewall für Proxy-Setups; modernes Forwarding ersetzt sie nicht. BungeeCord-kompatibles Legacy-Forwarding gilt laut Doku als unsicher (PaperMC: Player Information Forwarding, PaperMC: Securing your servers). Bei anderen Proxy-/Server-Kombinationen prüfe deren aktuelle Anleitung. Teste vor dem Umstellen mit einem bekannten Spielerkonto, ob Inventar, Rechte und Whitelist-Zuordnung stimmen.
Den Cutover koordinieren und den alten Server behalten
Lege mit der Gruppe ein Wartungsfenster fest. Die Testkopie ist nur eine Probe; unmittelbar vor dem Wechsel bleibt die bisherige Welt die führende Version. Stoppe den alten Server sauber, erstelle einen letzten vollständigen Stand und übertrage diesen konsistent zum Ziel. Wenn du vorab kopiert hast, synchronisiere die Änderungen seit der Testkopie nur mit einem Verfahren, das du sicher bedienen kannst; andernfalls übertrage den finalen gestoppten Stand vollständig. Prüfe danach nochmals die Weltordner und Konfiguration.
Starte nun den neuen Server allein. Kontrolliere Konsole und Logs, verbinde dich selbst und prüfe Welt, Inventar, Berechtigungen sowie Erweiterungen erneut. Ändere erst dann die Adresse: Bei direktem Zugang DNS-Ziel und gegebenenfalls Port, bei einem Proxy dessen Backend-Ziel. Kommuniziere den neuen Hostnamen und Port an die Gruppe. Den alten Server lässt du gestoppt und unverändert stehen, statt ihn parallel weiterlaufen zu lassen.
Falls der neue Server vor dem ersten Spielereintritt scheitert, kannst du den Zugang zurück auf den alten Stand lenken. Haben auf dem Zielserver bereits Spieler gebaut oder Gegenstände verändert, schalte nicht einfach die alte Kopie wieder frei: Stoppe zuerst das Ziel und sichere oder übertrage dessen neue Daten, sonst entstehen zwei auseinanderlaufende Welten. Behalte den alten Stand, bis die Gruppe auf dem Zielserver spielen konnte und die wichtigsten Funktionen geprüft sind. Bei Startfehlern hilft die Fehler-Checkliste.