Offshore-Hosting ohne Ausfallzeit

Niemand zieht eine laufende Seite zum Vergnügen um. Es passiert, weil der aktuelle Host plötzlich ein Foto Ihres Passes will, eine Beschwerde mit einer 24-Stunden-Frist weiterleitet, oder weil das Land, in dem sein Rechenzentrum steht, aufgehört hat, wie ein vernünftiger Ort für Ihre Daten auszusehen. Was auch immer Sie dazu gebracht hat – der Umzug selbst ist der gefährliche Teil: der eine Moment, in dem die Seite dunkel werden kann, und der eine Moment, in dem ein unachtsamer Schritt den neuen Server an die Identität heftet, die Sie eigentlich hinter sich lassen wollten.

Beide Risiken haben dieselbe Lösung, und es ist kein Werkzeug. Es ist die Reihenfolge. Eine Migration in der richtigen Abfolge hat kein Fenster, in dem die Seite unerreichbar ist, weil beide Server gleichzeitig laufen und DNS als Letztes umgestellt wird. Eine Migration in der falschen Abfolge erzeugt Ausfall und Spur zugleich. Was folgt, ist genau diese Abfolge, geschrieben für jemanden, der zu einem Offshore- und no-KYC-Host wechselt, statt zwischen zwei üblichen Anbietern hin- und herzuwechseln – die Mechanik ist dieselbe, die Aufräumarbeit danach nicht.

Was „keine Ausfallzeit" wirklich bedeutet

Der Ausdruck wird locker verwendet, und genau in dieser Lockerheit tut es weh. HTTP von zwei Maschinen gleichzeitig auszuliefern ist einfach. Den Zustand konsistent zu halten, während zwei Maschinen gleichzeitig bedienen, ist der schwierige Teil – und der einzige Teil, bei dem je Daten verloren gehen. Entscheiden Sie deshalb, bevor Sie irgendetwas planen, welchen dieser Fälle Sie tatsächlich vor sich haben, denn die Antwort bestimmt den Ablauf der ganzen Nacht.

Beachten Sie, dass nur die erste Zeile wirklich kostenlos ist. Überall sonst bedeutet „keine Ausfallzeit" so viel wie „eine Schreibsperre, die so kurz ist, dass niemand deswegen ein Ticket aufmacht". Zwei Minuten Nur-Lese-Betrieb um 04:00 Uhr sind ein Rundungsfehler; zwei Stunden gespaltener Schreibvorgänge über zwei Datenbanken hinweg sind ein Wochenende Abgleich. Wählen Sie die Sperre.

Die DNS-TTL Tage vor dem geplanten Umzug senken

Das ist der einzige Schritt mit Vorlaufzeit, weshalb er zuerst kommt – und weshalb er derjenige ist, den alle überspringen. Ihre TTL – time to live – sagt jedem Resolver im Internet, wie lange er Ihren Eintrag zwischenspeichern darf, bevor er erneut nachfragt. Hat Ihr A-Eintrag eine TTL von 86400, liefert ein Resolver, der ihn vor einer Stunde abgefragt hat, noch weitere 23 Stunden lang die alte IP aus – egal, was Sie beim Registrar ändern.

Das entscheidende Detail: Das Senken der TTL unterliegt selbst der alten TTL. Resolver erfahren erst dann vom neuen, kürzeren Wert, wenn die alte zwischengespeicherte Kopie abläuft. Senken Sie die TTL deshalb mindestens eine volle alte TTL-Periode vor der Umschaltung auf 300 Sekunden – bei einer tagelangen TTL heißt das 24 bis 48 Stunden vorher. Dann folgt die ganze Welt Ihrem neuen Eintrag innerhalb von fünf Minuten nach der Änderung, und die Umschaltung hört auf, ein nervenaufreibendes Ereignis zu sein.

Setzen Sie die TTL ein paar Tage nach dem Umzug wieder auf einen vernünftigen Wert. Eine 300-Sekunden-TTL ist ein gutes Werkzeug, aber eine schlechte dauerhafte Einstellung: Sie vervielfacht Ihr Abfragevolumen und macht Ihren DNS-Anbieter zu einem noch schärferen Single Point of Failure.

