Linux-Server von einem anderen Anbieter ohne Neuinstallation umziehen

Sie ziehen einen Linux-Server von Ihrem bisherigen Anbieter ohne Neuinstallation auf einen Seed um. Betriebssystem, Dienste, Konten und Konfiguration kommen vollständig mit. Ausgenommen bleiben nur die Teile, die den Seed bootfähig und erreichbar halten: Kernel, Bootloader, /etc/fstab und Netzwerkkonfiguration.

Sie arbeiten dafür im Rescue-System, einem eigenständigen Live-System, das im Arbeitsspeicher läuft und die Festplatte des Seeds unangetastet lässt. Nur so lässt sich das Root-Dateisystem überschreiben, während nichts darauf läuft.

Für die meisten Umzüge ist der Weg über Linux-Server von einem anderen Anbieter in die dataforest cloud umziehen die bessere Wahl. Dort richten Sie die Dienste auf dem Seed neu ein und holen nur Ihre Daten. Das dauert länger, ist aber unkritisch und führt zu einem sauberen, aktuellen System.

Bevor Sie anfangen. Dieser Weg greift tief in das Zielsystem ein und kann den Seed unbrauchbar machen. 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.

Wann sich dieser Weg lohnt

Wenn Ihr Server über Jahre gewachsen ist und niemand mehr genau sagen kann, wie er eingerichtet wurde. Wenn viele Dienste ineinandergreifen und das Nachbauen mehr Zeit kostet als die Übertragung. Oder wenn Sie eine exakte Kopie brauchen, bis hin zu Konten und Passwörtern.

Gegen diesen Weg spricht dreierlei. Er verlangt Sicherheit auf der Kommandozeile, insbesondere beim Einhängen von Dateisystemen. Geht etwas schief, ist der Seed nach dem Neustart unter Umständen nur noch über die Konsole erreichbar. Und Sie übernehmen alle Altlasten des bisherigen Systems mit, statt sie beim Umzug loszuwerden.

Ihre Daten auf dem alten Server sind davon zu keinem Zeitpunkt betroffen. Misslingt der Versuch, spielen Sie den Snapshot zurück, den Sie vorher anlegen, und fangen von vorn an.

Was Sie brauchen

• einen alten Server mit Debian oder Ubuntu
• einen Seed mit Debian oder Ubuntu und derselben Prozessorarchitektur wie der alte Server, in aller Regel amd64
• Zugang als root auf beiden Maschinen und rsync auf dem alten Server
• ein Wartungsfenster, dessen Länge sich nach Ihrer Datenmenge richtet

Für andere Distributionen gilt diese Anleitung nicht. AlmaLinux und RockyLinux legen ihre Netzwerkkonfiguration an anderer Stelle ab, und unsere Images dieser Distributionen haben eine andere Aufteilung der Festplatte.

Dieselbe Distribution oder Version ist nicht erforderlich. Der Kernel des Seeds startet auch ein älteres System. Geprüft haben wir Debian 12 und Ubuntu 22.04 auf einem Debian-13-Seed sowie Ubuntu 24.04 auf einem Ubuntu-24.04-Seed, jeweils auch mit Updates und erneutem Neustart danach.

Eine Einschränkung betrifft aber den Betrieb danach. Weicht Ihre Distribution von der des Seeds ab, kennt Ihre Paketverwaltung den laufenden Kernel nicht und liefert dafür keine Sicherheitsupdates mehr. Für einen dauerhaft betriebenen Server ist dann der andere Weg die bessere Wahl. Stimmen Distribution und Hauptversion überein, stellt sich die Frage nicht.

Vorbereiten

Legen Sie den Seed an und lassen Sie ihn einmal vollständig starten, damit Netzwerk, Bootloader und /etc/fstab eingerichtet sind. Worauf Sie bei Größe, IPv4-Adresse und Firewall achten sollten, steht in der Hauptanleitung.

