So ziehst du einen Minecraft-Server zu einem neuen Hoster um

Dein Server kann bis zum Umzugstag völlig in Ordnung aussehen, und dann verwandelt ein fehlender Plugin-Ordner, eine abweichende Java-Version oder eine vergessene Datenbank einen einfachen Umzug in ein Zurücksetzen. Die gute Nachricht: Zu lernen, wie du einen Minecraft-Server umziehst, ist vor allem Vorbereitung, keine komplizierten Befehle. Kopier die richtigen Dateien, erhalte den Software-Stack, teste, bevor du die neue IP verkündest, und deine Spieler merken den Umzug womöglich kaum.

Dieser Guide behandelt einen sicheren Umzug für Vanilla-, Paper-, Purpur-, Forge-, Fabric- und Plugin-lastige Community-Server. Er zeigt auch die Stellen, an denen nach dem Livegang des neuen Servers Inventare verloren gehen, Claims kaputtgehen, Mod-Items fehlen und TPS-Probleme entstehen.

Fang mit einem Umzugsplan an, nicht mit einer Dateiübertragung

Ein Minecraft-Server ist mehr als sein Welt-Ordner. Er ist eine Kombination aus Welt, Server-Software, Konfigurationsdateien, Plugins oder Mods, Spielerdaten und manchmal externen Datenbanken. Ist eines dieser Teile nicht synchron, können deine Spieler einem Server beitreten, der vertraut aussieht, aber fehlende Ränge, zurückgesetzte Quests oder kaputte Kontostände hat.

Halte vor dem ersten Schritt beim neuen Hoster dein aktuelles Setup fest: Minecraft-Version, Server-Jar und Build, Java-Version, RAM-Zuteilung, Start-Flags, installierte Plugins oder Mods und jede Proxy-Konfiguration wie BungeeCord oder Velocity. Mach Screenshots wichtiger Panel-Einstellungen, wenn dein alter Hoster ein eigenes Control-Panel nutzt.

Deine erste Entscheidung ist, ob es ein direkter Umzug oder gleichzeitig ein Upgrade ist. Ein direkter Umzug behält dieselbe Minecraft-Version, denselben Servertyp, dieselbe Java-Version und dieselben Inhalte. Das ist die risikoärmste Option. Ein Update von Paper 1.20.4 auf 1.21, das Ersetzen von Plugins oder ein Wechsel der Forge-Version kann sich lohnen, aber behandle das als eigenes Projekt, wenn der Server auf seiner neuen Hardware stabil läuft.

Mach ein letztes Backup und friere Änderungen ein

Automatische Backups sind ein Sicherheitsnetz, aber geh nicht davon aus, dass das neueste die letzten Minuten der Spieleraktivität enthält. Erstell direkt vor dem Umzug ein frisches manuelles Backup. Ist dein Server aktiv, plane ein kurzes Wartungsfenster und sag den Spielern genau, wann Bauen, Handeln und Inventaränderungen aufhören müssen.

Stopp den Server dann sauber über Panel oder Konsole. Beende ihn nicht einfach gewaltsam, während er Chunks speichert. Ein sauberes Herunterfahren schreibt Welt- und Spielerdaten ordentlich und senkt die Gefahr beschädigter Region-Dateien.

Bei einem Standardserver lädst du das komplette Server-Verzeichnis herunter oder kopierst es. Dazu gehören meist Ordner wie world, world_nether, world_the_end, plugins, mods, config und libraries sowie Dateien wie server.properties, ops.json, whitelist.json, banned-players.json, banned-ips.json, usercache.json und deine Server-Jar.

Hast du nur wenige eigene Einstellungen, ist es verlockend, nur die Welt umzuziehen. Tu es nicht. Eine vollständige Kopie gibt dir einen bekannten, funktionierenden Punkt zum Zurücksetzen und erhält die Details, die man leicht vergisst.

Prüf auf externe Datenbanken

