Linux-Server von einem anderen Anbieter in die dataforest cloud umziehen

Beim Umzug von Ihrem bisherigen Anbieter richten Sie die Dienste auf einem Seed neu ein, holen Ihre Daten vom alten Server ab, testen alles unter Ihrer echten Domain und stellen zuletzt die DNS-Einträge um. Der alte Server läuft bis dahin unverändert weiter und bleibt Ihre Rückfallebene. Ob er bei einem anderen Cloud-Anbieter, als Root-Server oder auf eigener Hardware läuft, spielt keine Rolle.

Wie lange der Umzug dauert, bestimmt vor allem Ihre Datenmenge. Ausfallen muss Ihre Anwendung nur für die letzte Synchronisation. In unserem Testumzug einer PHP-Anwendung mit MariaDB dauerte er unter einer Sekunde, bei größeren Datenbanken sind es einige Minuten.

Bevor Sie anfangen. Sie brauchen Root-Zugang zu beiden Servern und sollten sich auf der Kommandozeile sicher bewegen. Sie arbeiten mit Root-Rechten auf Ihren eigenen Systemen, die Umsetzung liegt in Ihrer Verantwortung. Prüfen Sie jeden Befehl, bevor Sie ihn absetzen, und sorgen Sie vorab für eine Sicherung Ihrer Daten.

Der Umzug besteht aus fünf Schritten:

1. Überblick verschaffen und einen passenden Seed anlegen
2. Die Dienste dort installieren
3. Daten und Datenbanken übertragen
4. Unter Ihrer echten Domain testen
5. Die DNS-Einträge umstellen

Wir empfehlen diesen Weg, weil Sie am Ende ein sauberes, aktuelles System haben. Ist Ihr Server über Jahre gewachsen und lässt sich kaum noch nachbauen, können Sie ihn auch ohne Neuinstallation umziehen, samt Betriebssystem und Konfiguration. Das beschreibt die Anleitung Linux-Server von einem anderen Anbieter ohne Neuinstallation umziehen. Dieser Weg ist aufwendiger und riskanter.

Vorbereitung: den alten Server verstehen

Bevor Sie irgendetwas anlegen, verschaffen Sie sich einen Überblick. Die folgenden Befehle laufen auf dem alten Server und beantworten die Fragen, die später zählen.

systemctl list-units --type=service --state=running   # Was läuft?
ss -tulpn                                             # Auf welchen Ports?
df -h /                                               # Wie viel ist belegt?
du -sh /var/www /home /srv /opt /var/lib/mysql 2>/dev/null   # Wo liegen die Daten?
ls /etc/cron.d/ /var/spool/cron/crontabs/ 2>/dev/null # Was läuft zeitgesteuert?
systemctl list-timers --no-pager                      # Und was über systemd?

Haben Sie weitere Datenträger eingehängt, zeigt df -h ohne Pfadangabe alle an. Deren Inhalte müssen ebenfalls mit.

Wissen Sie ohnehin, was auf Ihrem Server läuft, genügt das. Sind Sie unsicher, welche Pakete hinter den Diensten stecken, ordnet diese Schleife beides einander zu. Sie funktioniert auf Debian und Ubuntu ebenso wie auf AlmaLinux, RockyLinux oder CentOS:

for s in $(systemctl list-units --type=service --state=running --no-legend --no-pager | awk '{print $1}'); do
  f=$(systemctl show -p FragmentPath --value "$s")
  p=$(dpkg -S "$f" 2>/dev/null | cut -d: -f1)
  [ -z "$p" ] && p=$(rpm -qf --qf '%{NAME}' "$f" 2>/dev/null)
  [ -n "$p" ] && printf "%-26s %s\n" "$s" "$p"
done

Einträge wie systemd, udev, dbus, cron oder openssh-server gehören zum Grundsystem und können Sie übergehen. Übrig bleibt die Liste dessen, was Ihren Server ausmacht. Notieren Sie sich auch die Versionsnummern, etwa von PHP oder der Datenbank. Weichen sie auf dem Seed ab, müssen Sie Pfade in Konfigurationsdateien anpassen.

Den passenden Seed anlegen