Inventarisieren Sie, was Sie umziehen – nicht, was Sie noch im Kopf haben

Jede gescheiterte Migration hat dasselbe Post-Mortem: Etwas, das niemand aufgelistet hatte, wurde nicht kopiert. Das Web-Root und die Datenbank sind die zwei Dinge, an die sich jeder erinnert; die folgende Liste ist der Rest, und es lohnt sich, sie wörtlich durchzugehen statt aus dem Gedächtnis.

• Geplante Aufgaben. crontab -l für jeden Benutzer, dazu systemd-Timer. Renewal-Hooks und nächtliche Jobs verstecken sich hier.
• Service-Definitionen. Eigene systemd-Units, die vHosts des Webservers, PHP-FPM-Pools, jede Supervisor-Konfiguration.
• Secrets und Umgebung. .env-Dateien, API-Schlüssel, Datenbankpasswörter, Anwendungs-Salts – und denken Sie daran, dass diese rotiert und nicht nur kopiert werden sollten.
• TLS-Material. Zertifikate und, wichtiger noch, der ACME-Account und die Erneuerungskonfiguration.
• Mail-Identität. Private DKIM-Schlüssel, SPF- und DMARC-Einträge. Stimmt hier etwas nicht, bricht nichts laut zusammen – es schickt Ihre Mails nur still in den Spam.
• Hochgeladene Medien. Oft außerhalb des Web-Roots, oft das Größte, was Sie besitzen.
• Alles Externe, das Ihrer IP vertraut. Allowlists der Zahlungs-Gateways, Webhook-Ziele, Datenbank-Firewalls, Drittanbieter-APIs mit IP-Beschränkungen. Das ist die häufigste Ursache für „die Seite läuft, aber der Checkout ist kaputt" um 03:00 Uhr.
• Die Paketliste. dpkg --get-selections oder das Äquivalent, damit die neue Maschine dieselben Erweiterungen und Bibliotheken hat statt nur beinahe dieselben.

Schreiben Sie die Liste auf, bevor Sie mit dem Kopieren beginnen. Das Inventar ist später auch Ihr Testplan – jede Zeile darauf ist etwas, das Sie auf dem neuen Server prüfen, bevor DNS überhaupt von seiner Existenz weiß.

Den neuen Server zuerst aufsetzen und härten, bevor irgendetwas darauf liegt

Bestellen Sie das Zielsystem frühzeitig und lassen Sie es ein oder zwei Tage lang leer laufen. Die Überlappung kostet nichts – ein kleiner Offshore-VPS kostet ein paar Dollar im Monat –, und es bringt sehr viel, den Aufbau nicht unter Zeitdruck mit einer eingefrorenen Datenbank im Wartestand erledigen zu müssen.

Bilden Sie die alte Umgebung bewusst nach: dieselbe Distribution und Hauptversion, dieselbe PHP-, Node- oder Python-Hauptversion, dieselbe Datenbank-Hauptversion. Die Versuchung, dabei gleich zu modernisieren, ist enorm – widerstehen Sie ihr vollständig. Wenn die Seite nach der Umschaltung nicht funktioniert, soll sich genau eine Variable geändert haben. Aktualisieren Sie den Stack zwei Wochen später, an einem langweiligen Nachmittag, mit der Möglichkeit zum Rollback.

Härten Sie ihn, solange er noch leer ist. SSH nur mit Schlüsseln, eine Firewall mit Default-Deny, automatische Sicherheitsupdates – die Hardening-Checkliste für die erste Stunde ist genau diese Liste, und sie lässt sich auf eine Maschine ohne Inhalt weit einfacher anwenden. Wenn die Daten sensibel genug sind, dass Sie deswegen die Jurisdiktion wechseln, ist jetzt auch der richtige Moment, um über Verschlüsselung im Ruhezustand zu entscheiden, denn sie nachträglich einzubauen bedeutet eine weitere Migration.

Die Daten zweimal kopieren: ein langsamer Durchgang, dann ein schneller

