OVH-Umzug abgrenzen: OVH zu Hetzner migrieren. Termin vereinbaren.
Ein OVH-zu-Hetzner-Umzug beginnt mit der Frage, was tatsächlich umziehen soll: eine Linux-Anwendung, mehrere Public-Cloud-Instanzen, ein Dedicated Server oder eine Umgebung mit privaten Netzen und separaten Datenbanken. Dieser Leitfaden ordnet den Ablauf für administrierbare Linux-Anwendungen. Er ist kein universeller Image-Import und kein Erfahrungsbericht aus einem Kundenprojekt.
Stand der Produktdokumentation: Oktober 2026. Die Checklisten sind unsere Planungsempfehlungen, die Befehle anpassbare Beispiele.
Inhaltsverzeichnis
- Bestand und Migrationsgrenze festhalten
- vRack und Zielnetz getrennt planen
- Zielsystem vor der Datenkopie vorbereiten
- Dateien und Datenbanken getrennt übertragen
- Umschaltung und Rückweg definieren
- Kosten und Abnahme prüfen
- Unser Vorgehen bei WZ-IT
- Weiterführende Guides
Bestand und Migrationsgrenze festhalten
Unsere Empfehlung: pro Anwendung eine Liste mit Dienst, Datenquelle, Verbindung, Zugang und Verantwortlichem führen. Eine Serverliste allein beschreibt weder den Datenfluss noch die Abnahme.
| Bestand | Festzuhaltende Information | Prüfpunkt im Ziel |
|---|---|---|
| Public Cloud oder Dedicated | Betriebssystem, Architektur, Dienste, persistente Pfade | Passende Laufzeit und Kapazität |
| Datenbank | Engine, Version, Erweiterungen, Rollen, Backupverfahren | Wiederherstellung und fachliche Abfragen |
| vRack und öffentliche Zugänge | Netze, Routen, erlaubte Verbindungen, DNS, Zertifikate | Erreichbarkeit nur über freigegebene Wege |
| Dateien und Objektspeicher | Schreibende Anwendungen, Metadaten, Aufbewahrung | Lesbarkeit, Rechte und Datenabgleich |
| Betrieb | Sicherung, Überwachung, Updates, Verantwortliche | Benannte Zuständigkeiten und Wiederanlauf |
Definieren Sie außerdem, was bei OVH verbleiben soll. Ein teilweise verlagertes System braucht dokumentierte Verbindungen zwischen beiden Umgebungen. Die Zielentscheidung sollte auch das Verbleiben einer Anwendung zulassen, wenn ihr Funktionsersatz noch ungeklärt ist.
vRack und Zielnetz getrennt planen
vRack verbindet OVHcloud-Dienste über ein privates Netzwerk. Daraus folgt keine übertragbare Netzkonfiguration für einen anderen Anbieter. Bei Hetzner lässt sich ein Cloud Network mit Dedicated Servern über einen vSwitch koppeln; die Dokumentation nennt dabei eine Grenze von einem vSwitch pro Network.
Unsere Ableitung für die Migration: gewünschte Verbindungen neu zeichnen und nicht nur alte VLAN-Namen übernehmen. Halten Sie je Verbindung Quelle, Ziel, Port, Namensauflösung und Freigabe fest. Prüfen Sie Netzbereiche auf Überschneidungen und planen Sie den Zugriff während des Parallelbetriebs separat. Ein Datenbankdienst soll nicht durch den Umzug unbeabsichtigt öffentlich erreichbar werden.
Für jede Änderung empfehlen wir einen Prüfpunkt: Anwendung erreicht Datenbank, Administration erreicht Zielserver, nicht freigegebene Zugriffe werden abgewiesen. Das sind Abnahmekriterien, keine hier behaupteten Testergebnisse.
Zielsystem vor der Datenkopie vorbereiten
Für einen abgegrenzten Anwendungsstack empfehlen wir eine Neuinstallation im Ziel. Das vermeidet, dass ungeprüfte Quellkonfigurationen Teil der Zielarchitektur werden. Betriebssystem, Laufzeit, Pakete, Dienstkonten, Mountpoints und Startreihenfolge werden explizit festgelegt.
Hetzners Datenmigrationsanleitung behandelt das Sichern und Kopieren von Daten und grenzt dies von der Übertragung ganzer Partitionen ab. Der Umfang dieses Artikels bleibt ebenfalls beim Anwendungs- und Datentransfer. Für ein vollständiges Systemabbild müssen Bootfähigkeit, Treiber, Dateisysteme und Netze gesondert bewertet werden.
Vor dem Transfer sollten Zugang zum Ziel, Speicherreserve und ein Wiederherstellungsweg feststehen. Übernehmen Sie Konten und Geheimnisse gezielt. Das pauschale Überschreiben der Zielverzeichnisse /etc oder /boot gehört nicht zu unserem Ablauf.
Dateien und Datenbanken getrennt übertragen
Für gewöhnliche Anwendungsdateien kann rsync über SSH eingesetzt werden. Laut rsync-Handbuch bedeutet --dry-run einen Probelauf; -a allein umfasst weder Hardlinks noch ACLs oder erweiterte Attribute. Der abschließende Slash am Quellpfad bezeichnet dessen Inhalt.
rsync -av --dry-run -e ssh /srv/app/uploads/ migration@TARGET_IP:/srv/app/uploads/
TARGET_IP, Konto und Pfade müssen ersetzt werden. Das Beispiel kopiert bei entferntem --dry-run nur den benannten Pfad, keine vollständige Maschine. Wir empfehlen, zuerst Zielpfad, Dateiliste und Berechtigungen zu prüfen. Falls die Anwendung ACLs, erweiterte Attribute oder spezielle Eigentümer benötigt, müssen die Optionen und Berechtigungen ausdrücklich dafür festgelegt werden. Ein Löschabgleich ist eine eigene Entscheidung.
Datenbanken bekommen einen getrennten Transferweg. Für PostgreSQL erzeugt pg_dump einen konsistenten Dump einer Datenbank; globale Rollendefinitionen werden dabei nicht gesichert. Für andere Engines ist das jeweilige Herstellerverfahren zu wählen. Eine laufende Datenbank einfach mit ihrem Datenverzeichnis in die Dateisynchronisation aufzunehmen, ist kein Konsistenznachweis.
Unsere empfohlene Reihenfolge: Erstübertragung der Dateien, Wiederherstellungsprobe der Datenbank, Kontrolle der Anwendung, dann ein vereinbarter Schreibstopp für den finalen Datenstand. Hintergrundjobs und externe Datenlieferungen gehören in diesen Schreibstopp, wenn sie den Bestand verändern.
Umschaltung und Rückweg definieren
Schreiben Sie vor dem Wechsel auf, welche Datenquelle nach der Umschaltung führend ist. Definieren Sie, wer Schreibzugriffe sperrt, den letzten Abgleich bestätigt und das Ziel freigibt. Ein erreichbarer Webserver allein ist noch keine fachlich abgenommene Anwendung.
Unsere Checkliste:
- Schreibende Webzugriffe, Jobs und Importe entsprechend dem Ablauf anhalten.
- Finalen Datei- und Datenbankstand übertragen und Abweichungen klären.
- Anwendung im Ziel über den vorgesehenen Hostnamen prüfen.
- DNS, externe Freigaben und Integrationen nach Plan umstellen.
- Anmeldung, Rechte, Upload und einen fachlichen Schreibvorgang abnehmen.
- Quelle erst nach Freigabe und geklärter Aufbewahrung abbauen.
Der Rückweg muss neue Zieldaten berücksichtigen. Legen Sie fest, wie diese bei einem Abbruch behandelt werden und wann die Quelle wieder schreiben darf. Diese Entscheidung ist Teil des Runbooks; sie lässt sich nicht durch einen pauschalen Verweis auf DNS ersetzen.
Kosten und Abnahme prüfen
Für die Kostenentscheidung empfehlen wir eine gemeinsame Betrachtungsperiode und dieselben Leistungsannahmen. Erfassen Sie Quellressourcen, Zielressourcen, Datenübertragung, Parallelbetrieb und anschließend benötigte Betreuung. Verwenden Sie Rechnungen und konkrete Angebote statt einer allgemeinen Sparquote.
Die Abnahme sollte Daten, Funktion und Betrieb abdecken: vereinbarte Datenbestände, Rechte, externe Integrationen, Sicherung, Überwachung und Wiederanlauf. Dokumentieren Sie erwartetes und tatsächliches Ergebnis. Dieser Artikel liefert eine Struktur, keine erfundenen Messwerte oder Migrationsdauer.
Unser Vorgehen bei WZ-IT
Die OVH-zu-Hetzner-Migration ist der passende Angebotsweg für diesen Umzug. Bei noch offener Zielwahl führt der Cloud-Exit-Check über Bestand, Kosten und Abhängigkeiten zur Entscheidung. Hetzner-Expertise ergänzt die Zielplattform.
Für eine Anfrage sind Anwendungsliste, Netzübersicht, Datenbanktyp, Datenmenge und gewünschte Betriebszuständigkeiten hilfreich. Umsetzung und anschließender Betrieb werden anhand dieses Bestands abgegrenzt.
Weiterführende Guides
- Cloud-Exit-Strategie für den Mittelstand
- AWS S3 zu Hetzner Object Storage
- DigitalOcean Droplet zu Hetzner migrieren
- Migrationsübersicht
OVH-Migration planen: Ausgangslage und Zielarchitektur abgrenzen. Termin vereinbaren.
