Checkliste für den Umzug deines Minecraft-Hostings: umziehen, ohne Fortschritt zu verlieren

Deinen Spielern ist egal, dass du den Hoster gewechselt hast. Ihnen ist wichtig, dass ihre Bauwerke laden, ihre Inventare intakt sind und der Server zur versprochenen Zeit öffnet. Deshalb zählt eine Checkliste für den Umzug deines Minecraft-Hostings: Der riskante Teil ist selten das Kopieren der Dateien. Sondern die richtigen Dateien umzuziehen, die Versionskompatibilität zu erhalten und zu testen, bevor deine Community das Problem zuerst findet.

Ein guter Umzug sollte sich langweilig anfühlen. Deine Welt geht online, die TPS bleiben gesund, Plugins oder Mods verhalten sich normal, und niemand verliert eine Woche Fortschritt. So erreichst du das, ohne den Tag der Serverübertragung in einen Notfall zu verwandeln.

Fang mit einem sauberen Umzugsfenster an

Fang nicht damit an, Ordner in ein neues Control-Panel zu ziehen. Leg zuerst fest, wann der alte Server keine Änderungen mehr annimmt. Jede Spieleraktivität nach deinem letzten Backup kann fehlende Inventardaten, zurückgesetzte Claims oder eine Welt erzeugen, die nicht mehr zu ihrer Datenbank passt.

Kündige ein Wartungsfenster an und stopp den Server dann sauber über das Panel. Vermeide ein gewaltsames Beenden, es sei denn, er ist eingefroren. Ein normales Herunterfahren gibt Paper, Purpur, Forge, Fabric und Plugins Zeit, Spielerdaten zu schreiben und Chunks zu speichern.

Halte vor dem Herunterfahren die Grundlagen deines aktuellen Setups fest: Minecraft-Version, Server-Software und Build, Java-Version, zugeteilten RAM, Startbefehl, Port und aktive Plugins oder Mods. Das dauert fünf Minuten und erspart später viel Raten. Ein Paper-Server auf 1.21.x ist nicht automatisch mit einem zufälligen neueren Paper-Build kompatibel, und Modpacks können noch weniger nachsichtig sein.

Was du sichern solltest

Dein ganzes Server-Verzeichnis ist der sicherste Ausgangspunkt. Lad es als Archiv herunter, wenn dein aktueller Hoster das erlaubt, oder nutz SFTP, um es lokal zu kopieren, bevor du es auf den neuen Server hochlädst. Bewahr eine zweite Kopie irgendwo außerhalb beider Hosting-Konten auf, bis der Umzug mehrere Tage stabil läuft.

Bei den meisten Servern beschränken sich die wichtigen Dateien nicht auf den Haupt-Welt-Ordner. Du brauchst die Welt und ihre Dimensionen, Konfigurationsdateien, Rechte, Spielerdaten, Plugin-Daten und alle externen Datenbanken, die dein Setup nutzt. Betreibst du BungeeCord oder Velocity, brauchen Proxy-Konfiguration und Backend-Server-Einstellungen eine eigene Prüfung.

Bestätige mindestens, dass dein Backup diese einzelnen Teile enthält:

• Deinen Haupt-Welt-Ordner plus die Nether- und End-Ordner, wenn sie separat gespeichert sind
• plugins, mods, config, defaultconfigs und alle eigenen Datapack-Ordner
• server.properties, eula.txt, ops.json, whitelist.json, banned-players.json und banned-ips.json
• Spielerdaten, inklusive Inventare, Endertruhen, Fortschritte, Statistiken und Plugin-spezifische Daten
• Datenbanken wie MySQL- oder SQLite-Dateien, die von Claims, Wirtschaft, Rechten, Shops oder Web-Karten genutzt werden

