NVMe TCPによるノートPCのクローン

 (copyninja.in)
2 ポイント 投稿者 GN⁺ 2024-03-13 | 1件のコメント | WhatsAppで共有

NVME TCPを使ったノートPCのクローン

  • 最近、新しいノートPCを購入し、使うための設定が必要だった。
  • 既に知られている手順を繰り返す気力がなかった。
  • 同僚の提案で、既存のディスクを新しいノートPCにコピーする方法を検討した。

クローン作業に関する疑問

  • 既存のノートPCを開けて新しいディスクをUSBで接続するためのツールがなかった。
  • フルディスク暗号化を使っており、既存のノートPCは512GB、新しいノートPCは1TBのNVMEを使っている。
  • LUKSパーティションのサイズ変更には慣れていなかった。

同僚の提案

  • NVME over TCPを使ってディスクをネットワーク経由で共有し、ディスク全体のコピーを行うよう提案された。
  • 提案された手順は次のとおり。
    • 既存のノートPCで nvmet-tcp を使ってディスクをエクスポートする。
    • 新しいノートPCへディスクのコピーを実行する。
    • パーティションを1TB全体を使うようにサイズ変更する。
    • LUKSのサイズを変更する。
    • 最後にBTRFSルートディスクのサイズを変更する。

NVME TCPによるディスクのエクスポート

  • systemd-storagetm.service を使うのが最も簡単な方法として提案された。
  • その代わりに、両方のノートPCをGRMLレスキューCDで起動し、nvmet-tcp モジュールを使ってNVMEディスクをエクスポートする手順を行った。

ディスクのコピー

  • dd コマンドを使ってルートディスクを新しいノートPCへコピーした。
  • 新しいノートPCにはEthernetポートがなく、Wi‑Fiだけを使わざるを得なかったため、512GB全体のコピーに約7時間半かかった。
  • コピー速度は約18〜20MB/sだった。

パーティションとLUKSコンテナのサイズ変更

  • parted を実行すると、パーティションテーブルがディスクサイズと一致していないことを検出し、修正を求められた。
  • cloud-guest-utils をインストールし、growpart を使ってパーティションを1TBまで拡張した。
  • cryptsetup-resize を使ってLUKSコンテナのサイズを拡大した。
  • システムにログインした後、BTRFSファイルシステムのサイズを変更した。

結論

  • この作業の唯一の利点は、新しいノートPCを使いながらも、これまでのノートPCを使っているのと同じ感覚を得られることだ。
  • 新しいノートPCのセットアップには通常1〜2週間かかるが、この場合はその時間を節約できる。
  • NVME over TCPを使ったディスクのエクスポート方法を学べたという追加の利点もある。

GN⁺の見解

  • NVME over TCPを使ったノートPCのクローンは、既存のシステム環境を新しいハードウェアへ素早く移行できる効率的な方法を示している。
  • この技術は、システム管理者や開発者にとって、時間を節約し設定ミスを最小限に抑える方法として興味深い。
  • ただし、ネットワーク速度に大きく依存し、Wi‑Fiしか使えない場合はかなりの時間がかかるため、その点は欠点として考慮する必要がある。
  • 類似の機能を提供するClonezillaやAcronisのようなツールもあるが、NVME over TCPにはネットワーク経由でディスクへ直接アクセスできるという独自の利点がある。
  • この技術を導入する際には、ネットワーク設定、暗号化ディスクの扱い、ファイルシステムのサイズ変更などについて十分な知識が必要になる。

関連記事

