Clonar una laptop sobre NVMe TCP

Artículo original ↗ Discusión en Hacker News ↗

Clonar la unidad NVMe de una laptop por la red usando NVMe-over-TCP provoca debate sobre si la complejidad adicional del protocolo está justificada cuando herramientas más simples como `dd` con `netcat`, rsync, Clonezilla o btrfs send/receive suelen ser suficientes. Los comentaristas analizan las compensaciones de rendimiento (Wi‑Fi frente a Ethernet frente a enlaces USB‑C/Thunderbolt, compresión, tamaños de bloque, O_DIRECT), la verificación de integridad de datos y el impacto del cifrado de disco completo o de los datos escasos. Muchos señalan que las instalaciones modernas de Linux e incluso de Windows son sorprendentemente portables entre hardware diferente, así que la verdadera decisión está entre la clonación bruta a nivel de bloque y métodos de migración de nivel superior, basados en archivos o snapshots, que evitan copiar espacio no usado.

Utilidad de NVMe/TCP frente a herramientas simples (nc, dd, ssh)

  • Muchos sostienen que NVMe/TCP no ofrece ninguna ventaja real para una clonación de disco de una sola vez sobre un enlace lento; una tubería simple dd | nc (o dd | ssh) es más sencilla e igualmente efectiva.
  • Otros destacan el valor de NVMe/TCP cuando realmente quieres usar un NVMe remoto como dispositivo de bloque (como almacenamiento en red), no solo clonar.
  • Algunos ven NVMe/TCP como “más piezas móviles” de las necesarias; otros lo consideran un transporte limpio y estandarizado.

Integridad de datos, banderas de dd y detalles de canalización

  • Debate sobre las opciones de dd: algunos advierten sobre corrupción sin iflag=fullblock cuando se usa count, mientras que otros aclaran que solo se necesita en casos específicos (lecturas parciales con count/skip).
  • Discusión sobre oflag=direct: un lado afirma que mejora o no perjudica el rendimiento con SSD rápidas; otro dice que a menudo reduce el rendimiento sostenido y no aporta beneficios en este escenario de clonación.
  • Sugerencias para evitar dd por completo en el lado receptor y usar nc > /dev/nvme0nX o pv para progreso y buffering.

Rendimiento: compresión, tamaños de bloque, redes

  • Muchos recomiendan añadir compresión (lz4, zstd, gzip) cuando la red es más lenta que la CPU/el disco, especialmente al clonar discos escasos o mayormente vacíos.
  • El ajuste del tamaño de bloque (bs=) se considera importante para el rendimiento de dd; hacer coincidir tamaños de dispositivo/sector puede importar.
  • Se señala repetidamente que WiFi es un gran cuello de botella; Ethernet por cable, adaptadores USB–Ethernet o redes directas USB‑C/Thunderbolt pueden ser muchísimo más rápidos.

Alternativas para clonación y migración

  • Varios prefieren Clonezilla, nbd/nbdkit o herramientas al estilo Acronis para copia escasa, comprobaciones de integridad y redimensionamiento de particiones.
  • Otros abogan por métodos a nivel de sistema de archivos: rsync, btrfs send/receive, dump/restore, configuraciones declarativas al estilo Ansible/NixOS, o simplemente mover la unidad NVMe entre máquinas.

Consideraciones entre hardware y sistemas operativos

  • Las instalaciones de Linux suelen migrar entre hardware diferente con pocos problemas; se informa que Windows maneja mejor los cambios de hardware que antes, pero puede encontrar problemas de licencias o controladores.
  • El cifrado de disco ligado al TPM se señala como un caso difícil, sin resolver.