Manche Plugins speichern Daten außerhalb ihres eigenen Ordners. Wirtschaft, Rechte, Web-Karten, Shop-Integrationen, Voting-Tools und serverübergreifende Systeme nutzen womöglich MySQL oder MariaDB statt SQLite-Dateien. plugins allein zu kopieren, überträgt diese Informationen nicht.

Exportier diese Datenbanken beim alten Hoster und importier sie dann in den neuen Datenbankdienst. Aktualisiere danach die Verbindungsdaten des Plugins. Ändern sich Hostname, Benutzername oder Passwort der Datenbank, startet das Plugin womöglich mit einem leeren Datensatz oder lädt nicht, bis seine Config korrigiert ist.

Prüf auch, ob du externe Dienste für Discord-Rollen, Zahlungs-Shops, Dynmap oder Backups nutzt. Diese Integrationen brauchen womöglich eine neue Server-IP, einen Port, eine Firewall-Regel oder einen Eintrag in einer API-Allowlist.

So ziehst du die Dateien deines Minecraft-Servers zum neuen Hoster um

Richte den Zielserver mit derselben Spielversion und Server-Software ein, bevor du Dateien hochlädst. Ein Paper-Server sollte zum Beispiel möglichst mit demselben Paper-Build starten, während ein Forge- oder Fabric-Server den passenden Loader und die passende Minecraft-Version braucht. Mit der falschen Jar zu starten, ist einer der schnellsten Wege, inkompatible Configs zu erzeugen oder beim Start abzustürzen.

Nutz den Dateimanager des Hosters, SFTP-Zugang oder einen Umzugsservice, um deine Dateien zu übertragen. Bei größeren Modpacks und großen Welten ist SFTP meist zuverlässiger als Uploads im Browser, besonders wenn du eine Übertragung fortsetzen musst. Behalte die Ordnerstruktur bei. Der Inhalt des Stammverzeichnisses deines alten Servers sollte im Stammverzeichnis des neuen Servers landen, nicht in einem zusätzlichen verschachtelten Ordner.

Bestätige nach dem Upload, dass das Wesentliche vorhanden ist:

• Jeder Welt-Ordner, inklusive Nether- und End-Dimension
• plugins und Plugin-Konfigurationsordner für Paper oder Purpur
• mods, config, defaultconfigs und kubejs, wo relevant, für Forge oder Fabric
• Spieler-, Whitelist-, Bann-, Operator- und Server-Einstellungsdateien
• Ressourcenpakete, Datapacks, Skripte und eigene Jars

Überschreib nicht blind vom Panel erzeugte Dateien, wenn dein neuer Hoster eine bestimmte Startkonfiguration vorgibt. Vergleiche sie zuerst. Name der Server-Jar, Startbefehl und zugeteilter Speicher müssen zu dem passen, was das Panel erwartet.

Gleiche Java, RAM und Starteinstellungen ab

Minecraft-Versionen haben Java-Anforderungen. Moderne Releases brauchen meist neuere Java-Versionen (Minecraft 26.x verlangt Java 25), während ältere Modpacks von Java 8 oder 17 abhängen können. Lief ein gemoddeter Server auf einer Java-Version und stürzt nach dem Umzug sofort ab, prüf das, bevor du annimmst, dass Dateien beschädigt wurden.

Der RAM sollte zur tatsächlichen Last passen, nicht nur zur Spielerzahl. Ein leichter Paper-SMP läuft womöglich gut mit einer bescheidenen Zuteilung und guter Single-Core-Leistung der CPU. Ein Forge-Modpack mit Hunderten Mods braucht mehr Speicher, aber mehr RAM allein behebt keine schlechte Tick-Leistung. CPU-Geschwindigkeit, Chunk-Generierung, Entity-Zahlen und Plugin-Effizienz zählen weiterhin.

Übernimm deine JVM-Flags nur, wenn du verstehst, warum sie da waren. Flags, die einem älteren Java-Build geholfen haben, sind auf einer neueren Laufzeit womöglich unnötig oder kontraproduktiv. Fang mit vernünftigen Standardwerten an, wenn dein neuer Hoster die Java-Einstellungen verwaltet, und stimm erst nach, wenn du echte TPS- und Speicherdaten hast.