Geh nicht davon aus, dass jedes Plugin seine Daten in seinem eigenen Ordner hält. LuckPerms nutzt womöglich MySQL. CoreProtect nutzt oft eine Datenbank. Ein Claims-Plugin kann Grundbesitz in SQLite oder MySQL speichern. Ziehst du nur die sichtbaren Plugin-JARs um, startet der Server womöglich normal, während deine Ränge, Logs, Homes oder Claims scheinbar verschwinden.

Gleiche die Software ab, bevor du etwas hochlädst

Der neue Hoster sollte zuerst dieselbe Minecraft-Version und dieselbe Software-Familie ausführen. Zieh von Paper zu Paper, von Forge zur selben Forge-Version oder von Fabric zum selben Fabric-Loader und derselben Minecraft-Version um. Aktualisieren kannst du später, wenn der Umzug geprüft ist. Einen Hoster-Umzug mit einem großen Spiel-Update zu kombinieren, ist der Weg, auf dem einfache Fehlersuche zu einem Dutzend möglicher Ursachen wird.

Java gehört zu dieser Kompatibilitätsprüfung. Moderne Minecraft-Versionen brauchen meist neuere Java-Releases, während ältere Forge-Modpacks womöglich von einer bestimmten Version abhängen. Startet dein alter Server mit eigenen JVM-Flags, speicher sie. Manche Flags verbessern das Verhalten der Garbage Collection, aber jedes alte Flag blind mitzunehmen, ist nicht immer klug. Gute Ryzen- oder EPYC-CPU-Leistung und schneller NVMe-Speicher helfen bei Chunk-Generierung und TPS, aber falsches Java oder eine kaputte Mod-Abhängigkeit können einen Server trotzdem eiskalt stoppen.

Prüf deine Tarif-Ressourcen ehrlich. Lief der alte Server regelmäßig bei 85 bis 95 Prozent RAM-Verbrauch, lässt ein Umzug auf dieselbe Speichermenge keinen Raum zum Wachsen — der RAM-Rechner hilft dir, eine Größe mit Reserve zu wählen. Andererseits behebt eine riesige RAM-Zuteilung kein Plugin, das in jedem Tick eine teure Aufgabe ausführt. Bei SMPs beeinflussen Single-Core-Geschwindigkeit der CPU, saubere Configs, view-distance, simulation-distance und Plugin-Qualität alle das Erlebnis.

Hochladen und dann die Dateistruktur prüfen

Stell den richtigen Servertyp im Panel deines neuen Hosters bereit, bevor du Dateien hochlädst. Ist die erste Installation abgeschlossen, stopp ihn. Lad dann dein Backup über den Dateimanager oder SFTP hoch.

Pass auf, keine zusätzliche Ordnerebene zu erzeugen. Ein häufiger Fehler sieht so aus: Das Stammverzeichnis des Servers im Panel enthält einen Ordner namens my-server-backup, und die eigentlichen Ordner server.jar, world und plugins stecken darin fest. Der Server generiert dann entweder eine frische leere Welt oder schlägt fehl, weil er die erwarteten Dateien nicht findet. Prüf auch, ob level-name in server.properties zum Namen deines Welt-Ordners passt.

Bietet dein Hoster automatische Backups, aktivier sie vor dem ersten Produktionsstart. Das ist nicht übertrieben. Es gibt dir einen Wiederherstellungspunkt nach dem Upload und bevor jemand beitritt. Elysium ist um genau diese Art reibungsarmer Einrichtung gebaut: schneller NVMe-Speicher, verwaltete Minecraft-Bereitstellungen und automatische Backups nehmen dir viel langweilige Infrastrukturarbeit ab, aber die Daten, die du mitbringst, musst du trotzdem prüfen.

Teste privat, bevor du die Türen öffnest

Starte den Server mit aktivierter Whitelist. Tritt mit einem Admin-Account bei und teste die Teile des Servers, die Spieler sofort bemerken. Prüf deinen Spawn, ein paar weit entfernte Basen, Netherportale, das End, Spielerinventare, Ränge, Homes, Claims, Shops und jede Aufforderung für Ressourcenpakete.

