Clonando um notebook via NVMe TCP

Clonando um notebook usando NVME TCP

• Recentemente comprei um notebook novo e precisava configurá-lo para uso.
• Eu não tinha motivação para repetir as etapas já conhecidas.
• Por sugestão de um colega, considerei uma forma de copiar o disco antigo para o notebook novo.

Dúvidas sobre o processo de clonagem

• Eu não tinha uma ferramenta para abrir o notebook antigo e conectar o novo disco via USB.
• Eu uso criptografia de disco completa, e o notebook antigo usa um NVME de 512GB, enquanto o novo usa um NVME de 1TB.
• Eu não tinha familiaridade com redimensionamento de partições LUKS.

A sugestão do colega

• Ele sugeriu usar NVME over TCP para compartilhar o disco pela rede e fazer uma cópia completa do disco.
• As etapas sugeridas foram as seguintes:
  • Exportar o disco do notebook antigo usando nvmet-tcp.
  • Fazer a cópia do disco para o notebook novo.
  • Redimensionar a partição para usar todo o 1TB.
  • Redimensionar o LUKS.
  • Por fim, redimensionar o disco raiz BTRFS.

Exportando o disco via NVME TCP

• Foi sugerido que a forma mais fácil seria usar systemd-storagetm.service.
• Em vez disso, inicializei os dois notebooks com o GRML rescue CD e executei as etapas para exportar o disco NVME usando o módulo nvmet-tcp.

Cópia do disco

• Usei o comando dd para copiar o disco raiz para o notebook novo.
• Como o notebook novo não tinha porta Ethernet, tive de usar apenas Wi-Fi, e levaram cerca de 7 horas e meia para copiar os 512GB completos.
• A velocidade de cópia ficou em torno de 18-20MB/s.

Redimensionando partições e o contêiner LUKS

• Ao executar parted, ele detectou que a tabela de partições não correspondia ao tamanho do disco e pediu correção.
• Instalei cloud-guest-utils e usei growpart para expandir a partição até 1TB.
• Usei cryptsetup-resize para aumentar o tamanho do contêiner LUKS.
• Depois de entrar no sistema, redimensionei o sistema de arquivos BTRFS.

Conclusão

• A única vantagem desse processo é que você pode usar o notebook novo tendo exatamente a mesma sensação de uso do notebook antigo.
• Normalmente leva de 1 a 2 semanas para configurar um notebook novo, mas neste caso foi possível economizar esse tempo.
• Há também o benefício adicional de ter aprendido como exportar um disco usando NVME over TCP.

Opinião do GN⁺

• Clonar um notebook com NVME over TCP apresenta uma forma eficiente de migrar rapidamente o ambiente do sistema existente para um novo hardware.
• Essa técnica pode ser interessante para administradores de sistemas e desenvolvedores como uma forma de economizar tempo e minimizar erros de configuração.
• No entanto, ela depende bastante da velocidade da rede, e se apenas Wi-Fi estiver disponível, o processo pode levar bastante tempo, o que é uma desvantagem a considerar.
• Existem ferramentas como Clonezilla ou Acronis que oferecem funcionalidades semelhantes, mas o NVME over TCP tem a vantagem única de permitir acesso direto ao disco pela rede.
• Ao adotar essa técnica, é necessário ter conhecimento suficiente sobre configuração de rede, tratamento de discos criptografados e redimensionamento de sistemas de arquivos.

[GN⁺]

Comentário no Hacker News