Hier zählt auf Minecraft ausgerichtete Infrastruktur. Schnelle Ryzen- oder EPYC-Kerne helfen dem Haupt-Thread des Servers mitzuhalten, während NVMe-Gen4-Speicher den Schmerz beim Laden und Speichern von Chunks reduziert. Hardware rettet kein kaputtes Plugin, gibt einem gesunden Server aber Raum für Leistung.

Mach einen privaten Test, bevor du die Türen öffnest

Starte den umgezogenen Server mit aktivierter Whitelist. Beobachte die Konsole vom ersten Start bis zum vollständigen Laden der Welt. Ein paar Warnungen können normal sein, aber wiederholte Fehler, Meldungen über fehlende Abhängigkeiten, fehlgeschlagene Datenbankverbindungen oder Registry-Abweichungen brauchen Aufmerksamkeit, bevor Spieler beitreten.

Tritt mit einem Test-Account bei und prüf mehr als den Spawn. Reise durch Oberwelt, Nether und End. Öffne Inventare und Endertruhen. Teste Claims, Ränge, Homes, Warps, Shops, Crates, Quests, Minispiel-Arenen und alle Befehle, die deine Community täglich nutzt. Auf einem gemoddeten Server prüfst du, ob gemoddete Blöcke, Maschinen, Dimensionen und Spielerinventare korrekt laden.

Prüf dann die Leistung unter realistischen Bedingungen. Nutz deinen üblichen Profiler oder die Server-Diagnose, um TPS, MSPT, Speicherverbrauch und CPU-Verhalten zu prüfen. Frische Hardware kann einen Server schneller wirken lassen, aber neue Chunk-Generierung bleibt anspruchsvoll. Werden Spieler nach dem Start einen neuen Kartenbereich erkunden, kann das Vorgenerieren von Chunks verhindern, dass die ersten Sessions zu einem TPS-Test werden, um den niemand gebeten hat.

Betreibst du ein Netzwerk, teste die Proxy-Weiterleitung sorgfältig. BungeeCord, Velocity, Backend-Server, Firewall-Regeln, Forwarding-Secrets und online-mode-Einstellungen müssen übereinstimmen. Eine kleine Abweichung kann doppelte UUIDs, fehlgeschlagene Logins oder Spieler ohne ihre erwarteten Daten verursachen.

Wechsle die Adresse erst, wenn der Test bestanden ist

Ist der private Test sauber, aktualisiere deine Domain oder teile die neue IP und den Port mit den Spielern. Dieselbe Domain zu behalten, ist für eine Community am einfachsten, weil niemand seine Serverliste bearbeiten muss. DNS-Änderungen können Zeit brauchen, bis sie alle erreichen, also lass den alten Server nach dem letzten Backup offline, statt die Spieler ihre Aktivität auf zwei Welten aufteilen zu lassen.

Behalte die alten Server-Dateien und das letzte Backup mindestens einige Tage. Kündige den bisherigen Dienst nicht in der Minute, in der der neue Server öffnet. Diese kurze Überschneidung gibt dir einen Rettungsweg, falls du in der ersten vollen Session eine fehlende Datenbanktabelle oder ein Config-Problem entdeckst.

Für Admins, die von einem Hoster mit langsamem Speicher, unklarem Support oder einem Panel wegziehen, das jede Änderung riskant wirken lässt, kann sich ein begleiteter Umzug lohnen. Elysium kann helfen, die Dateien zu übertragen und die Umgebung zu prüfen, aber du solltest trotzdem wissen, was übertragen wird, und dein eigenes Backup behalten. Deine Welt ist zu wertvoll, um sie einer einzigen Kopie anzuvertrauen.

Ein guter Umzug ist nicht aufregend, und genau darum geht es. Spieler loggen sich ein, finden ihre Bauwerke, behalten ihre Inventare und spielen weiter, während du einen stabilen TPS-Graphen beobachtest statt Konsolenfehlern im Notfall.