Der Instinkt sagt: alles während des Wartungsfensters kopieren. Machen Sie das Gegenteil. Führen Sie Tage vorher eine vollständige Kopie durch, während die alte Seite ganz entspannt weiter Traffic bedient, und lassen Sie dann bei der Umschaltung einen zweiten Durchgang laufen, der nur überträgt, was sich geändert hat. Der erste Durchgang kann sechs Stunden dauern, und niemand bemerkt es. Der zweite dauert 90 Sekunden, und das ist Ihr gesamtes Ausfallzeit-Budget.

Für Dateien erhält rsync -aHAX --numeric-ids Berechtigungen, Eigentümer, Hardlinks und erweiterte Attribute; das Flag --numeric-ids ist wichtig, weil UIDs zwischen zwei frisch aufgesetzten Maschinen selten übereinstimmen. Führen Sie es einmal frühzeitig aus, dann noch einmal unmittelbar vor der Umschaltung mit denselben Argumenten – der zweite Lauf überträgt nur das Delta.

Datenbanken brauchen dieselbe zweiphasige Behandlung, aber andere Werkzeuge. Ein mysqldump --single-transaction oder pg_dump liefert Ihnen einen konsistenten frühen Snapshot zum Aufbauen und Testen. Bei der Umschaltung erstellen Sie entweder während Ihrer kurzen Schreibsperre einen zweiten Dump, oder – bei einer großen Datenbank, wo selbst eine kurze Sperre wehtut – richten Sie den neuen Server Tage im Voraus als Replikat des alten ein, lassen ihn aufholen und stufen ihn dann hoch. Replikation macht aus der Sperre eine Sache von Sekunden. Sie macht aber auch aus einer zweistündigen Migration ein zweitägiges Projekt, also setzen Sie sie nur ein, wenn die Größe es wirklich verlangt.

Den neuen Server testen, bevor DNS von ihm weiß

Sie können den echten Hostnamen von der neuen IP ausliefern, ohne einen einzigen öffentlichen Eintrag zu ändern – und Sie sollten das auch tun, denn genau das macht die Umschaltung ereignislos. Fügen Sie Ihrer lokalen /etc/hosts eine Zeile hinzu, die die Domain auf die neue IP zeigen lässt, oder lassen Sie das curl für eine einzelne Anfrage erledigen:

curl -I --resolve example.com:443:203.0.113.10 https://example.com/

Gehen Sie jetzt das Inventar durch. Laden Sie die Startseite und drei tiefer liegende Seiten. Loggen Sie sich ein. Senden Sie ein Formular ab. Laden Sie eine Datei hoch. Prüfen Sie, dass die Datenbankverbindung die neue lokale ist und nicht immer noch über das Internet auf den alten Host zeigt – ein Fehler, der perfekt funktioniert, bis genau zu dem Moment, in dem Sie den alten Server kündigen. Führen Sie die Cron-Jobs von Hand aus und lesen Sie ihre Ausgabe. Prüfen Sie die Weiterleitungen und dass eine fehlende URL weiterhin 404 statt 200 zurückgibt.

Stellen Sie das TLS-Zertifikat jetzt aus, vor der Umschaltung, nicht danach. Verwenden Sie eine DNS-01-Challenge, die die Kontrolle über die Domain per TXT-Eintrag nachweist und deshalb funktioniert, während der A-Eintrag noch auf den alten Server zeigt. Wenn Sie bis nach der DNS-Änderung mit der HTTP-01-Validierung warten, bekommt jeder frühe Besucher in der Zwischenzeit eine Zertifikatswarnung – ein selbstverschuldeter Ausfall genau in dem Fenster, das Sie eigentlich schützen wollten.

Die Umschaltung, Schritt für Schritt

An diesem Punkt ist der neue Server aufgesetzt, gehärtet, befüllt, unter dem echten Hostnamen getestet und hält ein gültiges Zertifikat. Die Umschaltung selbst ist jetzt nur noch eine kurze, langweilige Liste – und genau das ist das Ziel.

