Servermigration mit dd über SSH

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.

Statusanzeige von pv, die den Fortschritt zeigt

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. von sda zu vda) 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!