Klonen eines Laptops über NVMe TCP

 (copyninja.in)
2 Punkte von GN⁺ 2024-03-13 | 1 Kommentare | Auf WhatsApp teilen

Klonen eines Laptops mit NVME TCP

  • Kürzlich wurde ein neuer Laptop gekauft und musste für die Nutzung eingerichtet werden.
  • Es bestand wenig Motivation, die bereits bekannten Schritte erneut zu wiederholen.
  • Auf Vorschlag eines Kollegen wurde erwogen, die bestehende Festplatte auf den neuen Laptop zu kopieren.

Fragen zum Klonvorgang

  • Es gab kein Werkzeug, um den alten Laptop zu öffnen und die neue Festplatte per USB anzuschließen.
  • Es wird vollständige Festplattenverschlüsselung verwendet, und der alte Laptop nutzt 512 GB, der neue 1 TB NVME.
  • Es bestand keine Vertrautheit mit dem Ändern der Größe von LUKS-Partitionen.

Vorschlag des Kollegen

  • Es wurde vorgeschlagen, NVME over TCP zu verwenden, um die Festplatte über das Netzwerk freizugeben und eine vollständige Festplattenkopie durchzuführen.
  • Die vorgeschlagenen Schritte waren wie folgt:
    • Die Festplatte vom alten Laptop mit nvmet-tcp exportieren.
    • Die Festplattenkopie auf den neuen Laptop durchführen.
    • Die Partitionen so vergrößern, dass die gesamten 1 TB genutzt werden.
    • Die Größe von LUKS anpassen.
    • Abschließend die Größe der BTRFS-Root-Festplatte anpassen.

Export der Festplatte über NVME TCP

  • Als einfachster Weg wurde die Verwendung von systemd-storagetm.service vorgeschlagen.
  • Stattdessen wurden beide Laptops mit einer GRML-Rescue-CD gebootet und die Schritte zum Export der NVME-Festplatte mit dem Modul nvmet-tcp durchgeführt.

Kopieren der Festplatte

  • Mit dem Befehl dd wurde die Root-Festplatte auf den neuen Laptop kopiert.
  • Da der neue Laptop keinen Ethernet-Port hatte, musste ausschließlich Wi‑Fi verwendet werden; das Kopieren der gesamten 512 GB dauerte etwa siebeneinhalb Stunden.
  • Die Kopiergeschwindigkeit lag bei etwa 18–20 MB/s.

Anpassen der Größe von Partitionen und LUKS-Container

  • Beim Ausführen von parted wurde erkannt, dass die Partitionstabelle nicht mit der Festplattengröße übereinstimmte, und eine Korrektur wurde vorgeschlagen.
  • cloud-guest-utils wurde installiert, um mit growpart die Partition auf 1 TB zu erweitern.
  • Mit cryptsetup-resize wurde die Größe des LUKS-Containers erhöht.
  • Nach der Anmeldung am System wurde die Größe des BTRFS-Dateisystems angepasst.

Fazit

  • Der einzige Vorteil dieses Vorgehens besteht darin, dass sich die Nutzung des neuen Laptops genauso anfühlt wie die des alten.
  • Das Einrichten eines neuen Laptops dauert normalerweise 1 bis 2 Wochen, was in diesem Fall eingespart werden konnte.
  • Ein zusätzlicher Vorteil besteht darin, gelernt zu haben, wie man eine Festplatte mit NVME over TCP exportiert.