Betriebssystem. Zur Auswahl stehen Debian, Ubuntu LTS, AlmaLinux und RockyLinux. Nehmen Sie die aktuelle Version Ihrer gewohnten Distribution.

Größe. Richten Sie sich nach dem belegten Speicher Ihres alten Servers, nicht nach dessen Plattengröße, und rechnen Sie Reserve dazu. Den Plan können Sie später vergrößern, ohne Daten zu verlieren. Der Seed startet dafür einmal neu, und die Festplatte lässt sich danach nicht mehr verkleinern.

IPv4-Adresse. Jeder Seed erhält kostenfrei ein IPv6-Subnetz, eine IPv4-Adresse buchen Sie unter den Erweiterungen dazu. Für eine öffentlich erreichbare Anwendung brauchen Sie sie fast immer, denn ein großer Teil Ihrer Besucher hat noch kein IPv6. Buchen Sie die Adresse gleich bei der Erstellung dazu, dann wird sie automatisch im Betriebssystem eingerichtet. Eine später ergänzte Adresse müssen Sie von Hand konfigurieren, auch nach einem Neustart.

Firewall. Legen Sie unter Netzwerk › Firewalls eine Firewall an und weisen Sie sie dem Seed gleich zu, bevor Ihre Daten dort liegen. Das Panel schlägt eingehend SSH und Ping vor. Ergänzen Sie die Ports aus Ihrer Bestandsaufnahme, bei einem Webserver also 80 und 443. Datenbanken gehören nicht dazu, die sollen von außen unerreichbar bleiben. Die ausgehenden Regeln für alle Ports, die das Panel ebenfalls anlegt, lassen Sie stehen. Eine Firewall lässt nur durch, was eine Regel ausdrücklich erlaubt. Ohne ausgehende Regeln erreicht der Seed weder Ihren alten Server noch Paketquellen oder Mailserver.

Auf AlmaLinux und RockyLinux läuft zusätzlich firewalld im Betriebssystem und lässt nur SSH durch. Geben Sie dort die Dienste auch lokal frei:

firewall-cmd --permanent --add-service=http --add-service=https
firewall-cmd --reload

Zugang und Sicherungen. Hinterlegen Sie einen SSH-Schlüssel und aktivieren Sie die automatischen Backups.

Der Benutzer ist bei allen unseren Images root:

ssh root@<SEED-IP>

Die beiden Server verbinden

Alle Übertragungen starten Sie auf dem Seed und holen die Daten vom alten Server ab. So bleiben alle Befehle an einem Ort, und auf Ihrem neuen Server bleibt später kein fremder Zugang zurück.

Erzeugen Sie auf dem Seed einen Schlüssel für den Umzug:

ssh-keygen -t ed25519 -C "migration" -f /root/.ssh/migration -N ""

Erlaubt der alte Server die Anmeldung per Passwort, hinterlegen Sie den Schlüssel mit ssh-copy-id -i /root/.ssh/migration.pub root@<ALT-SERVER-IP>. Viele Server lassen root aber nur mit Schlüssel herein. Dann geben Sie den Schlüssel auf dem Seed mit cat /root/.ssh/migration.pub aus und hängen die Zeile auf dem alten Server an:

echo 'ssh-ed25519 AAAA… migration' >> /root/.ssh/authorized_keys

Prüfen Sie die Verbindung vom Seed aus:

ssh -i /root/.ssh/migration root@<ALT-SERVER-IP> hostname

Kommt keine Antwort, blockiert meist eine Firewall vor dem alten Server oder ein Schutz wie fail2ban die Verbindung. Geben Sie dort SSH für die IP-Adresse Ihres Seeds frei.

Zum Schluss braucht es auf beiden Seiten rsync. Unsere Ubuntu-, AlmaLinux- und RockyLinux-Images bringen es mit, bei Debian installieren Sie es nach. Auf dem alten Server fehlt es häufig ebenfalls.

apt install -y rsync    # Debian, Ubuntu
dnf install -y rsync    # AlmaLinux, RockyLinux, CentOS

Dienste einrichten und Daten übernehmen

Sie installieren auf dem Seed die Dienste aus Ihrer Bestandsaufnahme und holen anschließend nur das, was wirklich Ihnen gehört. Das sind Anwendungsdaten, Datenbankinhalte, Zertifikate und Ihre eigenen Konfigurationsdateien.

