Cloning a Laptop over NVMe TCP

Original Article ↗ Hacker News Discussion ↗

Cloning a laptop’s NVMe drive over the network using NVMe-over-TCP sparks debate over whether the added protocol complexity is justified when simpler tools like `dd` with `netcat`, rsync, Clonezilla, or btrfs send/receive often suffice. Commenters dig into performance trade-offs (Wi‑Fi vs Ethernet vs USB‑C/Thunderbolt links, compression, block sizes, O_DIRECT), data integrity verification, and the impact of whole-disk encryption or sparse data. Many note that modern Linux and even Windows installs are surprisingly portable across different hardware, so the real choice is between raw block-level cloning and higher-level, file- or snapshot-based migration methods that avoid copying unused space.

Usefulness of NVMe/TCP vs Simple Tools (nc, dd, ssh)

  • Many argue NVMe/TCP offers no real advantage for a one-shot disk clone over a slow link; a plain dd | nc (or dd | ssh) pipeline is simpler and equally effective.
  • Others highlight NVMe/TCP’s value when you actually want to use a remote NVMe as a block device (like network storage), not just clone it.
  • Some view NVMe/TCP as “more moving parts” than necessary; others see it as a clean, standardized transport.

Data Integrity, dd Flags, and Piping Details

  • Debate about dd options: some warn about corruption without iflag=fullblock when using count, while others clarify it’s only needed in specific cases (partial reads with count/skip).
  • Discussion on oflag=direct: one side claims it improves or doesn’t hurt performance with fast SSDs; another says it often reduces sustained throughput and isn’t beneficial in this cloning scenario.
  • Suggestions to avoid dd entirely on the receive side and use nc > /dev/nvme0nX or pv for progress and buffering.

Performance: Compression, Block Sizes, Networks

  • Many recommend adding compression (lz4, zstd, gzip) when the network is slower than CPU/disk, especially when cloning sparse or mostly empty disks.
  • Block size tuning (bs=) is seen as important for dd throughput; matching device/sector sizes can matter.
  • WiFi is repeatedly noted as a major bottleneck; wired Ethernet, USB–Ethernet adapters, or direct USB‑C/Thunderbolt networking can be vastly faster.

Alternatives for Cloning and Migration

  • Several prefer Clonezilla, nbd/nbdkit, or Acronis‑style tools for sparse copying, integrity checks, and partition resizing.
  • Others advocate filesystem-level methods: rsync, btrfs send/receive, dump/restore, Ansible/NixOS-style declarative setups, or just moving the NVMe drive between machines.

Cross‑Hardware and OS Considerations

  • Linux installs generally migrate across different hardware with few issues; Windows is reported to handle hardware changes better than it used to but may hit licensing or driver quirks.
  • TPM‑tied disk encryption is flagged as a hard, unresolved case.