Server-Umzug zu einem anderen Hoster: Der richtige Ablauf

Irgendwann trifft es fast jeden Root-Server-Betreiber: Der aktuelle Hoster wird teurer, ein anderer Anbieter passt plötzlich besser, die Performance stimmt nicht mehr, oder der Vertrag läuft aus und du willst wechseln. Anders als die Ersteinrichtung ist ein Umzug kein rein technisches Problem, die Reihenfolge entscheidet, ob deine Community davon überhaupt etwas mitbekommt, oder ob ihr tagelang Verbindungsprobleme habt.

Bevor irgendetwas umzieht: die Kündigungsfrist

Der erste Fehler, der bei Umzügen am häufigsten passiert: den alten Vertrag zu früh kündigen, weil der neue Server ja schon „fertig eingerichtet" aussieht. Kündige erst, wenn der neue Server seit mehreren Tagen fehlerfrei läuft, nicht wenn er zum ersten Mal startet. Prüfe die Kündigungsfrist beim aktuellen Hoster vorab genau, monatliche vServer-Verträge sind meist unkompliziert, längerfristige Root-Server-Verträge oder Verträge mit Einrichtungsgebühr haben teils deutlich längere Fristen. Ein kurzer Zeitraum, in dem du für beide Server gleichzeitig zahlst, ist der mit Abstand günstigste Teil eines Umzugs, verglichen mit dem, was ein missglückter Umzug ohne Rückfallebene kosten kann.

Die Grundregel: erst parallel, dann umschalten, dann erst kündigen

Ein Umzug in einem einzigen Rutsch, alten Server abschalten, neuen Server hochfahren, ist der Ablauf, bei dem am meisten schiefgeht. Die deutlich robustere Reihenfolge:

1. Neuen Server komplett einrichten, inklusive Firewall, Server-Software und Konfiguration, während der alte Server unverändert weiterläuft.
2. Daten auf den neuen Server übertragen und dort gründlich testen, dazu gleich mehr.
3. Erst wenn der neue Server nachweislich funktioniert, den Umstieg für Spieler sichtbar machen (DNS oder direkte Adresse).
4. Alten Server noch einige Tage bis Wochen im Hintergrund laufen lassen, als Rückfallebene, bevor der Vertrag dort endet.

Diese Überlappung kostet ein paar Tage Doppelmiete, ist aber der Unterschied zwischen einem Umzug, den niemand bemerkt, und einem, der zum Community-Drama wird, weil mittendrin etwas nicht funktioniert und es keinen Weg zurück gibt.

DNS: der Teil, der am meisten Vorlauf braucht

Nutzt eure Community eine eigene Domain oder Subdomain statt der reinen IP-Adresse (etwa mc.eureseite.de), ist DNS der Schritt, den ihr am frühesten vorbereiten müsst, nicht am Tag des Umzugs selbst. Jeder DNS-Eintrag hat eine TTL (Time to Live), die angibt, wie lange Resolver weltweit ihn zwischenspeichern dürfen. Steht die TTL auf einem hohen Wert, etwa 24 Stunden, kann es nach der eigentlichen Umstellung noch einen ganzen Tag dauern, bis alle Spieler beim neuen Server landen, manche eher zufällig, je nachdem, wann ihr eigener DNS-Resolver zuletzt abgefragt hat.

Der praktische Ablauf:

1. TTL rechtzeitig senken, mindestens 24 bis 48 Stunden vor dem eigentlichen Umzug, auf einen niedrigen Wert wie 300 Sekunden (5 Minuten). Die neue, niedrige TTL muss sich erst selbst verbreiten, deshalb der Vorlauf.
2. A-Record erst ändern, wenn der neue Server steht und getestet ist. Mit vorher gesenkter TTL greift die Änderung bei den meisten Spielern dann innerhalb weniger Stunden statt Tage.
3. Geduld mit hartnäckigen Einzelfällen einplanen. Manche Internetanbieter und auch einzelne Browser ignorieren sehr niedrige TTL-Werte und cachen trotzdem länger, das lässt sich von eurer Seite aus nicht erzwingen, nur aussitzen.

Wer ausschließlich über die reine IP-Adresse spielt, ohne eigene Domain, kann diesen ganzen Abschnitt überspringen, muss dafür aber jedes Mal bei einem Hosterwechsel die neue IP manuell an alle Spieler kommunizieren, das ist der Trade-off, den eine eigene Domain gerade vermeidet.