Beobachte die Konsole beim Start. Warnungen sind nicht immer fatal, aber wiederholte Fehler verdienen Aufmerksamkeit. Fehler wegen fehlender Abhängigkeiten, fehlgeschlagene Datenbankverbindungen, inkompatible Plugin-APIs oder Registry-Abweichungen bei Mods sollten vor dem öffentlichen Start behoben sein. Ignorier eine rote Konsole nicht, nur weil der Server dich verbinden lässt.

Prüf dann die Leistung unter realistischen Einstellungen. Lauf durch neues Gelände, teleportier zwischen Welten, löse häufig genutzte Befehle aus und beobachte TPS und Speicherverbrauch. Fallen die TPS direkt nach dem Umzug, vergleiche server.properties, Paper- oder Purpur-Configs, Java-Version und view-distance-Einstellungen mit der alten Umgebung. Womöglich ist es ein Konfigurationsunterschied statt eines Hosting-Problems.

Lass auf gemoddeten Servern mindestens einen Spieler mit genau dem Modpack testen, das deine Community nutzt. Ein Server kann starten, während ein fehlender, clientseitig erforderlicher Mod Spieler am Beitritt hindert. Teste auf öffentlichen Servern Proxy-Routing, Forced Hosts, Forwarding-Secrets und Backend-IP-Einstellungen, bevor du DNS änderst oder eine neue Adresse bewirbst.

Schalte um, ohne Spieler zu verwirren

Bestehen die Tests, entscheide, ob du eine letzte Synchronisierung brauchst. Durften Spieler während der Tests zurück auf den alten Server, fahr ihn erneut herunter und kopier alle geänderten Welt- und Spielerdaten vom alten Server. Blieb er offline, bleibt deine ursprüngliche Übertragung die maßgebliche Quelle.

Aktualisiere deine Domain oder Serveradresse erst, wenn der neue Server bereit ist. Ändert sich dein DNS-Eintrag, denk daran, dass manche Spieler wegen Caching kurz die alte Adresse erreichen können. Halte den alten Server in dieser Zeit offline. Zwei Live-Kopien derselben Welt laden zu gespaltenem Fortschritt und Support-Kopfschmerzen ein — unser Guide zum Hoster-Wechsel ohne Ausfallzeit behandelt das Umschalten ausführlicher.

Lass die Whitelist in den ersten Minuten des öffentlichen Zugangs an, wenn du einen Ansturm erwartest. Beobachte Konsole, TPS, RAM und Verbindungsfehler. Öffne dann den Server und bleib erreichbar. Eine schnelle Reaktion auf einen fehlenden Rang oder einen fehlgeschlagenen Claim schafft mehr Vertrauen, als so zu tun, als hätten Umzüge nie Sonderfälle.

Behalte den Rückweg, bis sich der Server bewährt hat

Lösch das alte Hosting-Konto oder das lokale Backup nicht in dem Moment, in dem sich Spieler einloggen. Behalte die Originaldateien und dein letztes Backup vor dem Umzug mindestens über mehrere normale Spielsitzungen. Gib den Leuten Zeit, entfernte Basen zu besuchen, seltener genutzte Befehle zu verwenden und Daten zu bemerken, die an Plugins hängen, die sie nur gelegentlich nutzen.

Stimmt etwas nicht, widersteh dem Drang, Dateien zu überschreiben, während Spieler online sind. Stopp den Server, mach ein frisches Backup seines aktuellen Zustands, finde die fehlende Komponente und stell nur das Nötige wieder her — der Guide zur Backup-Wiederherstellung führt durch eine sichere teilweise Wiederherstellung. Ein sauberer Rückweg verwandelt ein Umzugsproblem in Wartung. Kein Plan verwandelt es in verlorenen Fortschritt.

Das Ziel ist kein dramatischer Umzug zu einem neuen Hoster. Sondern ein Server, der sich genau wie zu Hause anfühlt, wenn deine Spieler beitreten — nur schneller, stabiler und viel leichter zu betreiben.