Minecraft-Server umziehen: DNS umstellen und Spielbetrieb freigeben

Ein Minecraft-Server kann beim Umzug seine bekannte Adresse behalten: Bereitet zuerst das Ziel vor, beendet Schreibzugriffe auf dem alten Server, übertragt einen abschließenden konsistenten Datenstand und schaltet danach den Verbindungsweg um. Die alte Welt bleibt für Spieler geschlossen. Eine DNS-Änderung weist einem Namen ein anderes Ziel zu; sie synchronisiert keine zwei weiterlaufenden Weltkopien.

Dieser Ablauf richtet sich an etablierte Communities, die mit einem Java-Server den Hoster wechseln. Er setzt voraus, dass ihr den öffentlichen Hostnamen kontrolliert und ein Wartungsfenster vereinbaren könnt. Die Schritte sind ein vorgeschlagener Betriebsablauf, kein auf eurer Infrastruktur getesteter Umzug. Bedrock-Zugänge, Crossplay und zusätzliche Dienste brauchen eigene Verbindungstests.

Den tatsächlichen Verbindungsweg erfassen

Beginnt mit dem gespeicherten Servereintrag eines regulären Teilnehmers. Notiert Hostname, gegebenenfalls ausdrücklich angegebenen Port, öffentlichen Einstiegspunkt und den Rechner, auf dem die Welt liegt. Bei einem Proxy müsst ihr dessen öffentliche Adresse von den privaten Backend-Zielen unterscheiden. Zieht nur ein Backend um und bleibt der Proxy bestehen, ist möglicherweise keine öffentliche DNS-Änderung nötig.

Prüft die gesamte DNS-Kette. A- und AAAA-Einträge liefern IPv4- beziehungsweise IPv6-Adressen; ein CNAME verweist auf einen weiteren Namen. Kontrolliert beide Adressfamilien, damit beim Wechsel von IPv4 keine alte IPv6-Verbindung unbemerkt bestehen bleibt. Die Referenz zu DNS-Eintragstypen erläutert diese Unterschiede.

Nutzt der bestehende Zugang einen SRV-Eintrag, erfasst dessen Ziel und Port sowie die Adresseinträge des Zielnamens. SRV ist ein eigener Diensteintrag. Sein Ziel muss Adresseinträge besitzen und darf kein Alias sein; das legt RFC 2782 fest. Behaltet den bisherigen Verbindungsaufbau bei, sofern dessen Änderung nicht ausdrücklich zum geprobten Umfang gehört.

Legt fest, wer DNS ändert und wer am Ziel bestätigt, welcher Server die Testverbindung erhalten hat. Sichert die bisherigen Eintragswerte im Änderungsprotokoll. Verbindet den Umzug nicht zusätzlich mit einem Registrarwechsel, einer neuen Authentifizierung oder einem Minecraft-Upgrade.

DNS-Caches vor dem Wartungsfenster vorbereiten

Die TTL legt fest, wie lange eine DNS-Antwort zwischengespeichert werden darf. Wird sie erst beim Umzug gesenkt, ersetzt das keine Antworten, die bereits mit der alten TTL im Cache liegen. RFC 1034 beschreibt dieses Cache-Verhalten.

Ein erfundenes Planungsbeispiel: Die zu ändernden Einträge haben eine TTL von 3.600 Sekunden. Senkt die betreffenden TTLs mindestens eine Stunde vor dem Zielwechsel auf 300 Sekunden und plant zusätzliche Reserve ein. Prüft dabei auch SRV-Ziele oder Aliasse, die sich ändern. Diese Zahlen veranschaulichen die Planung; sie versprechen nicht, dass nach fünf Minuten sämtliche Spieler den neuen Server erreichen. Auch die TTL-Dokumentation von Cloudflare weist auf mögliche Verzögerungen durch lokale Caches hin.

Legt neue Zielnamen frühzeitig an und prüft sie vor dem Wartungsfenster. Einen neuen Namen hinzuzufügen ist ein anderer Fall als einen bestehenden Eintrag zu ändern: Auch eine frühere negative Antwort kann im Cache liegen. Ein abgelaufener Countdown ist deshalb kein ausreichendes Freigabekriterium.

Verwaltet Cloudflare euer DNS, prüft für den normalen Spielzugang die passende DNS-only-Konfiguration. Der übliche HTTP-Proxy ist kein allgemeiner Transport für Minecraft; ein ausdrücklich eingerichteter Transportdienst ist gesondert zu betrachten. Maßgeblich sind die dokumentierten Proxy-Einschränkungen.

Das Ziel proben, ohne eine zweite produktive Welt zu öffnen

Richtet das Ziel mit derselben Software und denselben Identitätseinstellungen ein. Verwendet für die Probe eine isolierte Kopie, trennt kopierte Datenbanken von Produktion und deaktiviert dort produktive Integrationen. Die Anleitung zur Wiederherstellungsprobe behandelt zusammengehörige Sicherungen und repräsentative Prüfungen von Spielerdaten.