Die eigentlichen Daten: Welt, Configs, und der Punkt mit dem gestoppten Server

Die Übertragung selbst läuft für die meisten Gameserver über rsync per SSH, direkt von Server zu Server, ohne Umweg über den eigenen PC:

rsync -avz --progress -e ssh /pfad/zum/server/ user@neue-server-ip:/pfad/zum/server/

Der Haken dabei, der leicht übersehen wird: Läuft der alte Server während der Übertragung weiter, schreibt er möglicherweise gerade in dem Moment in Welt- oder Datenbankdateien, in dem rsync sie liest, das Ergebnis sind im schlimmsten Fall korrupte Dateien auf der neuen Seite. Der sichere Ablauf: einmal den Server komplett synchronisieren, während er noch läuft (das kann bei großen Welten eine Weile dauern), danach den Server stoppen und einen zweiten, deutlich schnelleren rsync-Lauf machen, der nur noch die Änderungen seit dem ersten Durchlauf überträgt. Erst dieser zweite Lauf mit gestopptem Server liefert einen konsistenten Datenstand.

Läuft euer Server über ein Panel wie Pterodactyl, prüft vorher, ob euer Hoster oder das Panel selbst eine Transfer-Funktion zwischen Nodes anbietet, das übernimmt diesen Ablauf teilweise automatisiert, ist aber vom jeweiligen Hoster-Setup abhängig, nicht bei jedem Panel-Hosting gleich verfügbar.

Firewall und Absicherung: neu aufsetzen, nicht mitkopieren

Ein Punkt, der beim Umzug gerne vergessen wird: Die Firewall-Konfiguration des alten Servers 1:1 zu übernehmen, ist meistens keine gute Idee, unterschiedliche Hoster haben teils unterschiedliche Netzwerk-Setups, manche mit vorgeschalteter Cloud-Firewall im Kundenpanel, manche ganz ohne. Behandelt die Absicherung des neuen Servers als komplette Neueinrichtung, nicht als Kopiervorgang, dazu im Detail die Server-Hardening-Checkliste.

Steam-Tokens und Co.: was tatsächlich an die IP gebunden ist

Bei Valve-Spielen wie CS2 stellt sich beim Umzug fast automatisch die Frage, ob der Game Server Login Token (GSLT) neu erstellt werden muss. Die Antwort: nein. Der Token ist an deinen Steam-Account gebunden, nicht an die Server-IP. Historisch eingeführt wurde das System in erster Linie, um Bans von der IP-Ebene auf die Account-Ebene zu verlagern, davor traf eine gesperrte IP-Adresse bei Shared Hosting oft auch andere, unbeteiligte Kunden auf derselben Maschine. Dieselbe Account-Bindung sorgt als direkte Folge dafür, dass ein Server auch nach einem IP-Wechsel für Spieler, die ihn als Favorit gespeichert haben, derselbe Server bleibt. Mehrere unabhängige Hoster-Dokumentationen bestätigen das übereinstimmend, eine einzelne, abweichende Quelle mit einer angeblichen IP-Bindung dürfte schlicht falsch liegen. Schaden kann ein kurzer Blick in den Server-Browser nach dem Umzug trotzdem nicht.

Die Community informieren, zur richtigen Zeit

Kündigt den Umzug rechtzeitig an, mit Datum und ungefährer Downtime-Erwartung, über denselben Kanal, über den ihr sonst auch kommuniziert, ob Discord oder TeamSpeak. Legt den eigentlichen Umstellungstermin bewusst außerhalb der Zeiten, in denen üblicherweise am meisten los ist, ein Wochenendabend ist fast immer die falsche Wahl, ein Wochentag-Vormittag meistens die bessere.

Für die Wahl des neuen Hosters selbst, falls die noch aussteht, lohnt sich vorher ein Blick in die Hoster-Übersicht. Und sobald der Umzug ein paar Tage stabil gelaufen ist, ist das auch ein guter Zeitpunkt, die eigene Backup-Strategie direkt auf dem neuen Server einmal zu testen, statt sich darauf zu verlassen, dass sie schon noch genauso funktioniert wie vorher.