1. Kündigen Sie das Fenster an, falls noch jemand anderes von der Seite abhängt, und versetzen Sie die alte Seite dann in den Nur-Lese- oder Wartungsmodus.
2. Deaktivieren Sie cron und Background-Worker auf dem alten Host. Tun Sie das, bevor Sie sie auf dem neuen starten – niemals danach.
3. Führen Sie den letzten rsync-Delta-Durchgang und den letzten Datenbank-Dump aus, und importieren Sie ihn.
4. Starten Sie die Anwendung auf dem neuen Server und wiederholen Sie Ihre Smoke-Tests über --resolve, gegen die endgültigen Daten.
5. Ändern Sie die A- und AAAA-Einträge auf die neue IP. Bei einer 300-Sekunden-TTL folgt die Welt innerhalb von fünf Minuten.
6. Aktivieren Sie cron und die Worker auf dem neuen Host.
7. Beobachten Sie beide Zugriffslogs nebeneinander. Der Traffic läuft vom alten Server ab und taucht auf dem neuen auf; wenn der alte still wird, ist die Umschaltung abgeschlossen.
8. Lassen Sie den alten Server eine Woche lang laufen, weiter bedienen und unangetastet. Er ist Ihr Rollback.

Schritt acht ist der, den alle streichen, und er ist die billigste Versicherung auf der Liste. Für ein paar Dollar behalten Sie die Möglichkeit, DNS zurückzustellen – eine Wiederherstellung in fünf Minuten – so lange, wie Sie brauchen, um sicher zu sein.

Was die Migration zurücklässt

Hier ist der Teil, den allgemeine Migrationsanleitungen auslassen – und der Teil, der am meisten zählt, wenn Sie aus Gründen der Privatsphäre umgezogen sind und nicht wegen des Preises. Der Umzug einer Seite löscht ihre Geschichte nicht. Mehrere öffentliche und halböffentliche Aufzeichnungen der alten Einrichtung überleben den Umzug dauerhaft, und zu wissen, welche das sind, macht den Unterschied zwischen einem echten und einem nur gefühlten sauberen Schnitt.

Die ehrliche Zusammenfassung: Eine Migration kann die Vergangenheit nicht umschreiben – sie kann nur aufhören, ihr etwas hinzuzufügen. Das ist trotzdem eine ganze Menge wert, ändert aber die Entscheidung: Wenn Ihr Bedrohungsmodell verlangt, dass kein Beobachter die neue Seite mit der alten verknüpfen kann, erreicht der Umzug derselben Domain zu einem neuen Host das nicht – und auch noch so viel Sorgfalt bei der Umschaltung wird daran nichts ändern. Dieser Fall braucht einen neuen Namen und einen echten Neuanfang, dazu gleich mehr. Wenn Ihr Ziel stattdessen ist, ab heute keine identifizierenden Spuren mehr zu erzeugen und den rechtlichen Schwerpunkt in eine selbst gewählte Jurisdiktion zu verlegen, dann leistet der Umzug genau das. Unser Leitfaden zu Server-OpSec behandelt die Gewohnheiten, die es danach sauber halten.

Die Domain-Frage: mitnehmen oder neu anfangen?

Die Seite und die Domain sind unabhängige Entscheidungen, und beide zu vermischen kommt häufig vor. Sie können das Hosting heute umziehen und den Registrar für immer in Ruhe lassen; nichts am Serverwechsel erfordert, die Domain überhaupt anzufassen. Ob Sie es sollten, hängt vollständig davon ab, was die Domain bereits über Sie weiß.

• Domain behalten, Registrar wechseln. Sinnvoll, wenn die Domain einen Wert hat – Links, Rankings, ein Name, den Leute eintippen. Das korrigiert die Zukunft des WHOIS-Eintrags, nicht seine Geschichte, und hält jedes Ranking-Signal intakt. Für die meisten kommerziellen Seiten ist das die richtige Antwort.
• Domain behalten, nur den Host wechseln. Völlig vernünftig, wenn Sie wegen Jurisdiktion, Uptime oder DMCA-Handhabung umgezogen sind und nicht wegen Anonymität. Der einfachste mögliche Umzug, ohne jedes SEO-Risiko.
• Neue Domain, alte weiterleiten. Erhält die Rankings, verknüpft die beiden Namen aber öffentlich und dauerhaft. Wählen Sie das für Kontinuität, niemals für Privatsphäre – die Weiterleitung ist die Verknüpfung.
• Neue Domain, sauberer Schnitt. Die einzige Option, die die Verbindung wirklich kappt – und sie kostet Sie jedes Ranking und jeden eingehenden Link, den Sie hatten. Registrieren Sie sie von Anfang an privat, denn eine Domain ist nur so anonym wie ihre erste Registrierung. Unser Leitfaden zur anonymen Domain-Registrierung mit Krypto beschreibt, wie das richtig geht.

