Clonar una laptop mediante NVMe TCP

Clonar una laptop usando NVMe TCP

• Hace poco compré una laptop nueva y tenía que configurarla para usarla.
• No tenía ganas de repetir los pasos de siempre que ya son conocidos.
• Por sugerencia de un colega, consideré copiar el disco existente a la laptop nueva.

Dudas sobre el proceso de clonación

• No tenía una herramienta para abrir la laptop vieja y conectar el disco nuevo por USB.
• Uso cifrado completo de disco, y la laptop anterior usa un NVME de 512GB, mientras que la nueva usa uno de 1TB.
• No estoy familiarizado con el redimensionamiento de particiones LUKS.

La propuesta del colega

• Me sugirió usar NVME over TCP para compartir el disco por la red y realizar una copia completa del disco.
• Los pasos propuestos fueron los siguientes:
  • Exportar el disco desde la laptop vieja usando nvmet-tcp.
  • Realizar la copia del disco desde la laptop nueva.
  • Redimensionar la partición para usar todo el 1TB.
  • Redimensionar LUKS.
  • Por último, redimensionar el disco raíz BTRFS.

Exportar el disco mediante NVME TCP

• Se sugirió que la forma más sencilla era usar systemd-storagetm.service.
• En su lugar, arranqué ambas laptops con un CD de rescate de GRML y seguí los pasos para exportar el disco NVME usando el módulo nvmet-tcp.

Copia del disco

• Usé el comando dd para copiar el disco raíz a la laptop nueva.
• Como la laptop nueva no tenía puerto Ethernet, tuve que usar solo Wi‑Fi, y copiar los 512GB completos tomó unas 7 horas y media.
• La velocidad de copia fue de unos 18-20MB/s.

Redimensionar la partición y el contenedor LUKS

• Al ejecutar parted, detectó que la tabla de particiones no coincidía con el tamaño del disco y pidió corregirlo.
• Instalé cloud-guest-utils y usé growpart para ampliar la partición hasta 1TB.
• Usé cryptsetup-resize para aumentar el tamaño del contenedor LUKS.
• Después de iniciar sesión en el sistema, redimensioné el sistema de archivos BTRFS.

Conclusión

• La única ventaja de este proceso es que puedes usar la laptop nueva sintiendo que estás usando la anterior.
• Configurar una laptop nueva normalmente toma entre 1 y 2 semanas, pero en este caso pude ahorrarme ese tiempo.
• Un beneficio adicional es que aprendí a exportar un disco usando NVME over TCP.

Opinión de GN⁺

• Clonar una laptop con NVME over TCP plantea una forma eficiente de migrar rápidamente el entorno de un sistema existente a hardware nuevo.
• Esta tecnología puede resultar interesante para administradores de sistemas o desarrolladores como una manera de ahorrar tiempo y minimizar errores de configuración.
• Sin embargo, depende en gran medida de la velocidad de la red, y si solo se usa Wi‑Fi puede tomar bastante tiempo, así que ese es un punto en contra a considerar.
• Existen herramientas como Clonezilla o Acronis que ofrecen funciones similares, pero NVME over TCP tiene la ventaja distintiva del acceso directo al disco a través de la red.
• Para adoptar esta técnica, se necesita conocimiento suficiente sobre configuración de red, manejo de discos cifrados y redimensionamiento de sistemas de archivos.

[GN⁺]

Comentarios en Hacker News