Meinung von GN⁺

  • Das Klonen eines Laptops mit NVME over TCP bietet eine effiziente Möglichkeit, eine bestehende Systemumgebung schnell auf neue Hardware zu übertragen.
  • Für Systemadministratoren und Entwickler kann diese Technik interessant sein, weil sie Zeit spart und Einrichtungsfehler minimieren kann.
  • Sie ist jedoch stark von der Netzwerkgeschwindigkeit abhängig, und wenn nur Wi‑Fi verfügbar ist, kann sie erheblich Zeit in Anspruch nehmen, was als Nachteil berücksichtigt werden sollte.
  • Es gibt Werkzeuge wie Clonezilla oder Acronis mit ähnlicher Funktionalität, doch NVME over TCP bietet den besonderen Vorteil eines direkten Festplattenzugriffs über das Netzwerk.
  • Für den Einsatz dieser Technik sind ausreichende Kenntnisse über Netzwerkkonfiguration, den Umgang mit verschlüsselten Festplatten und die Größenanpassung von Dateisystemen erforderlich.

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-03-13
Hacker-News-Kommentar

  • Im Szenario des Autors gibt es keinen Vorteil durch die Nutzung von NVMe/TCP. Es wird lediglich eine serielle Blockkopie mit dd durchgeführt, sodass kein gleichzeitiges I/O genutzt wird. Die komplexen Befehle könnten einfach durch netcat ersetzt werden.

    • Auf dem Ziellaptop: $ nc -l -p 1234 | dd of=/dev/nvme0nX bs=1M
    • Auf dem Quelllaptop: $ nc x.x.x.x 1234 </dev/nvme0nX
    • Auf dem Ziel puffert dd Schreibvorgänge, was es schneller und effizienter macht. Wenn man auf Quelle/Ziel noch gzip/gunzip ergänzt, geht der gesamte Vorgang deutlich schneller, sofern die Platte nicht voll ist. Das ist meine bevorzugte Methode, um PC-Images über das Netzwerk zu erstellen. Es ist sinnvoll, gzip die Option --fast mitzugeben oder es durch das schnellere lz4/unlz4 zu ersetzen. Ich habe das kürzlich verwendet, um einen neuen Windows-Laptop mit 1-TB-NVMe zu imag(en); über GigE dauerte es etwa 20 Minuten, und das resultierende Image war 20 GB groß. Normalerweise sichere ich dieses lz4-Image und stelle es Jahre später beim Spenden des Laptops mit unlz4 | dd wieder her. Sehr praktisch.
    • Ich kannte das Linux-Kernel-Modul nvme-tcp nicht, aber man lernt jeden Tag etwas Neues. Sein Nutzen liegt eher darin, ein Dateisystem auf entferntem NVMe zu mounten, als per dd roh darauf zuzugreifen.
    • Unter Linux beträgt die maximale Pipe-Puffergröße 64 kB, daher muss das Argument dd bs=X technisch gesehen nicht größer sein. bs=1M schadet jedoch nicht (es puffert 64-kB-Lesevorgänge, bis 1 MB erreicht ist) und ist auch in Zukunft nutzbar, falls die Pipe-Größe erhöht wird. Einige netcat-Versionen haben Optionen zur Steuerung der Eingabe- und Ausgabe-Blockgröße, was die Notwendigkeit von dd bs=X verringert, aber auf Rescue-Disks findet man meist ein netcat-Binary ohne solche Optionen.

  • Die Verwendung von nbdkit und nbdcopy ist deutlich einfacher.

    • nbdkit file /dev/nvme0n1
    • nbdcopy nbd://otherlaptop localfile

  • Als ich einen neuen Laptop einrichten musste, war es nützlich, ein USB-C-Kabel zu verwenden und mit 10 Gb/s zu übertragen. Die einzige andere Option war WiFi.

    • Wenn man die Computer verbindet, entsteht ein Ad-hoc-Netzwerk, und die Übertragung ist mit rsync möglich. Die Verbindung schien ausgelastet zu sein, daher wäre ein anderes Protokoll sinnlos gewesen.

  • Ich musste kürzlich etwa 200 GB an Dateien über WiFi kopieren. Ich habe rsync verwendet, damit ich bei einem Verbindungsabbruch nicht wieder von vorne anfangen muss, aber es dauerte trotzdem mindestens 6 Stunden. Ich frage mich, ob es eine bessere Methode gibt.

    • Welche Garantien bekommt man bei der dd-Methode? Sollte man die md5 der resultierenden Blockgerätedaten vergleichen?

  • Ich verstehe nicht, warum der Autor nicht btrfs über das Netzwerk gepiped hat. Man erstellt zuerst einen btrfs-Snapshot und überträgt dann mit btrfs send => nc => network => nc => btrfs receive nur die tatsächlich verwendeten Blöcke.

  • Bei früheren Laptop-Übertragungen habe ich auf beiden Seiten einen Installer ausgeführt, der dd und nc kombinierte. Soweit ich mich erinnere, habe ich zusätzlich gzip verwendet, um die Übertragung zu beschleunigen.

    • Da der neue Laptop keinen Ethernet-Port hatte, könnte die Kompression einen kleinen Geschwindigkeitsvorteil gebracht haben, sodass es möglicherweise schneller war als die Methode des Autors.

  • Mit Clonezilla werden nur die tatsächlich belegten Datenblöcke kopiert, und Partitionen lassen sich automatisch anpassen. Ich verwende immer diese Methode.

    • Normalerweise nehme ich die NVMe-SSD aus dem Laptop heraus und stecke sie in ein schnelles Dock.

  • Seit Jahrzehnten habe ich ein OS nicht mehr wirklich „installiert“, sondern kopiere einfach Dateien und passe sie bei Bedarf an. Meist nutze ich das als Gelegenheit, ein neues Dateisystem anzulegen und dabei Dateisystemtyp/-parameter (z. B. Blockgröße), Verschlüsselung usw. zu aktualisieren, und übertrage die Dateien mit rsync.

    • Trotzdem wäre für Menschen, die gerne im Voraus planen, vielleicht ein deklarativerer Ansatz wie NixOS besser. Dann kopiert man nur die Konfiguration und kann anschließend alles automatisch neu installieren.

  • Keine Erwähnung von FDT (Fast Data Transfer).

    • Leider in Java geschriebene, aber beeindruckende Software (was die Transferleistung angeht). Sie hat unintuitive CLI-Optionen, ist aber die schnellste Übertragung, die ich je gesehen habe.
    • Sie ist so schnell, dass sie manchmal das gesamte lokale Netzwerk belegt, wenn man die Geschwindigkeit nicht künstlich begrenzt.
    • Mit der Option -limit <rate> kann die Übertragung auf eine bestimmte Geschwindigkeit begrenzt werden. Als Suffixe können K (KiloBytes/s), M (MegaBytes/s) und G (GigaBytes/s) verwendet werden.
    • Sie verursacht Dateifragmentierung auf dem Ziel, aber in der Praxis dürfte das niemanden interessieren.