Testet über einen kontrollierten Weg, der den vorgesehenen Einstiegspunkt nutzt. Ein direkter IP-Test kann den Proxy oder vom Hostnamen abhängiges Verhalten umgehen. Haltet fest, wie ihr den Test nach der endgültigen Übertragung wiederholt und welche Zielprotokolle ihn belegen. Bei Velocity gelten weiterhin die Grenzen aus den Prüfungen des Backend-Zugangs.

Verwerft Änderungen aus der Probe vor der abschließenden Datenübertragung. Eine erfolgreiche Anmeldung an einer eine Woche alten Kopie belegt nicht, dass der endgültige Umzug die aktuellen Inventare erhalten hat.

Schreibzugriffe eindeutig übergeben

Für das vereinbarte Wartungsfenster bietet sich folgender Ablauf an:

1. Schließt den Spielerzugang und beendet laufende Spielsitzungen. Pausiert Bots, geplante Aufgaben und weitere Systeme, die zusammengehörige Daten verändern.
2. Fahrt den Quellserver sauber herunter. Sichert Welten, benötigte Konfiguration und externe Daten mit den dafür unterstützten Verfahren als dokumentierten Wiederherstellungsstand.
3. Übertragt diesen abschließenden Stand zum Ziel. Prüft, dass er die Probedaten ersetzt hat und die vorgesehenen produktiven Abhängigkeiten verwendet.
4. Beschränkt den Zugang zu beiden Umgebungen, während das Team Dimensionen, Inventare, Berechtigungen und ausgewählte Plugin-Daten kontrolliert. Haltet die Zielprotokolle der Testverbindungen fest.
5. Schaltet den vorbereiteten Verbindungsweg um und prüft ihn aus den für die Abnahme vorgesehenen Netzen. Öffnet den Spielbetrieb erst nach Freigabe durch den benannten Verantwortlichen.

Dies ist ein konservativer Vorschlag für einen geplanten Umzug. Datenbankspezifische Synchronisierung und vorhandene Proxy-Architekturen können einen anderen Ablauf erfordern. Das Weltverzeichnis allein enthält nicht zwangsläufig Guthaben, Schutzgebiete oder Daten einer Integration.

Lasst den alten Spielprozess ausgeschaltet oder verhindert dort zuverlässig weiteren Spielbetrieb. Ein Wartungsdienst darf keine beschreibbare Kopie der alten Welt einbinden. Während des Übergangs erreichen manche Spieler möglicherweise noch die frühere Adresse. Dürfen sie dort weiterbauen, entstehen auseinanderlaufende Datenstände.

Festlegen, wann eine Rückkehr mehr als DNS erfordert

Vor der öffentlichen Freigabe bleibt die Quelle der zuletzt akzeptierte Produktionsstand. Scheitert die Zielprüfung, bleibt das Ziel geschlossen. Setzt nötigenfalls die Verbindung zurück und öffnet die Quelle erst, nachdem ihr ihren Zustand und ihre Abhängigkeiten geprüft habt. Berücksichtigt DNS-Caches auch auf diesem Rückweg.

Sobald Spieler oder Integrationen am Ziel schreiben, ist die Quelle veraltet. DNS zurückzustellen überträgt keine neuen Bauwerke, Inventare oder Datenbanktransaktionen. Beendet Schreibzugriffe und entscheidet, ob ihr das Ziel repariert, seinen aktuellen Stand zurückübertragt oder einen vereinbarten Sicherungsstand wiederherstellt. Dokumentiert erwarteten Datenverlust vor der Wiederöffnung. Eine sofortige Rückkehr sollte ohne nachgewiesenen Datenablauf nicht zugesagt werden.

Nehmt diese kleine Abnahmetabelle in die Übergabe auf:

Prüfung	Erforderlicher Nachweis
Bekannte Adresse	Eine echte Anmeldung erreicht den vorgesehenen Einstieg und erscheint im Zielprotokoll
Spielerdaten	Ausgewählte Inventare, Positionen und Plugin-Datensätze entsprechen der letzten Übertragung
Alter Zugang	Auf der Quelle sind keine Schreibzugriffe durch Spielbetrieb möglich
Entscheidung bei Fehlern	Verantwortlicher, Freigabekriterien und Umgang mit neuen Zieldaten sind dokumentiert

Bewahrt den alten Wiederherstellungsstand bis zum vereinbarten Zeitpunkt auf, beobachtet Anmelde- und Startfehler und setzt nach akzeptiertem Übergang die üblichen TTLs wieder ein. Eine erfolgreiche DNS-Abfrage allein ist keine Abnahme.

Mineandos verwaltete Minecraft-Infrastruktur kann Architektur, Bereitstellung und Wiederherstellungsverfahren als individuell vereinbartes, kostenpflichtiges Projekt umfassen. Beschreibt Zugangswege, Abhängigkeiten und Grenzen des Wartungsfensters; Supportzeiten und Zuständigkeiten werden gesondert vereinbart.