Entscheiden Sie bewusst, und entscheiden Sie vor der Umschaltung, nicht währenddessen. Es sich bei der Domain nach der DNS-Umstellung noch einmal anders zu überlegen bedeutet, den heiklen Teil zweimal zu machen.

Den alten Host ordentlich abschalten

Ein bis zwei Wochen nach der Umschaltung, wenn die Logs des neuen Servers langweilig und die des alten leer sind, ist es Zeit, den alten Account zu schließen. Tun Sie das in dieser Reihenfolge, denn die verlockende Abkürzung – einfach kündigen – ist genau die, die Ihre Daten auf der Platte eines anderen zurücklässt.

1. Bestätigen Sie, dass nichts mehr auf die alte IP zeigt: Prüfen Sie fest codierte Adressen in Webhooks von Drittanbietern, Allowlists, Monitoring, und jeden vergessenen DNS-Eintrag, etwa eine übrig gebliebene mail- oder cpanel-Subdomain.
2. Rotieren Sie jedes Secret, das je auf dieser Maschine lag – Datenbankpasswörter, API-Schlüssel, Anwendungs-Salts, DKIM-Schlüssel, SSH-Schlüssel. Kopieren Sie sie nicht einfach weiter.
3. Entfernen Sie Ihre öffentlichen SSH-Schlüssel und jeden Support-Zugang vom alten Server.
4. Löschen Sie die Anwendung, die Dumps und die Backups, und überschreiben Sie dann den freien Speicherplatz, damit ein flüchtiges Auslesen des wiederverwendeten Volumes nichts ergibt.
5. Erst danach kündigen Sie den Dienst und entfernen jede gespeicherte Zahlungsmethode aus dem alten Account.

Die gesamte Abfolge auf einer Seite

Ohne die Begründung ist eine Host-Migration neun Schritte, von denen nur zwei wirklich dringend sind:

1. Zwei Tage vorher: die DNS-TTL auf 300 Sekunden senken.
2. Zwei Tage vorher: den Zielserver bestellen und härten, Version für Version passend zum alten Stack.
3. Tage vorher: das Inventar schreiben – cron, Secrets, TLS, Mail-Schlüssel, Medien, IP-Allowlists, Pakete.
4. Tage vorher: die erste vollständige Datenkopie ausführen, von Host zu Host.
5. Vor dem Fenster: das Zertifikat per DNS-01 ausstellen und alles über --resolve testen.
6. Das Fenster (Minuten): Schreibvorgänge einfrieren, altes cron deaktivieren, Delta-Kopie und letzten Dump ausführen, die neue Anwendung starten.
7. Das Fenster (Sekunden): den A-Eintrag ändern, dann cron auf dem neuen Host aktivieren.
8. Die folgende Woche: den alten Server als Rollback am Leben lassen, beide Logdateien beobachten, dann die TTL wieder anheben.
9. Danach: Secrets rotieren, löschen, kündigen – und sich erinnern, was der Umzug nicht auslöschen konnte.

Nichts auf dieser Liste ist schwierig. Jeder Schritt, der wehtut, ist ein Schritt, der außer der Reihe gemacht wurde – eine TTL, die erst in der Nacht gesenkt wird, ein Zertifikat, das nach der DNS-Änderung ausgestellt wird, ein Cron-Job, der auf einer nicht mehr autoritativen Maschine scharf bleibt. Stimmt die Reihenfolge, ist der interessante Teil einer Migration die Wahl, wo der Server stehen soll – nicht der Umzug selbst. Wenn Sie das noch nicht entschieden haben, ist der Leitfaden zur Jurisdiktionswahl der richtige Startpunkt.