Benutzer zuerst. Läuft Ihre Anwendung unter einem eigenen Benutzer, legen Sie ihn auf dem Seed mit demselben Namen an, bevor Sie Dateien übertragen:

useradd -m -s /bin/bash <BENUTZER>

rsync ordnet Dateien dann über den Namen richtig zu, auch wenn der Benutzer auf dem Seed eine andere Nummer (UID) bekommt. Fehlt der Benutzer, gehören die Dateien danach einer bloßen Nummer.

Dateien holen Sie mit rsync. Der Befehl läuft auf dem Seed:

rsync -aAX --info=progress2 -e "ssh -i /root/.ssh/migration" \
  root@<ALT-SERVER-IP>:/pfad/zu/den/daten/ /pfad/zu/den/daten/

Achten Sie auf die Schrägstriche am Ende beider Pfade. Sie sorgen dafür, dass der Inhalt übertragen wird und nicht das Verzeichnis in sich selbst hinein. Den Befehl können Sie beliebig oft wiederholen. Beim zweiten Lauf überträgt er nur noch, was sich geändert hat, und genau das nutzen Sie später bei der Umstellung.

Zertifikate. Nutzen Sie Let's Encrypt, übernehmen Sie /etc/letsencrypt als Ganzes, einschließlich der symbolischen Links darin:

rsync -aAX -e "ssh -i /root/.ssh/migration" \
  root@<ALT-SERVER-IP>:/etc/letsencrypt/ /etc/letsencrypt/

Ihre Webserver-Konfiguration verweist auf diese Dateien, ohne sie startet nginx nicht. Mit den übernommenen Zertifikaten funktioniert HTTPS auf dem Seed schon beim Test und direkt nach der Umstellung. Das certbot-Paket installieren Sie auf dem Seed wie jeden anderen Dienst, die Erneuerung läuft danach dort weiter.

Datenbanken kopieren Sie niemals als Dateien. Während der Dienst läuft, schreibt er ständig, und eine Dateikopie wäre in sich widersprüchlich. Erzeugen Sie stattdessen einen Dump, bei MariaDB und MySQL etwa so:

ssh -i /root/.ssh/migration root@<ALT-SERVER-IP> \
  "mysqldump --single-transaction --routines --triggers --events --databases <DATENBANK>" \
  > /root/dump.sql

Auf zwei Dinge kommt es dabei an, unabhängig davon, welches Datenbanksystem Sie einsetzen. Der Dump muss einen einheitlichen Stand abbilden, ohne die laufende Anwendung zu blockieren. Das leistet oben --single-transaction. Und er muss vollständig sein. Die drei übrigen Optionen nehmen gespeicherte Prozeduren, Trigger und geplante Ereignisse mit, die sonst stillschweigend fehlen würden. Solche Lücken fallen erst Wochen später auf, denn der Dump läuft ohne Fehlermeldung durch.

Prüfen Sie vor dem Einspielen, dass der Dump vollständig geschrieben wurde. Bei mysqldump lautet die letzte Zeile -- Dump completed on …. Eingespielt wird er anschließend auf dem Seed mit mysql < /root/dump.sql.

Ein Dump enthält die Daten, aber nicht die Benutzerkonten. Ohne sie kann sich Ihre Anwendung nicht anmelden, obwohl alle Tabellen da sind. Am einfachsten übernehmen Sie das Konto samt Rechten und Passwort direkt vom alten Server:

ssh -i /root/.ssh/migration root@<ALT-SERVER-IP> \
  "mysql -N -e \"SHOW CREATE USER '<DB-BENUTZER>'@'localhost'; SHOW GRANTS FOR '<DB-BENUTZER>'@'localhost';\"" \
  | sed 's/$/;/' > /root/benutzer.sql
mysql < /root/benutzer.sql

Das Passwort wandert dabei nur als Hash mit, und die Konfiguration Ihrer Anwendung bleibt unverändert gültig.

MySQL und MariaDB sind nicht in jeder Richtung austauschbar. Debian liefert MariaDB aus, viele ältere Server laufen mit MySQL 8. Einen MySQL-8-Dump spielt die MariaDB von Debian 13 ohne Anpassung ein. Die ältere MariaDB von Debian 12 bricht dagegen mit Unknown collation: 'utf8mb4_0900_ai_ci' ab. Dort ersetzen Sie die Collation vor dem Einspielen:

sed -i 's/utf8mb4_0900_ai_ci/utf8mb4_unicode_ci/g' /root/dump.sql

Benutzerkonten aus MySQL 8 nutzen standardmäßig das Verfahren caching_sha2_password, das MariaDB nicht kennt. Legen Sie das Konto in diesem Fall mit dem Passwort aus der Konfiguration Ihrer Anwendung neu an.

Konfigurationsdateien holen Sie gezielt, niemals als ganzes Verzeichnis. Wer /etc oder /etc/nginx komplett kopiert, überschreibt die Grundeinstellungen des Seeds. Nehmen Sie stattdessen einzelne Dateien mit: Ihre vHost-Konfigurationen, PHP-Pools und eigenen systemd-Einheiten. Prüfen Sie danach die Pfade darin. Wenn etwa die PHP-Version abweicht, zeigen Verweise auf deren Socket ins Leere. Auch die alte IP-Adresse steckt gern in Konfigurationen. Diese Suche auf dem Seed findet beides:

grep -rn -e "<ALT-SERVER-IP>" -e "php<ALTE-VERSION>" /etc /var/www /srv 2>/dev/null

Cronjobs übernehmen Sie noch nicht. Sie würden sonst auf beiden Servern gleichzeitig laufen, Mails doppelt verschicken oder Daten doppelt verarbeiten. Sie kommen erst bei der Umstellung dazu.

Testen, bevor die Domain umzieht

Hier prüfen Sie den Seed unter Ihrer echten Domain, ohne die DNS-Einträge anzufassen. Tragen Sie dazu auf Ihrem eigenen Rechner in /etc/hosts (unter Windows C:\Windows\System32\drivers\etc\hosts) eine Zeile ein:

<SEED-IP>    ihre-domain.de www.ihre-domain.de

Nur Ihr Rechner sieht damit den neuen Server, alle anderen weiterhin den alten. Weil die Zertifikate schon auf dem Seed liegen, funktioniert auch HTTPS. Arbeiten Sie durch, was Ihre Anwendung können muss: anmelden, speichern, hochladen, Formulare abschicken. Ein Blick in die Protokolle des Seeds gehört dazu. Entfernen Sie die Zeile wieder, wenn Sie fertig sind.

Solange hier etwas klemmt, ändern Sie nichts an der Domain.

DNS umstellen

Setzen Sie ein bis zwei Tage vorher die TTL Ihrer DNS-Einträge auf 300 Sekunden herunter. Die TTL sagt anderen Servern, wie lange sie sich eine Antwort merken dürfen. Ein niedriger Wert sorgt dafür, dass die Umstellung schnell überall ankommt. Warten Sie dabei die alte TTL ab: Stand dort ein Tag, wirkt die Verkürzung auch erst nach einem Tag.

Verschickt Ihre Anwendung selbst Mails, ergänzen Sie in derselben Zeit den SPF-Eintrag Ihrer Domain um die IP-Adresse des Seeds. Sonst landen Mails vom neuen Server im Spam oder werden abgewiesen. Die alte Adresse entfernen Sie erst nach dem Umzug.

Am Umzugstag gehen Sie in dieser Reihenfolge vor:

1. Webserver, Anwendungsdienste und Cron auf dem alten Server anhalten, damit keine neuen Daten mehr hineinlaufen. Die Datenbank läuft weiter, sie wird für den letzten Dump gebraucht.
2. Letzte Synchronisation der Dateien, derselbe rsync-Befehl wie zuvor, jetzt mit --delete, damit auch gelöschte Dateien verschwinden
3. Letzter Datenbank-Dump und Einspielen auf dem Seed. Datenbanken werden immer vollständig übertragen, hier gibt es keinen inkrementellen Weg.
4. Cronjobs auf dem Seed einrichten
5. DNS umstellen: A-Eintrag auf die IPv4-Adresse des Seeds und einen vorhandenen AAAA-Eintrag auf dessen IPv6-Adresse. Bleibt der alte AAAA-Eintrag stehen, landen Besucher mit IPv6 weiter auf dem alten Server. Denken Sie auch an Subdomains und weitere Einträge, die auf die alte Adresse zeigen.
6. Prüfen mit dig +short ihre-domain.de A und dig +short ihre-domain.de AAAA und im Browser