1件のコメント

 
GN⁺ 2024-03-13
Hacker Newsの意見

  • 著者のシナリオでは、NVMe/TCPを使う利点はない。単にddを使ってシリアルなブロックコピーを行っているだけなので、同時I/Oを活用できていない。複雑なコマンドはシンプルなnetcatで置き換え可能。

    • 宛先ノートPCでは $ nc -l -p 1234 | dd of=/dev/nvme0nX bs=1M を使用。
    • 転送元ノートPCでは $ nc x.x.x.x 1234 </dev/nvme0nX を使用。
    • 宛先側のddは書き込みをバッファリングするため、より高速かつ効率的になる。転送元/宛先でgzip/gunzipを追加すれば、ディスクが埋まっていない場合は作業全体が大幅に速くなる。これはネットワーク経由でPCイメージを作成する自分のお気に入りの方法。gzipに--fastオプションを渡すか、より高速なlz4/unlz4に置き換えるのがよい。最近、1TB NVMeを搭載した新しいWindowsノートPCをイメージ化する際に使ったが、GigE経由で20分ほどかかり、結果のイメージは20GBだった。通常はこのlz4イメージをバックアップしておき、数年後にノートPCを寄付するときにunlz4 | ddで復元する。とても便利。
    • Linuxカーネルモジュールnvme-tcpについては知らなかったが、毎日何かしら新しいことを学ぶ。このモジュールの有用性は、ddで生のアクセスをすることよりも、リモートNVMeにファイルシステムをマウントすることにある。
    • Linuxでの最大パイプバッファサイズは64kBなので、dd bs=X引数は技術的にはそれより大きくする必要はない。ただし、bs=1Mは害はなく（64kBの読み取りを1MBになるまでバッファする）、パイプサイズが将来増えた場合にもそのまま使える。一部のnetcatバージョンには入出力ブロックサイズを制御するオプションがあり、dd bs=Xを使う必要性を減らせるが、レスキューディスクではそうしたオプションのないnetcatバイナリが使われることが多い。

  • nbdkitとnbdcopyを使うほうがずっと簡単。

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

  • 新しいノートPCをセットアップしなければならなかったとき、USB-Cケーブルを使って10Gb/sで転送できたのが便利だった。他の選択肢はWiFiしかなかった。

    • コンピュータ同士を接続するとアドホックネットワークが形成され、rsyncを使って転送できる。リンクは飽和しているようだったので、別のプロトコルを使っても意味はなさそう。

  • 最近、WiFi経由で約200GBのファイルをコピーする必要があった。接続失敗時に最初からやり直しにならないようrsyncを使ったが、それでも少なくとも6時間かかった。もっと良い方法があるのか気になる。

    • dd方式だとどんな保証が得られるのか？ 結果のブロックレベルデバイスのmd5を比較すべきなのか？

  • 著者がなぜネットワーク経由でbtrfsをパイプしなかったのか理解できない。まずbtrfsスナップショットを作成し、その後btrfs send => nc => network => nc => btrfs receiveで使用中のブロックだけを転送すればよい。

  • 以前ノートPCを移行したとき、両側でddとncを組み合わせたインストーラを実行した。記憶している限りでは、転送を速くするためにgzipも追加した。

    • 新しいノートPCにはEthernetポートがなかったので、圧縮によって多少速度向上が得られ、著者の方法より速かったかもしれない。

  • Clonezillaを使えば、実データブロックだけをコピーし、パーティションも自動調整できる。いつもこの方法を使っている。

    • 普通はノートPCからNVMeディスクを取り出して、高速ドックに挿す。

  • 何十年も実際にOSを「インストール」しておらず、ファイルをコピーして必要に応じて調整している。たいていは新しいファイルシステムを作って、ファイルシステム種別/パラメータ（例: ブロックサイズ）、暗号化などを更新する機会にし、ファイルはrsyncで転送する。

    • それでも、計画的に進めたい人なら、NixOSのようなより宣言的なアプローチを使うほうが良いかもしれない。ここでは設定だけをコピーし、その後すべてを自動で再インストールできる。

  • FDT(Fast Data Transfer)への言及がない。

    • 残念ながらJavaで書かれているが、驚くべきソフトウェア（転送性能の面で）。CLIオプションは直感的ではないが、自分が見た中では最速の転送。
    • あまりに速すぎて、人工的に速度制限しないとローカルネットワーク全体を占有してしまうことがある。
    • -limit <rate>オプションで転送速度を指定レートに制限できる。接尾辞としてK(KiloBytes/s)、M(MegaBytes/s)、G(GigaBytes/s)が使える。
    • 宛先側でファイルの断片化を引き起こすが、実際には誰にとっても大した問題ではない。