• No cenário do autor, não há vantagem em usar NVMe/TCP. Como ele simplesmente usa dd para fazer uma cópia serial em nível de bloco, não aproveita I/O simultâneo. Os comandos complexos podem ser substituídos por um simples netcat.

  • No notebook de destino, use $ nc -l -p 1234 | dd of=/dev/nvme0nX bs=1M.
  • No notebook de origem, use $ nc x.x.x.x 1234 </dev/nvme0nX.
  • No destino, o dd faz buffer das gravações, tornando o processo mais rápido e eficiente. Se adicionar gzip/gunzip na origem/destino, todo o processo fica muito mais rápido quando o disco não está cheio. Esse é meu jeito favorito de criar imagens de PCs pela rede. Vale a pena passar a opção --fast para o gzip, ou trocá-lo por lz4/unlz4, que é mais rápido. Usei isso recentemente para criar a imagem de um notebook Windows novo com NVMe de 1TB; levou cerca de 20 minutos via GigE, e a imagem resultante tinha 20GB. Normalmente guardo essa imagem em lz4 como backup e, alguns anos depois, quando vou doar o notebook, restauro com unlz4 | dd. É extremamente prático.
  • Eu não conhecia o módulo do kernel Linux nvme-tcp, mas todo dia se aprende algo novo. A utilidade desse módulo parece estar mais em montar um sistema de arquivos em um NVMe remoto do que em fazer acesso bruto com dd.
  • No Linux, o tamanho máximo do buffer de pipe é 64kB, então o argumento dd bs=X tecnicamente não precisa ser maior que isso. Ainda assim, bs=1M não atrapalha (ele faz buffer de leituras de 64kB até chegar a 1MB) e continua servindo no futuro caso o tamanho do pipe aumente. Algumas versões do netcat têm opções para controlar o tamanho dos blocos de entrada e saída, o que reduz a necessidade de usar dd bs=X, mas em discos de recuperação normalmente se usa um binário netcat sem essas opções.

• Usar nbdkit e nbdcopy é muito mais simples.

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

• Quando precisei configurar um notebook novo, foi útil transferir a 10Gb/s usando um cabo USB-C. A única outra opção era Wi‑Fi.

  • Ao conectar os computadores, forma-se uma rede ad hoc e dá para transferir com rsync. Parecia que o link já estava saturado, então usar outro protocolo não faria diferença.

• Recentemente precisei copiar cerca de 200GB de arquivos por Wi‑Fi. Usei rsync para não ter que recomeçar do zero se a conexão caísse, mas ainda assim levou pelo menos 6 horas. Gostaria de saber se existe uma forma melhor.

  • Que garantias você obtém com o método de dd? É preciso comparar o md5 do dispositivo em nível de bloco resultante?

• Não entendo por que o autor não usou btrfs pela rede. Primeiro cria-se um snapshot do btrfs e depois usa-se btrfs send => nc => network => nc => btrfs receive para transferir apenas os blocos em uso.

• Já fiz migração de notebooks antes executando um instalador que combinava dd e nc em ambos os lados. Pelo que me lembro, também adicionei gzip para acelerar a transferência.

  • Como o notebook novo não tinha porta Ethernet, a compressão pode ter dado um pequeno ganho de velocidade, então provavelmente foi mais rápido que o método do autor.

• Com Clonezilla, você pode copiar apenas os blocos de dados reais e ajustar automaticamente as partições. Sempre uso esse método.

  • Normalmente tiro o disco NVMe do notebook e o coloco em um dock rápido.

• Há décadas eu não "instalo" um sistema operacional de fato; eu copio os arquivos e ajusto o que for necessário. Em geral, aproveito para criar um novo sistema de arquivos e atualizar o tipo/parâmetros do sistema de arquivos (por exemplo, tamanho de bloco), criptografia etc., e transfiro os arquivos com rsync.

  • Ainda assim, para quem gosta de planejar tudo, talvez seja melhor usar uma abordagem mais declarativa, como NixOS. Nesse caso, basta copiar a configuração e reinstalar tudo automaticamente.

• Não houve nenhuma menção ao FDT (Fast Data Transfer).

  • Infelizmente, é um software incrível (em termos de desempenho de transferência) escrito em Java. Tem opções de CLI pouco intuitivas, mas é a transferência mais rápida que já vi.
  • É tão rápido que, se você não limitar artificialmente a velocidade, às vezes ele toma conta da rede local inteira.
  • Você pode limitar a velocidade da transferência com a opção -limit <rate>. É possível usar K(KiloBytes/s), M(MegaBytes/s) e G(GigaBytes/s) como sufixos.
  • Ele causa fragmentação dos arquivos no destino, mas na prática isso não importa para ninguém.