Legen Sie anschließend im Tab Snapshots einen Snapshot an, etwa mit dem Namen vor_uebertragung. Er ist Ihr Rückweg, falls der Seed nach der Übertragung nicht startet.

Erzeugen Sie dann auf dem Seed einen Schlüssel für den Umzug und hinterlegen Sie ihn auf dem alten Server, wie in der Hauptanleitung unter Die beiden Server verbinden beschrieben:

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

Er liegt danach auf der Festplatte des Seeds und steht Ihnen im Rescue-System zur Verfügung.

Halten Sie zuletzt auf dem alten Server alle Dienste an, die Daten schreiben, Datenbanken vor allem. Ab hier ruht Ihr Betrieb, bis der Seed übernimmt.

In das Rescue-System wechseln

Wechseln Sie den Seed im Tab Verwalten unter Seed-Rescue in den Rescue-Modus und bestätigen Sie mit Speichern und neu starten. Ihre SSH-Schlüssel gelten dort wie im normalen Betrieb.

Geben Sie ihm eine Minute, bevor Sie sich anmelden. Weil das Rescue-System eigene Host-Keys hat, meldet Ihr Rechner eine Abweichung. Entfernen Sie den alten Eintrag:

ssh-keygen -R <SEED-IP>
ssh root@<SEED-IP>

Dort verschaffen Sie sich mit lsblk -f einen Überblick. Sie sehen zwei Partitionen: eine kleine mit vfat, das ist die EFI-Partition, und eine große mit ext4, Ihr Root-Dateisystem. Fassen Sie die kleine nicht an, dort liegt der Bootloader. Die große ist bei unseren Debian- und Ubuntu-Images /dev/sda2.

Nur bei Debian-13-Seeds und älteren Systemen. Das Dateisystem eines Debian-13-Seeds nutzt das Feature orphan_file, das Debian 11, Ubuntu 22.04 und ältere Systeme nicht kennen. Das übertragene System startet zunächst. Sobald aber ein Update das initramfs neu erzeugt, bricht der nächste Start mit einer fehlgeschlagenen Dateisystemprüfung ab. Entfernen Sie das Feature deshalb jetzt, solange das Dateisystem nicht eingehängt ist:

e2fsck -f /dev/sda2
tune2fs -O ^orphan_file /dev/sda2

Hängen Sie dann das Root-Dateisystem ein:

mkdir -p /mnt/ziel && mount /dev/sda2 /mnt/ziel

Die Ausschlussliste

Sie ist der Kern des Verfahrens, denn an ihr hängt, ob der Seed danach noch startet und erreichbar ist. Legen Sie sie im Rescue-System an:

cat > /root/ausschluss.txt <<'ENDE'
/dev/*
/proc/*
/sys/*
/run/*
/tmp/*
/mnt/*
/media/*
/lost+found
/boot/*
/lib/modules/*
/usr/lib/modules/*
/vmlinuz*
/initrd.img*
/etc/fstab
/etc/hostname
/etc/hosts
/etc/machine-id
/var/lib/dbus/machine-id
/etc/network/interfaces
/etc/network/interfaces.d/*
/etc/netplan/*
/etc/systemd/network/*
/etc/udev/rules.d/70-persistent-net.rules
/etc/cloud/*
/var/lib/cloud/*
/etc/ssh/ssh_host_*
/root/.ssh/*
/etc/swap
/swapfile
/swap.img
ENDE

In Gruppen gelesen: Die ersten Einträge sind Verzeichnisse, die der Kernel zur Laufzeit selbst füllt. Die nächsten halten Kernel und Bootdateien des Seeds fest. Dann folgen /etc/fstab, Hostname und Netzwerkkonfiguration. Ohne diese Zeilen ist Ihr Seed nach dem Neustart nicht mehr erreichbar, weil er die Netzwerkeinstellungen des alten Servers übernähme und es bei uns kein DHCP gibt. Das gilt besonders für Server, die ohne cloud-init eingerichtet wurden. Sie tragen ihre feste IP-Adresse meist direkt in /etc/network/interfaces ein. Die letzten Einträge sichern cloud-init, die Machine-ID, die Host-Keys, Ihren eigenen Zugang und die Swap-Datei.

Die Übertragung

rsync -aAXHx --numeric-ids --delete --info=progress2 \
  -e "ssh -i /mnt/ziel/root/.ssh/migration" \
  --exclude-from=/root/ausschluss.txt \
  root@<ALT-SERVER-IP>:/ /mnt/ziel/

Führen Sie den Lauf zuerst mit --dry-run --stats aus. Dann passiert nichts, und Sie sehen an der Statistik, was geschehen würde.

-x hält rsync auf dem Root-Dateisystem, damit eingehängte Netzlaufwerke Ihres alten Servers nicht mitwandern. Liegen dort eigene Partitionen für /home oder /var, holen Sie diese anschließend einzeln. --numeric-ids ist richtig, weil Sie die Benutzerverwaltung des alten Servers mitübertragen. --delete ist nicht optional. Ohne diese Angabe bleiben Dateien des Seed-Images liegen, die es auf Ihrem alten Server nicht gibt, und Sie erhalten ein Mischsystem aus zwei Distributionen, dessen Dienste beim Start fehlschlagen. Die Einträge Ihrer Ausschlussliste bleiben davon unberührt. Meldungen wie cannot delete non-empty directory: etc/cloud sind deshalb zu erwarten und richtig.

Cloud-init erhalten

Das Panel legt ein neues root-Passwort und eine entfernte IPv4-Adresse auf dem cloud-init-Laufwerk des Seeds ab, und cloud-init übernimmt sie beim nächsten Start. Auch das Mitwachsen des Dateisystems bei einem größeren Plan läuft über cloud-init. Prüfen Sie deshalb, ob die nötigen Programme im übertragenen System vorhanden sind:

ls /mnt/ziel/usr/bin/cloud-init /mnt/ziel/usr/bin/growpart /mnt/ziel/usr/sbin/qemu-ga

Der Guest Agent (qemu-ga) gehört dazu, weil das Panel über ihn den Zustand Ihres Seeds ausliest. Fehlt eines der Programme, weil Ihr alter Server ohne cloud-init lief, installieren Sie es nach dem ersten Start. Das Netz kommt auch ohne cloud-init hoch, denn die Netzwerkkonfiguration des Seeds ist erhalten geblieben.

apt install -y -o Dpkg::Options::=--force-confold cloud-init cloud-guest-utils qemu-guest-agent

--force-confold behält die vorhandene /etc/cloud/cloud.cfg des Seeds. Ohne diese Angabe fragt apt nach, ob die Datei durch die Paketversion ersetzt werden soll. Behalten Sie sie in jedem Fall. Die Paketversion sperrt die Anmeldung als root per SSH-Schlüssel. Die übrige Konfiguration, mit der cloud-init das Laufwerk des Seeds findet, liegt bereits unter /etc/cloud/cloud.cfg.d/, weil /etc/cloud von der Übertragung ausgenommen war.

Setzen Sie zuletzt den Zustand von cloud-init zurück, damit cloud-init beim ersten Start einmal vollständig durchläuft:

rm -rf /mnt/ziel/var/lib/cloud/*

Kontrollieren und aushängen

Prüfen Sie, dass die Netzwerkkonfiguration die Adresse Ihres Seeds zeigt und nicht die des alten Servers. Auf Debian steht sie in /mnt/ziel/etc/network/interfaces.d/50-cloud-init, auf Ubuntu in /mnt/ziel/etc/netplan/50-cloud-init.yaml. Unter /mnt/ziel/boot/ muss noch ein Kernel liegen.

Kontrollieren Sie außerdem die Namensauflösung. Verweist /etc/resolv.conf auf systemd-resolved, wie bei Ubuntu üblich, ist nichts zu tun:

readlink /mnt/ziel/etc/resolv.conf

Zeigt die Ausgabe nicht auf systemd/resolve, stehen in der Datei meist noch die Nameserver Ihres bisherigen Anbieters. Viele davon antworten nur im eigenen Netz. Ersetzen Sie die Datei:

rm -f /mnt/ziel/etc/resolv.conf
printf 'nameserver 1.1.1.1\nnameserver 8.8.8.8\n' > /mnt/ziel/etc/resolv.conf

Stimmt etwas nicht, korrigieren Sie es jetzt, solange die Platte noch eingehängt ist. Dann hängen Sie aus und prüfen das Dateisystem:

sync && umount /mnt/ziel && e2fsck -n /dev/sda2

Die Ausgabe von e2fsck -n muss clean enthalten. Geprüft wird dabei nur, verändert wird nichts.

Zurückschalten

Stellen Sie im Panel wieder auf Hard-Drive-Modus und starten Sie neu. Auch hier ändern sich die Host-Keys erneut, entfernen Sie den Eintrag also wieder mit ssh-keygen -R <SEED-IP>.

Direkt nach dem Start kann die Namensauflösung einen Moment brauchen. Warten Sie eine Minute, bevor Sie daraus auf einen Fehler schließen. Mit systemctl --failed sehen Sie dann, ob etwas nicht sauber hochgekommen ist.

Was danach anders ist

Der Seed behält seinen eigenen Hostnamen und seine Netzwerkkonfiguration. Alles andere stammt vom alten Server, auch die Benutzerkonten und ihre Passwörter. Eine Ausnahme ist root. Beim ersten Start mit cloud-init erhält root das Passwort, das Sie beim Anlegen des Seeds vergeben haben. Ihr SSH-Schlüssel funktioniert weiterhin, weil /root/.ssh ausgenommen war. Den Migrationsschlüssel können Sie jetzt entfernen, auf dem Seed unter /root/.ssh/migration* und auf dem alten Server den zugehörigen Eintrag in authorized_keys.

Entfernen Sie den Kernel des Seeds nicht. Ihre Paketverwaltung kennt ihn nicht, weil er nicht aus Ihrem alten System stammt. Das ist gewollt. Installiert ein Update einen Kernel Ihrer bisherigen Distribution, startet der Seed trotzdem weiter mit seinem eigenen, solange dessen Versionsnummer höher ist. Bei einem älteren System als dem des Seeds ist das der Fall.

Wenn der Seed nicht startet

Kommt der Seed nicht hoch, erreichen Sie ihn über die Konsole im Panel und sehen dort, woran es hängt.

• Keine Netzwerkverbindung: Prüfen Sie mit ip a, ob die Adresse des Seeds gesetzt ist, und ob /etc/network/interfaces noch eine alte Adresse enthält.
• Namensauflösung schlägt fehl: Ersetzen Sie /etc/resolv.conf wie oben beschrieben.
• Start endet in der Notfall-Shell mit Fehler bei der Dateisystemprüfung: Wechseln Sie ins Rescue-System, führen Sie dort e2fsck -f /dev/sda2 und tune2fs -O ^orphan_file /dev/sda2 aus und starten Sie neu.

Lässt sich der Fehler nicht finden, spielen Sie den Snapshot zurück und beginnen von vorn.

Die Domain umstellen

Ihr System läuft jetzt auf dem Seed. Was noch fehlt, ist die Umstellung der Domain, und die läuft genauso wie beim anderen Weg. Sie testen erst unter Ihrer echten Domain, ohne die DNS-Einträge anzufassen, und schalten dann um. Beides beschreibt die Hauptanleitung in den Abschnitten zum Testen und zur DNS-Umstellung.

Lassen Sie den alten Server danach noch zwei bis vier Wochen laufen, bevor Sie ihn kündigen.