Danach setzen Sie die TTL wieder hoch.

Falls Sie zurückmüssen

Solange der alte Server unverändert bereitsteht, ist der Rückweg kurz: Sie stellen die DNS-Einträge zurück. Alles, was seit der Umstellung auf dem Seed entstanden ist, fehlt dem alten Server dann allerdings. Holen Sie es vorher in umgekehrter Richtung zurück, mit angehaltenem Webserver auf dem Seed:

mysqldump --single-transaction --routines --triggers --events --databases <DATENBANK> \
  | ssh -i /root/.ssh/migration root@<ALT-SERVER-IP> mysql
rsync -aAX -e "ssh -i /root/.ssh/migration" /pfad/zu/den/daten/ root@<ALT-SERVER-IP>:/pfad/zu/den/daten/

Anschließend starten Sie die Dienste auf dem alten Server wieder.

Nacharbeiten

Zertifikate. Sobald die Domain auf den Seed zeigt, prüfen Sie mit certbot renew --dry-run, dass die Erneuerung dort funktioniert.

Sicherungen. Prüfen Sie, dass die erste Sicherung durchgelaufen ist.

Den alten Server behalten. Lassen Sie ihn zwei bis vier Wochen laufen, bevor Sie kündigen. Erfahrungsgemäß fällt erst nach einigen Tagen auf, dass eine Kleinigkeit fehlt. Entfernen Sie danach den Migrationsschlüssel aus /root/.ssh/authorized_keys auf dem alten Server und die Schlüsseldateien /root/.ssh/migration* auf dem Seed.

Vor der Kündigung. Ist Ihre Domain oder deren DNS-Verwaltung Teil des bisherigen Vertrags, endet sie mit der Kündigung. Ziehen Sie die Domain vorher zu einem Registrar Ihrer Wahl um oder lösen Sie sie aus dem Vertrag. Dasselbe gilt für Postfächer, die beim bisherigen Anbieter liegen.

Sonderfälle in Kürze

Andere Datenbanken als MariaDB und MySQL migrieren Sie nach demselben Muster: Dump erzeugen, übertragen, einspielen, Benutzerkonten neu anlegen. Welche Werkzeuge Ihr System dafür mitbringt, beschreibt dessen Dokumentation, bei PostgreSQL etwa das Kapitel Backup and Restore.

Docker und Docker Compose: Übertragen Sie die compose.yml, die .env und die Verzeichnisse hinter Ihren Volumes. Die Images wandern nicht mit, die lädt der Seed beim ersten Start frisch. Datenbanken in Containern behandeln Sie wie oben, mit einem Dump statt einer Dateikopie.

Mailserver brauchen über den Umzug hinaus einen passenden PTR-Eintrag, den Sie im Panel bei den IP-Adressen des Seeds setzen. Außerdem müssen sie sich ihren Ruf bei den Empfängern neu erarbeiten. Planen Sie mehr Zeit ein und stellen Sie die MX-Einträge erst um, wenn der Versand nachweislich funktioniert. Postfächer übertragen Sie über IMAP, etwa mit imapsync, und vergleichen danach die Zahl der Mails je Ordner.

Server-Panels wie Plesk oder cPanel bringen eigene Umzugswerkzeuge mit. Nutzen Sie diese, statt die Dateien am Panel vorbei zu kopieren.

Gewachsene Server, deren Einrichtung sich kaum noch nachvollziehen lässt, können Sie auch ohne Neuinstallation umziehen, samt Betriebssystem und Konfiguration. Der Weg steht in der Anleitung Linux-Server von einem anderen Anbieter ohne Neuinstallation umziehen. Die rohe Festplatte zu klonen, etwa mit dd, führt dagegen nicht zum Ziel. Ein solcher Klon startet auf einem Seed in aller Regel nicht.

Windows Server können Sie bei uns nicht als Image auswählen, sondern nur selbst von einer ISO installieren, mit eigener Lizenz. Den Ablauf beschreibt die Anleitung Windows Server über eine ISO selbst installieren.