Kommst du von einem anderen Host zu Server Manager? Der Assistent Von anderem Host importieren meldet sich auf deinem alten Server an, durchsucht ihn nach WordPress-Websites, statischen Websites und Datenbanken und kopiert dann eine davon als .tar.gz-Bundle herüber. Dieses Bundle geht anschließend in den Wiederherstellungsassistenten, der den Dienst auf diesem Server tatsächlich installiert — mit deiner Freigabe bei jedem Schritt.
Die Quelle wird nur gelesen. Auf deinem alten Host wird nichts verändert. Der Assistent durchsucht ihn, kopiert nur das Nötige und trennt die Verbindung wieder. Du kannst ihn später erneut ausführen, um eine weitere Website zu migrieren.
Was kann ich migrieren?
Der Assistent erkennt drei Arten von „Dingen zum Umziehen“:
| Art | Was gefunden wird | Was hier am Ende entsteht |
|---|---|---|
| WordPress-Website | Eine wp-config.php plus erreichbare Datenbank (Zugangsdaten werden automatisch ausgefüllt, wenn lesbar) | Vollständige containerisierte WordPress-Installation mit frischer Datenbank; Medien, Plugins und Themes werden wiederhergestellt |
| Statische Website | Ein Dokumentstamm mit index.html (unter /var/www/, /home/<user>/public_html/, üblichen cPanel-Layouts …) | Der Dateibaum unter /var/www/<your-new-domain>/, ausgeliefert von Caddy |
| Datenbank | Eine MySQL- / MariaDB-Instanz, die über den SSH-Zugang der Quelle erreichbar ist | Ein neuer Datenbank-Container mit einer per mysqldump wiederhergestellten Kopie |
Nicht migriert werden: beliebige Web-Apps (Node-/Python-/PHP-Frameworks außerhalb von WordPress — nutze dafür stattdessen Aus einem Git-Repo bereitstellen), E-Mail/Postfächer, DNS-Einträge oder alles, was außerhalb der üblichen Webroot-/Datenbank-Konventionen liegt.
So erreichst du deinen alten Host — SSH oder cPanel
Der Assistent unterstützt zwei Verbindungsarten:
| Quelltyp | Wann du ihn wählen solltest |
|---|---|
| SSH-Anmeldung | Du hast Shell-Zugriff (denselben Zugang, den du mit dem Befehl ssh nutzen würdest). Die meisten Server-Anbieter stellen dir das standardmäßig bereit. |
| cPanel API | Du hast nur cPanel und kein SSH (typisch bei Shared Hosting). Nutzt statt eines Linux-Logins ein API-Token von cPanel. |
Wenn du unsicher bist, versuche zuerst SSH — das ist der unkompliziertere Weg. Wechsle den Tab, wenn die Verbindung fehlschlägt oder dein Host nur cPanel anbietet.
Schritt für Schritt
Obere Leiste → Menü → Von anderem Host importieren.
Wähle den Quelltyp aus, trage die Zugangsdaten ein und klicke auf Quelle scannen.
Im Modus SSH-Anmeldung brauchst du: Host (IP oder Domain des alten Servers), Port (normalerweise 22), Benutzername (root, ubuntu, dein cPanel-Benutzer usw.) und entweder ein Passwort oder einen privaten OpenSSH-Schlüssel. Sind dieselben Zugangsdaten bereits als Server in Server Manager gespeichert? Klicke auf Zugangsdaten von einem gespeicherten Server verwenden, um sie von dort vorauszufüllen.
Im Modus cPanel API brauchst du: die vollständige cPanel-URL (inklusive Port — normalerweise https://your-domain:2083), deinen cPanel-Benutzernamen und ein API-Token. Das Token bekommst du in cPanel → Suche nach „API-Token verwalten“ → Erstellen — cPanel zeigt es nur einmal an, also kopiere es sofort und füge es direkt ein.
Was der Assistent mit Zugangsdaten macht. Sie bleiben nur in dieser Browser-Sitzung und werden per HTTPS direkt an die Quelle gesendet. Wir schreiben sie nicht auf die Festplatte dieses Servers und speichern sie nicht zwischen Assistentenläufen.
Der Assistent meldet sich an der Quelle an und durchsucht etwa 10–30 Sekunden lang die üblichen Web- und Datenbankpfade. Alles Erkannte wird nach Art gruppiert.
Wähle ein Element für diesen Migrationslauf aus (Mehrfachauswahl gibt es noch nicht — öffne den Assistenten für das nächste Element erneut). Die ausgewählte Karte bekommt einen pfirsichfarbenen Rahmen.
Wenn der Scan nichts findet, zeigt dir der Assistent, welche Wurzelverzeichnisse geprüft wurden, plus eventuelle Warnungen (Berechtigungsfehler, nicht lesbare wp-config usw.). Passe die Zugangsdaten zur Quelle oder die Pfadstruktur an, falls das fehlende Element in einem nicht standardmäßigen Wurzelverzeichnis liegt.
Dieser Schritt hängt von der Art ab:
- WordPress → wähle die Domain aus, unter der die migrierte Website gehostet werden soll (das kann dieselbe wie bisher sein — DNS stellst du danach um — oder eine ganz neue), und bestätige die DB-Zugangsdaten (aus
wp-config.phpvorausgefüllt, wenn lesbar). - Statische Website → wähle optional eine Domain aus. Lass das Feld leer, um die Website vorerst über die IP deines Servers bereitzustellen; du kannst später im Dienst-Panel eine Domain anhängen.
- Datenbank → wähle einen Titel für die neue Datenbank auf diesem Server und überschreibe (selten nötig) die
mysqldump-Zugangsdaten.
Klicke auf Import starten.
Server Manager holt die Daten von der Quelle und erstellt auf diesem Server ein Bundle im Server-Manager-Format. Fortschrittszeilen werden in Echtzeit aktualisiert (Archiv erstellen, übertragen, Hash berechnen usw.). Auf der Quellseite wird nur gelesen — keine Schreibvorgänge, keine zurückgelassenen temporären Dateien.
Schließe den Dialog nicht während des Imports. Wenn du das tust, wird die laufende Übertragung abgebrochen und du musst neu starten. Aufräumen passiert automatisch — Teildateien unter /tmp/helm-restore/ auf diesem Server werden innerhalb von 24 Stunden entfernt. Wenn etwas fehlschlägt, kannst du sie auch direkt auf dem Fehlerbildschirm bereinigen.Sobald das Bundle erstellt ist, schließt sich der Migrationsdialog und der Wiederherstellungsassistent öffnet sich mit dem gerade angekommenen Bundle vorausgewählt. Das ist derselbe Dialog, den der Ablauf Auf einen anderen Server umziehen nach der Ankunft verwendet — mit demselben Ein-Klick-Button Dieses Bundle wiederherstellen.
Klicke auf Dieses Bundle wiederherstellen und der Chat übernimmt: Faro liest das Manifest, startet die Installation auf diesem Server und hält bei jedem Befehl für deine Freigabe an — docker compose up, die Caddyfile-Bearbeitung, wp search-replace, falls sich die Domain geändert hat, usw.
Wenn der Vorgang abgeschlossen ist, erscheint die migrierte Website als Workload-Karte auf deinem Startbildschirm — genau wie alles andere, was du hier nativ bereitgestellt hast.
Wenn du für das Ziel eine neue Domain verwendet hast, bist du fertig — Caddy stellt innerhalb von etwa 30 Sekunden ein TLS-Zertifikat dafür aus und die Website ist live.
Wenn du dieselbe Domain wie auf dem alten Host verwendet hast, lief die Migration gegen die IP deines alten Servers. Um den Traffic umzuziehen, aktualisiere den A-Record bei deinem DNS-Anbieter, sodass er auf diesen Server zeigt. Innerhalb der DNS-Ausbreitungszeit (meist 1–10 Minuten) wandert der Traffic zur migrierten Kopie, und Caddy erneuert das Zertifikat unter der neuen IP automatisch. Die alte Installation auf der Quelle bedient dieselbe Domain weiter, bis DNS aufgeholt hat; sobald du mit der Migration zufrieden bist, kannst du sie auf der Quellseite abschalten.
DNS-Hinweis auf dem Abschlussbildschirm. Der Assistent zeigt einen Hinweis an, wenn die Zieldomain noch nicht hierher zeigt — Caddy kann erst ein HTTPS-Zertifikat holen, wenn DNS angekommen ist. Auch der Wiederherstellungsschritt hält an und sagt dir Bescheid, falls DNS noch nicht eingerichtet ist.
Häufige Fragen
Ist meine Website während der Migration offline? Nein — die Quelle bedient den Traffic die ganze Zeit weiter. Die Migration kopiert nur. Ausfallzeit entsteht höchstens in dem Moment, in dem du DNS umstellst (oder gar nicht, wenn du auf dem neuen Server eine neue Domain verwendest).
Was ist mit Plugins / Themes / eigenem Code in WordPress? Wird gebündelt. Die Migration erfasst die WordPress-Dateien (Themes, Plugins, Uploads) UND die Datenbank in einem konsistenten Snapshot. Nach der Wiederherstellung verhält sich die Website identisch — gleicher Inhalt, gleiche URLs (oder umgeschriebene URLs, wenn du eine andere Domain gewählt hast).
Meine Datenbank ist größer als der freie Speicherplatz auf der Quelle. So funktioniert es nicht — mysqldump braucht auf der Quelle kurzzeitig freien Platz in der Größe des Dumps. Schaffe zuerst etwas Platz auf der Quelle oder migriere manuell über SQL-Dumps (Dump herunterladen → hier über Aus einem Backup wiederherstellen hochladen).
Kann ich von etwas anderem als SSH/cPanel migrieren? Aktuell nein — die Scan-/Probe-Logik kennt nur diese beiden Zugangswege. Für andere Panels (Plesk, DirectAdmin usw.) ist der Weg: Melde dich per SSH manuell an der Quelle an, packe dein Webroot mit tar, exportiere deine Datenbank mit mysqldump, verpacke alles in eine .tar.gz, die zum Backup-Bundle-Layout passt, und importiere sie über Aus einem Backup wiederherstellen. Wenn du die genaue Spezifikation des Bundle-Formats brauchst, um eines von Hand zu bauen, frag über Kontakt nach — wir teilen sie mit dir.
Was passiert, wenn die Migration auf halbem Weg fehlschlägt? Der Fehlerbildschirm bietet einen Ein-Klick-Button Jetzt bereinigen, der alle teilweise geschriebenen Staging-Verzeichnisse unter /tmp/helm-restore/ entfernt. Auf der Quellseite wurde nichts verändert. Du kannst den Assistenten sicher von vorn erneut ausführen.
Wird eine bestehende Website an diesem Ziel überschrieben? Nur wenn du das im Wiederherstellungsschritt ausdrücklich akzeptierst. Standardmäßig installiert die Chat-Übergabe nebeneinander — du würdest „auf neue Domain klonen“ wählen (oder bei Datenbanken „daneben klonen“ mit einem Suffix), wenn am Ziel bereits ein Workload existiert.
Bleibt nach der Migration etwas auf der Quelle zurück? Keine Artefakte, die wir hinzufügen. Der Assistent macht nur Lese-Aufrufe; das Einzige, was auf der Quelle schreibt, ist mysqldump (bei WordPress- und Datenbankmigrationen). Dabei entsteht eine Datei, die der Assistent sofort herunterlädt und löscht. Nachdem der Assistent die Verbindung getrennt hat, ist die Quelle im selben Zustand wie vorher.
Secrets — werden sie wiederverwendet oder rotiert? Das DB-Passwort aus wp-config.php wird verwendet, um mysqldump auf der Quelle auszuführen, und danach verworfen. Die wiederhergestellte Website startet mit frischen Datenbank-Zugangsdaten, die bei der Chat-Übergabe generiert werden — keine Zugangsdaten von der Quelle gelangen in die neue Installation.
Was hier NICHT enthalten ist
- Bundle-zu-Bundle-Wiederherstellung (du hast bereits eine
.tar.gz, die irgendwo anders exportiert wurde) → siehe direkt Aus einem Backup wiederherstellen. - Server-zu-Server-Umzug innerhalb von Server Manager (Quelle und Ziel werden beide von Helm verwaltet) → siehe Backups → Auf einen anderen Server umziehen. Dieser Weg ist effizienter: kein Probe-Schritt, keine Rekonstruktion des Manifests.
- Engine-Wechsel (du nutzt nginx/Apache und möchtest hier Caddy) → siehe Zu Caddy migrieren. Das ist ein anderes Problem; dieser Ablauf schreibt Konfigurationen direkt um und holt kein Bundle.
- E-Mail + DNS → nicht enthalten. Richte beides separat über Domain verbinden und E-Mail für deine Domain einrichten ein.
Referenz
Quellpfade, die der SSH-Scan prüft:
/var/www/*/— üblicher Nginx- / Apache-vhost-Stamm/srv/www/*/— Alternative im Debian-Stil/home/*/public_html/— Dokumentstamm im cPanel-Stil/home/*/domains/*/public_html/— Dokumentstamm im DirectAdmin-Stil- WordPress: jeder der oben genannten Pfade, der eine
wp-config.phpenthält - Datenbanken: aufgelistet über
mysql -e "SHOW DATABASES"unter Verwendung von~/.my.cnfdes SSH-Benutzers, falls vorhanden
Verwendete cPanel-Scan-Endpunkte:
WebVhosts(vhost-Dokumentstämme auflisten)MysqlFE/listdbs(Datenbanken auflisten)- Dateibaum-Prüfung pro vhost auf
wp-config.php
Staging auf der Festplatte während der Migration:
- Quellseite: temporärer mysqldump unter
/tmp/, danach sofort gelöscht - Dieser Server:
/tmp/helm-restore/<id>/<bundle>.tar.gz— derselbe Pfad, den der Wiederherstellungsassistent verwendet
Bundle-Format: das eigene Format von Server Manager, austauschbar mit dem, was der Backup-Tab erzeugt — eine Migration mit anschließender Wiederherstellung ist also Byte für Byte identisch mit einem Backup mit anschließender Wiederherstellung (der Unterschied ist nur, woher das Bundle stammt).