• En el escenario del autor no hay ninguna ventaja en usar NVMe/TCP. Como simplemente usa dd para hacer una copia serial de bloques, no aprovecha la E/S concurrente. Los comandos complejos podrían reemplazarse por un simple netcat.

  • En la laptop de destino, usar $ nc -l -p 1234 | dd of=/dev/nvme0nX bs=1M.
  • En la laptop de origen, usar $ nc x.x.x.x 1234 </dev/nvme0nX.
  • En el destino, dd hace buffering de las escrituras, lo que lo vuelve más rápido y eficiente. Si se agrega gzip/gunzip en el origen/destino, todo el proceso se vuelve mucho más rápido cuando el disco no está lleno. Esta es mi forma favorita de crear imágenes de PC por red. Conviene pasar la opción --fast a gzip, o reemplazarlo por lz4/unlz4, que es más rápido. Lo usé recientemente para hacer una imagen de una nueva laptop con Windows con un NVMe de 1 TB, tomó unos 20 minutos por GigE y la imagen resultante fue de 20 GB. Normalmente guardo esa imagen en lz4 y años después, cuando dono la laptop, la restauro con unlz4 | dd. Es muy práctico.
  • No conocía el módulo del kernel de Linux nvme-tcp, pero todos los días se aprende algo nuevo. La utilidad de este módulo está más en montar un sistema de archivos sobre un NVMe remoto que en hacer acceso crudo con dd.
  • En Linux, el tamaño máximo del búfer de pipes es 64 kB, así que técnicamente el argumento dd bs=X no necesita ser mayor que eso. Sin embargo, bs=1M no hace daño (va almacenando lecturas de 64 kB hasta llegar a 1 MB) y además sirve a futuro por si el tamaño del pipe aumenta. Algunas versiones de netcat tienen opciones para controlar el tamaño de bloque de entrada y salida, lo que reduce la necesidad de usar dd bs=X, pero en discos de rescate del sistema normalmente se usa un binario de netcat que no incluye esas opciones.

• Usar nbdkit y nbdcopy es mucho más sencillo.

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

• Cuando tuve que configurar una laptop nueva, fue útil transferir por un cable USB-C a 10 Gb/s. La única otra opción era WiFi.

  • Al conectar las computadoras se forma una red ad hoc y se puede transferir con rsync. Parecía que el enlace ya estaba saturado, así que usar otro protocolo no tenía sentido.

• Hace poco tuve que copiar unos 200 GB de archivos por WiFi. Usé rsync para no tener que empezar de nuevo desde cero si fallaba la conexión, pero igual tomó al menos 6 horas. Me pregunto si hay una mejor forma.

  • ¿Qué garantías se obtienen con el método de dd? ¿Habría que comparar el md5 del dispositivo de bloques resultante?

• No entiendo por qué el autor no hizo un pipe de btrfs por la red. Primero se crea un snapshot de btrfs, y luego con btrfs send => nc => network => nc => btrfs receive se transfieren solo los bloques en uso.

• Antes, al migrar laptops, ejecuté un instalador que combinaba dd y nc en ambos lados. Si mal no recuerdo, también agregaba gzip para acelerar la transferencia.

  • Como la laptop nueva no tenía puerto Ethernet, la compresión quizá dio una pequeña mejora de velocidad, así que probablemente habría sido más rápido que el método del autor.

• Si usas Clonezilla, copia solo los bloques de datos reales y puede ajustar automáticamente las particiones. Yo siempre lo hago así.

  • En general saco el disco NVMe de la laptop y lo pongo en un dock de alta velocidad.

• En realidad no he "instalado" un OS en décadas; simplemente copio archivos y ajusto lo necesario. Normalmente aprovecho para crear un sistema de archivos nuevo y actualizar el tipo/parámetros del sistema de archivos (por ejemplo, el tamaño de bloque), cifrado, etc., y transfiero los archivos con rsync.

  • Aun así, para quienes planifican este tipo de cosas, quizá sea mejor usar un enfoque más declarativo como NixOS. Ahí solo copias la configuración y luego puedes reinstalar todo automáticamente.

• No hay ninguna mención de FDT (Fast Data Transfer).

  • Lamentablemente es un software increíble escrito en Java (en términos de rendimiento de transferencia). Tiene opciones de CLI poco intuitivas, pero es la transferencia más rápida que he visto.
  • Es tan rápido que a veces ocupa toda la red local si no se limita artificialmente la velocidad.
  • Con la opción -limit <rate> se puede limitar la velocidad de transferencia a la tasa especificada. Se pueden usar los sufijos K (KiloBytes/s), M (MegaBytes/s) y G (GigaBytes/s).
  • Provoca fragmentación de archivos en el destino, pero en la práctica eso no le importa a nadie.