[Startseite](https://servhidden.com/de) / [Datenschutz-Hosting-Leitfäden](https://servhidden.com/de/guides) / Website zu Offshore-Hosting migrieren – ohne Ausfallzeit Betrieb # Offshore-Hosting ohne Ausfallzeit Fast jede schmerzhafte Migration ist ein Fehler in der Reihenfolge, kein technisches Problem – eine TTL, die erst in der Nacht statt zwei Tage vorher gesenkt wird, ein Zertifikat, das nach der DNS-Änderung statt davor ausgestellt wird, ein Cron-Job, der auf einem Server scharf bleibt, der längst nicht mehr autoritativ ist. Das ist die Abfolge, die das Ausfallfenster vollständig beseitigt – plus der Teil, den allgemeine Anleitungen auslassen: was der Umzug dauerhaft über Sie festhält, und was Sie trotzdem noch dagegen tun können. [Anleitung lesen](#guide-body) [FAQ](#guide-faq) ## Auf dieser Seite - [Anleitung](#guide-body) - [FAQ](#guide-faq) - [Verwandte Anleitungen](#guide-related) - [Empfohlene Seiten](#guide-cta) Kein KYC Nur Krypto Keine Logs DMCA ignoriert Voller Root-Zugriff NVMe SSD 19 Min. Lesezeit Aktualisiert Aug 2026 Auf dieser Seite [01Was „keine Ausfallzeit" wirklich bedeutet](#was-keine-ausfallzeit-wirklich-bedeutet) [02Die DNS-TTL Tage vor dem geplanten Umzug senken](#die-dns-ttl-tage-vor-dem-geplanten-umzug-senken) [03Inventarisieren Sie, was Sie umziehen – nicht, was Sie noch im Kopf haben](#inventarisieren-sie-was-sie-umziehen-nicht-was-sie-noch-im-k) [04Den neuen Server zuerst aufsetzen und härten, bevor irgendetwas darauf liegt](#den-neuen-server-zuerst-aufsetzen-und-härten-bevor-irgendetw) [05Die Daten zweimal kopieren: ein langsamer Durchgang, dann ein schneller](#die-daten-zweimal-kopieren-ein-langsamer-durchgang-dann-ein-) [06Den neuen Server testen, bevor DNS von ihm weiß](#den-neuen-server-testen-bevor-dns-von-ihm-weiß) [07Die Umschaltung, Schritt für Schritt](#die-umschaltung-schritt-für-schritt) [08Was die Migration zurücklässt](#was-die-migration-zurücklässt) [09Die Domain-Frage: mitnehmen oder neu anfangen?](#die-domain-frage-mitnehmen-oder-neu-anfangen) [10Den alten Host ordentlich abschalten](#den-alten-host-ordentlich-abschalten) [11Die gesamte Abfolge auf einer Seite](#die-gesamte-abfolge-auf-einer-seite) [FAQHäufige Fragen](#guide-faq) [→Empfohlene Seiten](#guide-cta) 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. | Was Sie umziehen | Der Teil, der wirklich wehtut | Wie der Plan aussehen sollte | | --- | --- | --- | | Statische Seite, Broschürenseite, generierte Ausgabe | Nichts. Es gibt keinen Zustand zum Aufteilen | Kopieren, prüfen, umschalten. Wirklich ganz ohne Ausfallzeit | | CMS mit Datenbank – WordPress, Ghost, ein Forum | Kommentare, Logins und Beiträge landen gleichzeitig in zwei Datenbanken | Eine Nur-Lese-Sperre, gemessen in **Minuten**, zu Ihrer ruhigsten Stunde | | Ein Shop, oder alles, was Bestellungen entgegennimmt | Ein Split-Brain-Zustand verliert bezahlte Bestellungen lautlos | Nehmen Sie das kurze Wartungsfenster in Kauf. Das ist günstiger als der Abgleich danach | | Alles mit Cron-Jobs oder Background-Workern | Derselbe Job feuert auf beiden Servern – doppelte E-Mails, doppelte Abbuchungen | Deaktivieren Sie den Zeitplan auf dem alten Host, *bevor* der neue startet | | Mail auf derselben Domain | MX-Einträge laufen in Caches nach ihrer eigenen Uhr ab, unabhängig von Ihrem A-Eintrag | Verschieben Sie Mail in einer separaten Nacht, und lassen Sie den alten MX eine Woche lang weiter annehmen | 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. Beide Server laufen gleichzeitig, und DNS wird als Letztes umgestellt – deshalb hat eine korrekt sequenzierte Umschaltung überhaupt kein Fenster. ## 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](https://servhidden.com/de/guides/first-hour-vps-hardening-checklist) 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](https://servhidden.com/de/guides/full-disk-encryption-on-a-vps) 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. **Pull statt Push, und niemals über Ihren Laptop.** Starten Sie die Kopie vom neuen Server aus, damit die Übertragung mit Rechenzentrumsgeschwindigkeit von Host zu Host läuft. Gigabytes über Ihren Heimanschluss zu leiten ist langsam, und es setzt die IP-Adresse Ihres Heimanschlusses in die Zugriffslogs beider Maschinen – genau die Verknüpfung, die eine aus Privatsphäre-Gründen motivierte Migration eigentlich vermeiden soll. Wenn es schon inakzeptabel ist, dass der alte Host Ihre neue IP erfährt, kopieren Sie gar nicht erst direkt: Stellen Sie den neuen Server stattdessen aus Ihrem eigenen [verschlüsselten Offsite-Backup](https://servhidden.com/de/guides/vps-backup-strategy) wieder her, und die beiden Maschinen sprechen nie miteinander. ## 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. - 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. - **Deaktivieren Sie cron und Background-Worker auf dem alten Host.** Tun Sie das, bevor Sie sie auf dem neuen starten – niemals danach. - Führen Sie den letzten rsync-Delta-Durchgang und den letzten Datenbank-Dump aus, und importieren Sie ihn. - Starten Sie die Anwendung auf dem neuen Server und wiederholen Sie Ihre Smoke-Tests über --resolve, gegen die endgültigen Daten. - Ä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. - Aktivieren Sie cron und die Worker auf dem neuen Host. - 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. - 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. | Was den Umzug festhält | Wer es lesen kann | Was Sie tatsächlich tun können | | --- | --- | --- | | Passive DNS – historische A-Einträge | Jeder, über kommerzielle Historien-Dienste | **Nichts.** Die alte IP bleibt dauerhaft mit dem Namen verknüpft. Planen Sie so, als wäre es öffentlich – denn das ist es | | Certificate-Transparency-Logs | Jeder, dauerhaft, durchsuchbar nach Domain | Jedes je ausgestellte Zertifikat ist gelistet – einschließlich der intern klingenden Subdomains, die Sie vergessen haben. Bevorzugen Sie ein Wildcard-Zertifikat gegenüber sprechenden Namen | | Die Account-Daten beim alten Host | Der alte Host, und jeder, der ihn dazu zwingen kann | Kartendaten, Anmelde-E-Mail, Login-IPs. Ein no-KYC-Ziel schützt die Zukunft, nicht die Vergangenheit | | WHOIS-Historie | Kommerzielle WHOIS-Historien-Archive | Wurde die Domain je unter echten Angaben registriert, ist dieser Schnappschuss festgehalten. Später hinzugefügte Privatsphäre nimmt das nicht zurück | | Analytics- und Werbe-IDs | Der Anbieter, und jeder, der Ihren Seitenquelltext liest | Dieselbe Tracking-ID weiterzuverwenden verknüpft beide Seiten unwiderlegbar. Vergeben Sie eine neue, oder verzichten Sie ganz darauf | | Dumps und Backups auf der alten Platte | Wer auch immer diesen Speicher als Nächstes zugewiesen bekommt | Löschen und überschreiben, bevor Sie kündigen. Bei Shared Storage gilt: Löschen ist eher ein Hinweis als eine Garantie | | Received:-Header in gesendeten Mails | Jeder Empfänger, für immer | Nichts Rückwirkendes. Nur Mails, die Sie nach dem Umzug versenden, tragen den neuen Pfad | | Ihre eigenen Verbindungen während der Kopie | Ihr ISP, und die Zugriffslogs beider Hosts | Das hier haben Sie vollständig selbst in der Hand. Greifen Sie nie von einer IP aus auf eine der beiden Maschinen zu, die Sie identifiziert | 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](https://servhidden.com/de/guides/server-opsec-staying-anonymous) 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](https://servhidden.com/de/guides/anonymous-domain-registration-with-crypto) 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. - 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. - 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. - Entfernen Sie Ihre öffentlichen SSH-Schlüssel und jeden Support-Zugang vom alten Server. - 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. - Erst danach kündigen Sie den Dienst und entfernen jede gespeicherte Zahlungsmethode aus dem alten Account. **Alles, was auf Hardware lag, die Sie nicht mehr kontrollieren, gilt per Definition als kompromittiert.** Nicht, weil Ihr alter Host böswillig wäre, sondern weil diese Platte zurück in einen Pool wandert und Sie nie erfahren werden, was das Löschen überlebt hat. Ein Datenbankpasswort zu rotieren dauert zwei Minuten. Monate später zu entdecken, dass ein Schlüssel von einem abgeschalteten Server noch immer etwas öffnet, dauert erheblich länger. ## Die gesamte Abfolge auf einer Seite Ohne die Begründung ist eine Host-Migration neun Schritte, von denen nur zwei wirklich dringend sind: - **Zwei Tage vorher:** die DNS-TTL auf 300 Sekunden senken. - **Zwei Tage vorher:** den Zielserver bestellen und härten, Version für Version passend zum alten Stack. - **Tage vorher:** das Inventar schreiben – cron, Secrets, TLS, Mail-Schlüssel, Medien, IP-Allowlists, Pakete. - **Tage vorher:** die erste vollständige Datenkopie ausführen, von Host zu Host. - **Vor dem Fenster:** das Zertifikat per DNS-01 ausstellen und alles über --resolve testen. - **Das Fenster (Minuten):** Schreibvorgänge einfrieren, altes cron deaktivieren, Delta-Kopie und letzten Dump ausführen, die neue Anwendung starten. - **Das Fenster (Sekunden):** den A-Eintrag ändern, dann cron auf dem neuen Host aktivieren. - **Die folgende Woche:** den alten Server als Rollback am Leben lassen, beide Logdateien beobachten, dann die TTL wieder anheben. - **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](https://servhidden.com/de/guides/choosing-an-offshore-jurisdiction) der richtige Startpunkt. FAQ ## Host-Migration – häufige Fragen ### 01 Mit wie viel Ausfallzeit muss ich wirklich rechnen? Bei einer statischen Seite mit gar keiner – beide Server können gleichzeitig denselben Inhalt ausliefern, sodass die DNS-Änderung unsichtbar bleibt. Bei allem mit Datenbank entspricht Ihre Ausfallzeit genau der Länge Ihrer Schreibsperre, typischerweise zwei bis zehn Minuten, wenn Sie vorher bereits eine vollständige Datenkopie gemacht haben. Entscheidend ist nicht, wie schnell DNS sich ändert, sondern wie viel Sie während des Fensters noch kopieren müssen. Kopieren Sie Tage im Voraus fast alles, und das Fenster schrumpft auf die Größe des Deltas. ### 02 Wie lange dauert die DNS-Propagierung? Es gibt keine Propagierung – das Wort beschreibt etwas, das gar nicht stattfindet. Resolver zwischenspeichern Ihren Eintrag einfach so lange, wie es die TTL vorgibt, und fragen erst wieder nach, wenn sie abläuft. Lag die geltende TTL bei 86400, liefern manche Resolver die alte IP noch weitere 24 Stunden lang aus. Senken Sie die TTL mindestens eine volle alte TTL-Periode vor der Umschaltung auf 300 Sekunden, und das gesamte Internet folgt Ihrer Änderung innerhalb von fünf Minuten. ### 03 Muss ich meine Domain auch umziehen? Nein. Registrar und Host sind vollständig unabhängig voneinander, und die Seite umzuziehen, während die Domain genau dort bleibt, wo sie ist, funktioniert einwandfrei. Ob Sie sie umziehen sollten, hängt von Ihrem Grund für die Migration ab: War es Jurisdiktion, Preis oder die DMCA-Handhabung, lassen Sie die Domain in Ruhe. War es Anonymität, bedenken Sie, dass die Domain ihre eigene, getrennte Geschichte trägt – WHOIS-Archive bewahren, mit welchen Angaben sie zuerst registriert wurde, und ein Hosting-Wechsel rührt daran nichts. ### 04 Kann ich migrieren, ohne dass der alte Host erfährt, wohin ich gewechselt bin? Nicht, wenn Sie direkt zwischen den beiden Maschinen kopieren – ein Ende verbindet sich mit dem anderen, und beide Zugriffslogs zeichnen das auf. Wenn diese Verknüpfung für Ihr Bedrohungsmodell wirklich zählt, kopieren Sie gar nicht erst von Host zu Host: Stellen Sie den neuen Server aus Ihrem eigenen verschlüsselten Offsite-Backup wieder her, sodass die beiden Anbieter nie ein Paket austauschen. So oder so: Starten Sie die Übertragung nie von einer Verbindung aus, die Sie identifiziert, und lassen Sie das Ziel aus jedem Support-Ticket heraus, das Sie beim alten Anbieter öffnen. ### 05 Sollte ich gleichzeitig auch das Betriebssystem oder den Stack aktualisieren? Nein, und das ist der häufigste selbstverschuldete Migrationsfehler. Ändern Sie eine Sache. Wenn die Seite nach der Umschaltung Probleme macht, wollen Sie eine einzige mögliche Erklärung haben, nicht die Wahl zwischen der neuen Maschine, der neuen PHP-Version und der neuen Datenbank-Hauptversion. Bilden Sie die alte Umgebung Version für Version nach, schließen Sie den Umzug ab, bestätigen Sie eine Woche saubere Logs, und aktualisieren Sie dann getrennt davon, mit der Möglichkeit zum Rollback. ### 06 Schadet die Migration meinen Suchrankings? Nicht nennenswert, solange Domain, URLs und Inhalt gleich bleiben – Google indexiert URLs, keine IP-Adressen, und ein Host-Wechsel für sich genommen ist kein Ranking-Signal. Behalten Sie die URL-Struktur identisch bei, geben Sie dieselben Statuscodes zurück, und verbinden Sie den Umzug nicht mit einem Redesign oder einer Änderung des URL-Schemas. Ziehen Sie stattdessen auf eine neue Domain um, rechnen Sie selbst mit korrekten 301-Weiterleitungen mit einem vorübergehenden Einbruch – und bedenken Sie, dass diese Weiterleitungen die beiden Namen auch öffentlich verknüpfen. ### 07 Muss ich TLS-Zertifikate neu ausstellen? Ja – der neue Server braucht sein eigenes Zertifikat und einen eigenen privaten Schlüssel, und den alten Schlüssel einfach weiterzukopieren ist eine schlechte Angewohnheit, selbst wenn es technisch funktioniert. Stellen Sie es vor der Umschaltung per DNS-01-Challenge aus, die per TXT-Eintrag validiert und deshalb auch gelingt, während der A-Eintrag noch auf den alten Host zeigt. Wer nach der DNS-Änderung auf HTTP-01 wartet, garantiert sich eine Phase mit Zertifikatswarnungen – genau in dem Fenster, das eigentlich geschützt werden sollte. ### 08 Wann ist es sicher, den alten Server zu kündigen? Nach ein bis zwei Wochen mit stillen Logs auf der alten Maschine und sauberen Logs auf der neuen – die Wartezeit ist Ihr Rollback und kostet ein paar Dollar. Bevor Sie kündigen, prüfen Sie, dass nichts Externes mehr auf die alte IP zeigt, rotieren Sie jedes Secret, das je darauf lag, und löschen Sie dann Ihre Daten und überschreiben Sie den freien Speicherplatz. Kündigen kommt zuletzt. Wer zuerst kündigt, lässt seine Datenbank auf einer Platte zurück, die er nicht mehr kontrolliert. Verwandte Anleitungen ## Weiterlesen [### Wie Sie im Jahr 2026 die richtige Offshore-Hosting-Jurisdiktion wählen Kauf Ein praktischer Entscheidungsrahmen für die Wahl einer Offshore-Jurisdiktion: Datenspeicherungspflicht, MLAT-Exposition, DMCA-Haltung, Reaktionsgeschwindigkeit der Gerichte und reale Durchsetzung — Land für Land. 6-Fragen-FAQ](https://servhidden.com/de/guides/choosing-an-offshore-jurisdiction) [### VPS vs. Dedizierter Server für datenschutzkritische Workloads Kauf Wann ein VPS ausreicht, wann geteilte Mieterschaft zum Risiko wird und wann Bare Metal die einzig ehrliche Antwort ist. Hardware-Isolation, Hypervisor-Risiko und Kosten vs. Bedrohungsmodell. 6-Fragen-FAQ](https://servhidden.com/de/guides/vps-vs-dedicated-for-privacy) [### Selbst gehostetes VPN auf einem No-KYC-VPS: WireGuard vs. OpenVPN Betrieb Warum ein selbst gehostetes VPN kommerziellen Anbietern überlegen ist und wie WireGuard und OpenVPN im Jahr 2026 wirklich bei Datenschutz, Performance und Betriebsrisiko abschneiden. 6-Fragen-FAQ](https://servhidden.com/de/guides/self-hosted-vpn-wireguard-vs-openvpn) [### RTX 4090 vs H100 SXM5 für KI-Inferenz (und wo RTX 5090 passt) Kauf Kaufentscheidungs-Leitfaden: welche NVIDIA-GPU für selbst gehostete LLM-, Bild-, Video-, Sprach- und Fine-Tuning-Workloads im Jahr 2026. RTX 4090 vs RTX 5090 vs H100 SXM5 vs Dual H100 — VRAM, Durchsatz, $/Token, wann jede gewinnt. 6-Fragen-FAQ](https://servhidden.com/de/guides/rtx-4090-vs-h100-for-ai-inference) [### Offshore Windows RDP für MT4 / MT5 / cTrader Forex-Trading Betrieb Vollständiger Leitfaden: Warum ein Windows-RDP für Forex-Trading, wie man eine latenzarme Offshore-Jurisdiktion wählt, MT4 / MT5 / cTrader / Expert-Advisor-Setup, Latenz zu Broker-Servern und der No-KYC-Checkout-Pfad. 6-Fragen-FAQ](https://servhidden.com/de/guides/offshore-windows-rdp-for-forex-trading) [### DMCA-Ignored Hosting erklärt: Was es 2026 wirklich bedeutet Kauf Was „DMCA ignored“ Hosting wirklich bringt, welche Jurisdiktionen das tatsächlich unterstützen, welche Workloads es brauchen — und welche Copyright-Fallen der Begriff nicht abdeckt. 6-Fragen-FAQ](https://servhidden.com/de/guides/dmca-ignored-hosting-explained) [### Anonyme Domain-Registrierung mit Krypto: WHOIS-Datenschutz 2026 Datenschutz Ein praktischer Guide 2026 zur Domain-Registrierung ohne Identitätsoffenbarung: WHOIS-Regime nach TLD, Registrar-Wahl, Coin-Wahl und operative Hygiene. 6-Fragen-FAQ](https://servhidden.com/de/guides/anonymous-domain-registration-with-crypto) [### Krypto-Zahlungen für Hosting: Monero vs. Bitcoin vs. USDT Datenschutz Wie die Wahl der Zahlungswährung beeinflusst, was Ihr Hoster über Sie erfährt. Datenschutz, Gebühren, Abwicklung und Chain-Analyse-Exposition für XMR, BTC und USDT — mit einer klaren Empfehlung. 6-Fragen-FAQ](https://servhidden.com/de/guides/crypto-payments-monero-vs-bitcoin-vs-usdt) [### Ist Offshore-Hosting wirklich anonym? Eine ehrliche Antwort Datenschutz Offshore-Hosting ohne KYC entfernt die Identität, die ein normaler Hoster erfasst – aber „anonym" hängt von der Zahlung, der Protokollierung des Anbieters und Ihrer eigenen Opsec ab. Hier erfahren Sie, was wirklich nachverfolgbar ist. 6-Fragen-FAQ](https://servhidden.com/de/guides/is-offshore-hosting-truly-anonymous) [### Die erste Stunde VPS-Härtung: Eine Checkliste Betrieb Eine konkrete, geordnete Checkliste, um einen neuen VPS in unter einer Stunde abzusichern: SSH-Schlüssel, eine Firewall, fail2ban, automatische Updates und die Reduzierung der Angriffsfläche, die die meisten opportunistischen Angriffe stoppt. 6-Fragen-FAQ](https://servhidden.com/de/guides/first-hour-vps-hardening-checklist) [### Was ist No-KYC-Hosting? Definition, Rechtslage und Funktionsweise Datenschutz Mit No-KYC-Hosting können Sie einen Server mieten, ohne jegliche Identitätsprüfung — kein Name, keine E-Mail, kein Ausweis. Hier erfahren Sie genau, was das bedeutet, wie es technisch funktioniert, ob es legal ist und wie Sie einen seriösen Anbieter erkennen. 6-Fragen-FAQ](https://servhidden.com/de/guides/what-is-no-kyc-hosting) [### Ist Offshore-Hosting legal? Die ehrliche Antwort für 2026 Kauf Offshore-Hosting ist legal – für Sie und für den Anbieter. Hier erfahren Sie, was der Begriff wirklich bedeutet, wo die rechtliche Grenze tatsächlich liegt, welche Mythen Sie getrost vergessen können und wie Sie es verantwortungsvoll nutzen. 6-Fragen-FAQ](https://servhidden.com/de/guides/is-offshore-hosting-legal) [### Hosting mit Monero (XMR) bezahlen – Schritt für Schritt Datenschutz Eine Schritt-für-Schritt-Anleitung zur Bezahlung eines VPS oder dedizierten Servers mit Monero (XMR): warum XMR die privateste Zahlungsmethode ist, wie man es erwirbt und wie der Bezahlvorgang abläuft – vom Rechnungsstellung bis zum laufenden Server in wenigen Minuten. 6-Fragen-FAQ](https://servhidden.com/de/guides/how-to-pay-for-hosting-with-monero) [### Wie man eine Website anonym hostet — Ein praktischer Leitfaden 2026 Datenschutz Ein praktischer, mehrschichtiger Leitfaden zum Hosten einer Website ohne zugeordnete Identität: Konto, Zahlung, Domain, Jurisdiction, Verbindung und Inhalt — jede Schicht ausführlich erklärt. 6-Fragen-FAQ](https://servhidden.com/de/guides/how-to-host-a-website-anonymously) [### WireGuard VPN auf einem VPS einrichten — Schritt-für-Schritt-Anleitung Betrieb Bauen Sie Ihr eigenes privates VPN auf einem VPS mit WireGuard: warum ein selbst gehostetes VPN kommerziellen Angeboten überlegen ist, die vollständige Einrichtung von der Installation bis zum verbundenen Client und wie Sie es absichern. 6-Fragen-FAQ](https://servhidden.com/de/guides/how-to-set-up-wireguard-vpn-on-a-vps) [### LLM auf einem GPU-Server selbst hosten — Leitfaden 2026 Betrieb Betreiben Sie Ihr eigenes Large Language Model auf einem gemieteten GPU-Server: Warum Self-Hosting einer API überlegen ist, welche GPU und welches Modell sich eignen, die Einrichtung mit Ollama oder vLLM und was es kostet. 6-Fragen-FAQ](https://servhidden.com/de/guides/self-host-an-llm-on-a-gpu-server) [### Bulletproof Hosting vs. Offshore Hosting — Was ist der Unterschied? Kauf Bulletproof Hosting und Offshore Hosting werden ständig verwechselt — dabei sind es nicht dasselbe. Hier ist der echte Unterschied, warum er wichtig ist und welches der beiden Sie tatsächlich brauchen. 6-Fragen-FAQ](https://servhidden.com/de/guides/bulletproof-vs-offshore-hosting) [### VPS mit Bitcoin kaufen — Schritt für Schritt (2026) Kauf Eine verständliche Anleitung zum Kauf eines VPS mit Bitcoin: BTC beschaffen, einen Tarif wählen, die Rechnung bezahlen und was Sie erhalten — einen laufenden Server ohne Kreditkarte und ohne hinterlegten Namen. 6-Fragen-FAQ](https://servhidden.com/de/guides/how-to-buy-a-vps-with-bitcoin) [### Die besten Länder für DMCA-ignorierten Hosting im Jahr 2026 Kauf Wo Sie hosten, wenn Ihre Server außerhalb der Reichweite US-amerikanischer Takedown-Mechanismen liegen sollen: die Rechtsordnungen, die funktionieren, was DMCA-ignoriert wirklich bedeutet und wie Sie die richtige Wahl treffen. 6-Fragen-FAQ](https://servhidden.com/de/guides/best-countries-for-dmca-ignored-hosting) [### Tor Hidden Service hosten (.onion-Website) — Anleitung 2026 Betrieb Einen Tor-Onion-Dienst auf einem VPS einrichten: was ein Hidden Service ist, warum er die stärkste Form des anonymen Hostings darstellt, die vollständige Einrichtung und wie man ihn wirklich anonym hält. 6-Fragen-FAQ](https://servhidden.com/de/guides/how-to-host-a-tor-hidden-service) [### Offshore-Mailserver einrichten — Private E-Mails selbst hosten in 2026 Betrieb Betreiben Sie Ihren eigenen privaten Mailserver auf einem Offshore-VPS: Warum E-Mails selbst hosten, was Sie dafür brauchen, die realistische Einrichtung mit einem All-in-One-Mailstack und wie Sie die Zustellbarkeit sicherstellen. 6-Fragen-FAQ](https://servhidden.com/de/guides/offshore-mail-server-setup) [### Krypto-Node-Hosting-Leitfaden — Blockchain-Node auf einem VPS betreiben Betrieb Wie man einen Blockchain-Node auf einem Server hostet: warum man einen eigenen Node betreiben sollte, wie man den Server für Bitcoin, Ethereum, Monero und weitere Ketten dimensioniert, die Einrichtung und wie man ihn privat hält. 6-Fragen-FAQ](https://servhidden.com/de/guides/crypto-node-hosting-guide) [### GPU-Hosting für Stable Diffusion — Eigenen Bildgenerierungsserver betreiben Betrieb Stable Diffusion auf einem eigenen GPU-Server betreiben: Warum selbst hosten, welche GPU die richtige ist, Einrichtung mit einer Web-Oberfläche und Kostenvergleich mit gehosteten Diensten. 6-Fragen-FAQ](https://servhidden.com/de/guides/gpu-hosting-for-stable-diffusion) [### Server-OpSec — Anonym bleiben, wenn man einen Server betreibt Datenschutz Operative Sicherheit für alle, die einen anonymen Server betreiben: die Fehler, die zur Deanonymisierung führen, die Gewohnheiten, die sie verhindern, und wie man Identitäten konsequent trennt. 6-Fragen-FAQ](https://servhidden.com/de/guides/server-opsec-staying-anonymous) [### Seedbox-Einrichtungsanleitung — Bauen Sie 2026 Ihre eigene private Seedbox Betrieb So bauen Sie Ihre eigene Seedbox auf einem Server: Was eine Seedbox ist, wie Sie sie dimensionieren, einen Torrent-Client mit Web-UI installieren und sie privat und sicher betreiben. 6-Fragen-FAQ](https://servhidden.com/de/guides/seedbox-setup-guide) [### DPI-Zensur mit dem eigenen VPS umgehen (Leitfaden 2026) Datenschutz Ihr VPN funktioniert plötzlich nicht mehr? So umgehen Sie DPI-Zensur mit dem eigenen VPS: was Deep Packet Inspection wirklich erkennt, welches der fünf 2026 relevanten Protokolle welche Sperre aushebelt, und eine vollständige VLESS+REALITY-Anleitung. 6-Fragen-FAQ](https://servhidden.com/de/guides/bypass-dpi-censorship-with-your-own-vps) [### Full-Disk-Verschlüsselung auf dem VPS: LUKS-Einrichtung und was sie schützt Betrieb Festplattenverschlüsselung mit LUKS auf dem VPS: verschlüsselte Datenvolumes, Root-Verschlüsselung mit SSH-Fernentsperrung und die Einstellungen für kleine Server. 8-Fragen-FAQ](https://servhidden.com/de/guides/full-disk-encryption-on-a-vps) [### Ursprungsserver-IP verbergen: CDN, Reverse Proxy und was trotzdem leckt Datenschutz Ob ein CDN vor den Offshore-Server gehört: was es verbirgt, welche Abuse-Stelle Sie erben, die sechs Wege, wie eine Ursprungs-IP trotzdem leckt, und wie Sie Ihre eigene prüfen. 8-Fragen-FAQ](https://servhidden.com/de/guides/hiding-your-origin-server-ip) [### VPS-Backup: verschlüsselt, extern und wirklich wiederherstellbar Betrieb Ihr Hoster speichert keine Backups. Was Server wirklich zerstört, restic vs. BorgBackup, die vergessenen Schlüssel – und wie Sie einen Restore testen, bevor es zu spät ist. 8-Fragen-FAQ](https://servhidden.com/de/guides/vps-backup-strategy) [### Matrix-Server selbst hosten: Federation, Metadaten & E2EE-Lücken Betrieb Was ein eigener Matrix-Homeserver wirklich bringt: Synapse vs. Conduit, der unveränderliche server_name, volle Platten und was Federation dennoch preisgibt. 8-Fragen-FAQ](https://servhidden.com/de/guides/self-host-a-matrix-server) [### How to Self-Host a Crypto Payment Gateway with BTCPay Server Betrieb Run your own non-custodial checkout on an offshore VPS: BTCPay Server, a pruned Bitcoin node, Lightning and Monero — how to size the disk, why the private keys must never touch the machine, and where KYC quietly reappears at the cash-out. 8-Fragen-FAQ](https://servhidden.com/de/guides/self-host-a-crypto-payment-gateway) ## Geben Sie der Migration einen Ort zum Landen Offshore-KVM-Server in sieben Jurisdiktionen ab 7,50 $/Monat, mit vollem Root-Zugriff, NVMe-Speicher und unbegrenzter Bandbreite, bereitgestellt in unter fünf Minuten, sobald eine Krypto-Zahlung bestätigt ist. Setzen Sie das Ziel frühzeitig auf, kopieren Sie in Ihrem eigenen Tempo, und schalten Sie um, wenn es bereit ist. [VPS-Tarife ansehen](https://servhidden.com/de/vps) [Offshore-Hosting](https://servhidden.com/de/offshore-hosting) [Alle Standorte](https://servhidden.com/de/locations) ## Structured data (JSON-LD) ```json { "@context": "https://schema.org", "@type": "Organization", "@id": "https://servhidden.com/#organization", "name": "ServHidden", "url": "https://servhidden.com", "description": "Offshore-VPS & Dedicated Server in 7 datenschutzfreundlichen Jurisdiktionen. Kein KYC, keine Logs, nur Krypto. Datenschutz durch Architektur.", "logo": { "@type": "ImageObject", "url": "https://servhidden.com/ServHidden.webp", "width": 512, "height": 512 }, "foundingDate": "2025", "areaServed": [ { "@type": "Country", "name": "Iceland" }, { "@type": "Country", "name": "Panama" }, { "@type": "Country", "name": "Moldova" }, { "@type": "Country", "name": "Romania" }, { "@type": "Country", "name": "Switzerland" }, { "@type": "Country", "name": "Netherlands" }, { "@type": "Country", "name": "Russia" } ], "knowsAbout": [ "Offshore hosting", "Offshore VPS", "Bare-metal dedicated servers", "DMCA-ignored hosting", "No KYC hosting", "Cryptocurrency payments", "Privacy engineering", "Token-based authentication", "Anonymous domain name registration", "No-KYC domain registrar", "WHOIS privacy", "Cheap .com domains", "Crypto-paid domain names", "NVIDIA GPU compute", "Windows RDP hosting", "Agentic commerce" ], "contactPoint": { "@type": "ContactPoint", "contactType": "customer support", "url": "https://servhidden.com/contact", "availableLanguage": [ "en", "ru", "zh", "es", "fr", "de", "pt", "ar", "ja", "ko", "hi", "id", "it", "tr", "fa", "vi" ] }, "sameAs": [ "https://servhidden.com/canary", "https://servhidden.com/press" ] } ``` ```json { "@context": "https://schema.org", "@type": "WebSite", "@id": "https://servhidden.com/#website", "url": "https://servhidden.com", "name": "ServHidden", "publisher": { "@id": "https://servhidden.com/#organization" }, "inLanguage": [ "en", "ru", "zh", "es", "fr", "de", "pt", "ar", "ja", "ko", "hi", "id", "it", "tr", "fa", "vi" ] } ``` ```json { "@context": "https://schema.org", "@type": "Article", "headline": "Website zu Offshore-Hosting migrieren – ohne Ausfallzeit", "description": "Die Reihenfolge, die eine Host-Migration langweilig macht: die DNS-TTL Tage vorher senken, beide Server parallel betreiben, Schreibvorgänge für Minuten statt Stunden einfrieren – und die Spur aus Passive DNS, Certificate Transparency und WHOIS aufräumen, die der Umzug hinterlässt.", "image": "https://servhidden.com/assets/img/guides/migrate-website-to-offshore-hosting.webp?v=1787969426", "author": { "@type": "Organization", "@id": "https://servhidden.com/#editorial", "name": "ServHidden Editorial", "url": "https://servhidden.com/about", "description": "Operator-side editorial team writing about offshore hosting jurisdictions, offshore server architecture, self-hosted privacy stacks and crypto payments.", "knowsAbout": [ "Offshore hosting jurisdictions", "Data retention law", "MLAT and judicial cooperation", "WireGuard and OpenVPN deployment", "Tor relay operation", "Monero and Bitcoin payment privacy", "KVM virtualization and bare-metal hosting", "DMCA-ignored hosting" ], "parentOrganization": { "@id": "https://servhidden.com/#organization" } }, "publisher": { "@id": "https://servhidden.com/#organization" }, "datePublished": "2026-08-29T00:00:00+00:00", "dateModified": "2026-08-29T00:00:00+00:00", "mainEntityOfPage": "https://servhidden.com/guides/migrate-website-to-offshore-hosting", "inLanguage": "de", "keywords": "Website umziehen ohne Ausfallzeit, Hosting wechseln ohne Downtime, VPS migrieren Anleitung, DNS TTL vor Umzug senken, Server migrieren Checkliste, rsync Server-Migration, Webhosting wechseln ohne KYC, Domainumzug ohne SEO-Verlust", "articleSection": "Betrieb", "wordCount": 3782 } ``` ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "Mit wie viel Ausfallzeit muss ich wirklich rechnen?", "acceptedAnswer": { "@type": "Answer", "text": "Bei einer statischen Seite mit gar keiner – beide Server können gleichzeitig denselben Inhalt ausliefern, sodass die DNS-Änderung unsichtbar bleibt. Bei allem mit Datenbank entspricht Ihre Ausfallzeit genau der Länge Ihrer Schreibsperre, typischerweise zwei bis zehn Minuten, wenn Sie vorher bereits eine vollständige Datenkopie gemacht haben. Entscheidend ist nicht, wie schnell DNS sich ändert, sondern wie viel Sie während des Fensters noch kopieren müssen. Kopieren Sie Tage im Voraus fast alles, und das Fenster schrumpft auf die Größe des Deltas." } }, { "@type": "Question", "name": "Wie lange dauert die DNS-Propagierung?", "acceptedAnswer": { "@type": "Answer", "text": "Es gibt keine Propagierung – das Wort beschreibt etwas, das gar nicht stattfindet. Resolver zwischenspeichern Ihren Eintrag einfach so lange, wie es die TTL vorgibt, und fragen erst wieder nach, wenn sie abläuft. Lag die geltende TTL bei 86400, liefern manche Resolver die alte IP noch weitere 24 Stunden lang aus. Senken Sie die TTL mindestens eine volle alte TTL-Periode vor der Umschaltung auf 300 Sekunden, und das gesamte Internet folgt Ihrer Änderung innerhalb von fünf Minuten." } }, { "@type": "Question", "name": "Muss ich meine Domain auch umziehen?", "acceptedAnswer": { "@type": "Answer", "text": "Nein. Registrar und Host sind vollständig unabhängig voneinander, und die Seite umzuziehen, während die Domain genau dort bleibt, wo sie ist, funktioniert einwandfrei. Ob Sie sie umziehen sollten, hängt von Ihrem Grund für die Migration ab: War es Jurisdiktion, Preis oder die DMCA-Handhabung, lassen Sie die Domain in Ruhe. War es Anonymität, bedenken Sie, dass die Domain ihre eigene, getrennte Geschichte trägt – WHOIS-Archive bewahren, mit welchen Angaben sie zuerst registriert wurde, und ein Hosting-Wechsel rührt daran nichts." } }, { "@type": "Question", "name": "Kann ich migrieren, ohne dass der alte Host erfährt, wohin ich gewechselt bin?", "acceptedAnswer": { "@type": "Answer", "text": "Nicht, wenn Sie direkt zwischen den beiden Maschinen kopieren – ein Ende verbindet sich mit dem anderen, und beide Zugriffslogs zeichnen das auf. Wenn diese Verknüpfung für Ihr Bedrohungsmodell wirklich zählt, kopieren Sie gar nicht erst von Host zu Host: Stellen Sie den neuen Server aus Ihrem eigenen verschlüsselten Offsite-Backup wieder her, sodass die beiden Anbieter nie ein Paket austauschen. So oder so: Starten Sie die Übertragung nie von einer Verbindung aus, die Sie identifiziert, und lassen Sie das Ziel aus jedem Support-Ticket heraus, das Sie beim alten Anbieter öffnen." } }, { "@type": "Question", "name": "Sollte ich gleichzeitig auch das Betriebssystem oder den Stack aktualisieren?", "acceptedAnswer": { "@type": "Answer", "text": "Nein, und das ist der häufigste selbstverschuldete Migrationsfehler. Ändern Sie eine Sache. Wenn die Seite nach der Umschaltung Probleme macht, wollen Sie eine einzige mögliche Erklärung haben, nicht die Wahl zwischen der neuen Maschine, der neuen PHP-Version und der neuen Datenbank-Hauptversion. Bilden Sie die alte Umgebung Version für Version nach, schließen Sie den Umzug ab, bestätigen Sie eine Woche saubere Logs, und aktualisieren Sie dann getrennt davon, mit der Möglichkeit zum Rollback." } }, { "@type": "Question", "name": "Schadet die Migration meinen Suchrankings?", "acceptedAnswer": { "@type": "Answer", "text": "Nicht nennenswert, solange Domain, URLs und Inhalt gleich bleiben – Google indexiert URLs, keine IP-Adressen, und ein Host-Wechsel für sich genommen ist kein Ranking-Signal. Behalten Sie die URL-Struktur identisch bei, geben Sie dieselben Statuscodes zurück, und verbinden Sie den Umzug nicht mit einem Redesign oder einer Änderung des URL-Schemas. Ziehen Sie stattdessen auf eine neue Domain um, rechnen Sie selbst mit korrekten 301-Weiterleitungen mit einem vorübergehenden Einbruch – und bedenken Sie, dass diese Weiterleitungen die beiden Namen auch öffentlich verknüpfen." } }, { "@type": "Question", "name": "Muss ich TLS-Zertifikate neu ausstellen?", "acceptedAnswer": { "@type": "Answer", "text": "Ja – der neue Server braucht sein eigenes Zertifikat und einen eigenen privaten Schlüssel, und den alten Schlüssel einfach weiterzukopieren ist eine schlechte Angewohnheit, selbst wenn es technisch funktioniert. Stellen Sie es vor der Umschaltung per DNS-01-Challenge aus, die per TXT-Eintrag validiert und deshalb auch gelingt, während der A-Eintrag noch auf den alten Host zeigt. Wer nach der DNS-Änderung auf HTTP-01 wartet, garantiert sich eine Phase mit Zertifikatswarnungen – genau in dem Fenster, das eigentlich geschützt werden sollte." } }, { "@type": "Question", "name": "Wann ist es sicher, den alten Server zu kündigen?", "acceptedAnswer": { "@type": "Answer", "text": "Nach ein bis zwei Wochen mit stillen Logs auf der alten Maschine und sauberen Logs auf der neuen – die Wartezeit ist Ihr Rollback und kostet ein paar Dollar. Bevor Sie kündigen, prüfen Sie, dass nichts Externes mehr auf die alte IP zeigt, rotieren Sie jedes Secret, das je darauf lag, und löschen Sie dann Ihre Daten und überschreiben Sie den freien Speicherplatz. Kündigen kommt zuletzt. Wer zuerst kündigt, lässt seine Datenbank auf einer Platte zurück, die er nicht mehr kontrolliert." } } ] } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "Startseite", "item": "https://servhidden.com/de/" }, { "@type": "ListItem", "position": 2, "name": "Datenschutz-Hosting-Leitfäden", "item": "https://servhidden.com/de/guides" }, { "@type": "ListItem", "position": 3, "name": "Website zu Offshore-Hosting migrieren – ohne Ausfallzeit", "item": "https://servhidden.com/de/guides/migrate-website-to-offshore-hosting" } ] } ```