Servermigration mit dd über SSH
Immer mal wieder möchte ich Server "am Stück" migrieren, also wie als würde ich die Festplatte aus dem alten Server entfernen und in den neuen Server einstecken. Das ist nicht nur sehr komfortabel (es müssen nicht die Daten jeder Anwendung einzeln migriert werden), sondern insgesamt häufig auch schneller als eine manuelle Migration.
Im Blogartikel "Snapshots von Servern anfertigen (dd über ssh)" habe ich schon darüber geschrieben, wie schön mit dd über SSH Snapshots erstellt werden können. In diesem Blogartikel dokumentiere ich, wie mit dd über SSH ganze Servermigrationen ablaufen können.
Hierbei nutzen wir zstd
(Zstandard) zur Kompression - ein von Facebook entwickelter verlustfreier Kompressionsalgorithmus, welcher bereits mit Standardeinstellungen ein fantastisches Verhältnis zwischen Kompressionsgrad und Ressourcenverbrauch mitbringt. Die Kompression beschleunigt die Übertragung insbesondere dann, wenn die Disk nicht voll ist.
Voraussetzungen
Wir haben zwei Systeme: Server A (altes System, Beispiel-IP: 10.10.10.1) und Server B (neues System, Beispiel-IP: 10.20.20.2). Diese Server können sowohl physisch, als auch virtualisiert sein. Mindestens ein System muss aber direkt (also ohne NAT oder mit NAT und Port-Forwarding) vom anderen System erreichbar sein. Bei beiden Systemen ist die Disk unter /dev/sda
verfügbar - falls nein, müssen die Commands entsprechend angepasst werden. Die Disk des alten Servers muss exakt gleich groß oder kleiner sein als die Disk des neuen Servers. Beide Systems müssen in ein "Rettungssystem", Live-System von USB o.ä. gebootet sein. Zudem muss eine SSH-Verbindung über den User root
möglich sein.
Grundlagen
Auf beiden Systemen (also im Live-System / Rettungssystem) müssen die Binaries dd
, zstd
und pv
verfügbar sein. Unter Ubuntu und Debian ist dd
im Paket coreutils
enthalten. zstd
und pv
lassen sich bei Ubuntu und Debian über sudo apt install zstd pv
installieren.
Variante 1: Migration vom neuen System aus
ssh root@10.10.10.1 "dd bs=4M if=/dev/sda | zstd -" | zstd -d | pv | dd bs=4M of=/dev/sda
Mit dem Command wird eine SSH-Verbindung zum alten Server aufgebaut. Auf dem System wird die Disk /dev/sda
per dd
ausgelesen und der Datenstream mit zstd
komprimiert. Der Datenstream wird über SSH übertragen und auf dem neuen System wieder dekomprimiert. Die Nutzung von pv
ermöglicht eine Statusanzeige (s. Screenshot unten). Letztlich werden die Daten dann wieder mit dd
auf /dev/sda
geschrieben.
Variante 2: Migration vom alten System aus
Das Prinzip vom alten System aus ist das Selbe, nur die Richtung ist umgekehrt (und der Command dadurch etwas anders):
dd bs=4M if=/dev/sda | pv | zstd - | ssh root@10.20.20.2 "zstd -d | dd bs=4M of=/dev/sda"
Weitere Abwandlungen
Wird keine Statusanzeige benötigt, kann pv
auch weggelassen werden.
Wird keine Kompression erwünscht, können die zstd
-Teile auch entfernt werden. Gerade wenn die Disk nicht komplett voll ist, lohnt sich die Kompression nach meiner Erfahrung auch bei guter Bandbreite (z.B. 2,5 Gbit) zwischen den Systemen!
Nachbereitung
Nach der Migration benötigt es noch einige Anpassungen im neuen System. Je nach Konfiguration muss z.B. angepasst werden:
- DNS-Server: ggf. sind anbieterspezifische DNS-Server hinterlegt, die außerhalb des Anbieternetzes nicht erreichbar sind
- IP-Adressen: falls kein DHCP genutzt wird, muss die IP-Adresse, Subnetzmaske, Gateway, ... angepasst werden
- Interfaces: je nach verwendeten Treibern kann die Bezeichnung des Interfaces abweichen
- fstab: Falls unter
/etc/fstab
keine UUIDs genutzt werden und sich die Bezeichnung der Disk geändert hat (z.B. vonsda
zuvda
) muss diese Änderung hier nachgezogen werden - Partitionen: Falls die Disk des neuen Systems größer ist, kann es nachträglich leicht z.B. mit gparted vergrößert werden.
Diese Anpassungen lassen sich noch im Rettungssystem auf dem neuen System durchführen. Mit dem Command fdisk -l
kann man die Disks mit den Partitionen anzeigen lassen. Die entsprechende Partieion lässt sich dann mit mount /dev/sda1 /mnt
mounten und nach erfolgten Änderungen mit umount /mnt
wieder unmounten.
Nach einem Neustart (ohne aktiviertes Rettungssystem) sollte das System ganz normal starten. Mir wurde schon von Fällen berichtet, wo ein Start in einem "kernel panic" endete. Das ist mir bei mind. 50 so migrierten Systemen verschiedenster Anbieter allerdings noch nie passiert und scheint wirklich eine Seltenheit zu sein!