Sao chép laptop qua NVMe TCP

 (copyninja.in)
2 điểm bởi GN⁺ 2024-03-13 | 1 bình luận | Chia sẻ qua WhatsApp

Sao chép laptop bằng NVMe TCP

  • Gần đây tôi mua một chiếc laptop mới và cần thiết lập nó để sử dụng.
  • Tôi không có hứng lặp lại các bước vốn đã quen thuộc.
  • Theo gợi ý của một đồng nghiệp, tôi cân nhắc cách sao chép ổ đĩa cũ sang laptop mới.

Những băn khoăn về quá trình sao chép

  • Tôi không có công cụ để mở laptop cũ và kết nối ổ đĩa mới qua USB.
  • Tôi đang dùng mã hóa toàn bộ ổ đĩa, laptop cũ dùng NVME 512GB còn laptop mới dùng NVME 1TB.
  • Tôi không quen với việc thay đổi kích thước phân vùng LUKS.

Đề xuất của đồng nghiệp

  • Anh ấy đề xuất dùng NVME over TCP để chia sẻ ổ đĩa qua mạng và thực hiện sao chép toàn bộ ổ đĩa.
  • Các bước được đề xuất như sau:
    • Xuất ổ đĩa từ laptop cũ bằng nvmet-tcp.
    • Thực hiện sao chép ổ đĩa sang laptop mới.
    • Thay đổi kích thước phân vùng để dùng toàn bộ 1TB.
    • Thay đổi kích thước LUKS.
    • Cuối cùng thay đổi kích thước ổ gốc BTRFS.

Xuất ổ đĩa qua NVME TCP

  • systemd-storagetm.service được đề xuất là cách dễ nhất.
  • Thay vào đó, tôi khởi động cả hai laptop bằng GRML rescue CD và thực hiện các bước xuất ổ NVME bằng mô-đun nvmet-tcp.

Sao chép ổ đĩa

  • Tôi dùng lệnh dd để sao chép ổ gốc sang laptop mới.
  • Laptop mới không có cổng Ethernet nên tôi buộc phải chỉ dùng Wi‑Fi, và mất khoảng 7 tiếng rưỡi để sao chép toàn bộ 512GB.
  • Tốc độ sao chép vào khoảng 18-20MB/s.

Thay đổi kích thước phân vùng và vùng chứa LUKS

  • Khi chạy parted, nó phát hiện bảng phân vùng không khớp với kích thước ổ đĩa và yêu cầu sửa lại.
  • Tôi cài cloud-guest-utils rồi dùng growpart để mở rộng phân vùng lên 1TB.
  • Tôi dùng cryptsetup-resize để tăng kích thước vùng chứa LUKS.
  • Sau khi đăng nhập vào hệ thống, tôi thay đổi kích thước hệ thống tệp BTRFS.

Kết luận

  • Lợi ích duy nhất của quá trình này là khi dùng laptop mới, bạn vẫn có cảm giác như đang dùng chiếc laptop cũ.
  • Thông thường tôi mất 1 đến 2 tuần để thiết lập một laptop mới, nhưng trong trường hợp này tôi đã tiết kiệm được khoảng thời gian đó.
  • Một lợi ích bổ sung là tôi đã học được cách xuất ổ đĩa bằng NVME over TCP.

Ý kiến của GN⁺

  • Việc sao chép laptop bằng NVME over TCP đưa ra một cách hiệu quả để chuyển nhanh môi trường hệ thống hiện có sang phần cứng mới.
  • Kỹ thuật này có thể hấp dẫn với quản trị viên hệ thống hoặc nhà phát triển như một cách tiết kiệm thời gian và giảm thiểu lỗi cấu hình.
  • Tuy nhiên, nó phụ thuộc rất nhiều vào tốc độ mạng, và nếu chỉ dùng Wi‑Fi thì có thể mất khá nhiều thời gian, đây là một nhược điểm cần cân nhắc.
  • Dù có các công cụ như Clonezilla hay Acronis cung cấp chức năng tương tự, NVME over TCP vẫn có lợi thế riêng là cho phép truy cập ổ đĩa trực tiếp qua mạng.
  • Khi áp dụng kỹ thuật này, cần có đủ kiến thức về cấu hình mạng, xử lý ổ đĩa được mã hóa và thay đổi kích thước hệ thống tệp.

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-03-13
Bình luận trên Hacker News

  • Trong kịch bản của tác giả, không có lợi ích gì khi dùng NVMe/TCP. Vì chỉ đơn giản dùng dd để thực hiện sao chép khối tuần tự nên không tận dụng được I/O đồng thời. Các lệnh phức tạp có thể được thay bằng netcat đơn giản.

    • Trên laptop đích, dùng $ nc -l -p 1234 | dd of=/dev/nvme0nX bs=1M.
    • Trên laptop nguồn, dùng $ nc x.x.x.x 1234 </dev/nvme0nX.
    • Ở phía đích, dd sẽ đệm thao tác ghi để nhanh và hiệu quả hơn. Nếu thêm gzip/gunzip ở phía nguồn/đích thì khi ổ đĩa chưa đầy, toàn bộ quá trình sẽ nhanh hơn nhiều. Đây là cách yêu thích của tôi để tạo image PC qua mạng. Nên truyền tùy chọn --fast cho gzip, hoặc thay bằng lz4/unlz4 nhanh hơn. Gần đây tôi đã dùng cách này để tạo image cho một laptop Windows mới với NVMe 1TB, mất khoảng 20 phút qua GigE và image thu được là 20GB. Tôi thường lưu image lz4 này để sao lưu, rồi vài năm sau khi đem tặng laptop thì khôi phục bằng unlz4 | dd. Rất tiện.
    • Tôi chưa biết về mô-đun nhân Linux nvme-tcp, nhưng ngày nào cũng học được điều mới. Tính hữu dụng của mô-đun này nằm nhiều hơn ở việc mount hệ thống tệp trên NVMe từ xa thay vì truy cập thô bằng dd.
    • Trên Linux, kích thước bộ đệm pipe tối đa là 64kB nên về mặt kỹ thuật đối số dd bs=X không cần lớn hơn mức đó. Tuy vậy, bs=1M cũng không gây hại (nó sẽ đệm các lần đọc 64kB cho tới khi thành 1MB) và vẫn dùng được trong tương lai nếu kích thước pipe tăng lên. Một số phiên bản netcat có tùy chọn điều khiển kích thước khối vào và ra, giúp giảm nhu cầu dùng dd bs=X, nhưng trên các đĩa cứu hộ hệ thống thì thường dùng binary netcat không có các tùy chọn đó.

  • Dùng nbdkit và nbdcopy sẽ đơn giản hơn nhiều.

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

  • Khi phải thiết lập laptop mới, việc truyền qua cáp USB-C ở tốc độ 10Gb/s rất hữu ích. Lựa chọn khác khi đó chỉ có WiFi.

    • Kết nối hai máy tính sẽ tạo ra một mạng ad-hoc và có thể truyền bằng rsync. Có vẻ như liên kết đã bão hòa nên dùng giao thức khác cũng không có ý nghĩa.

  • Gần đây tôi phải sao chép khoảng 200GB tệp qua WiFi. Tôi dùng rsync để nếu kết nối bị rớt thì không phải bắt đầu lại từ đầu, nhưng vẫn mất ít nhất 6 tiếng. Không biết có cách nào tốt hơn không.

    • Với cách dd thì nhận được bảo đảm gì? Có cần so sánh md5 của thiết bị khối kết quả không?

  • Tôi không hiểu vì sao tác giả không pipe btrfs qua mạng. Trước tiên tạo một snapshot btrfs, sau đó dùng btrfs send => nc => network => nc => btrfs receive để chỉ truyền các khối đang được sử dụng.

  • Trước đây khi chuyển dữ liệu giữa các laptop, tôi đã chạy một trình cài đặt kết hợp dd và nc ở cả hai phía. Nếu nhớ không nhầm, tôi cũng thêm gzip để tăng tốc truyền.

    • Laptop mới không có cổng Ethernet nên việc nén có thể đã cải thiện tốc độ đôi chút, vì vậy có lẽ còn nhanh hơn cách của tác giả.

  • Nếu dùng Clonezilla thì chỉ sao chép các khối dữ liệu thực sự có dữ liệu và có thể tự động điều chỉnh phân vùng. Tôi luôn dùng cách này.

    • Thông thường tôi tháo ổ NVMe ra khỏi laptop rồi gắn vào dock tốc độ cao.

  • Trong nhiều thập kỷ, tôi thực ra chưa bao giờ "cài đặt" hệ điều hành, mà chỉ sao chép tệp rồi điều chỉnh khi cần. Thường tôi xem đây là cơ hội để tạo hệ thống tệp mới và cập nhật loại hệ thống tệp/tham số (ví dụ: kích thước khối), mã hóa, v.v., rồi truyền tệp bằng rsync.

    • Dù vậy, nếu là người thích lên kế hoạch thì có lẽ nên dùng cách tiếp cận mang tính khai báo hơn như NixOS. Khi đó chỉ cần sao chép cấu hình rồi tự động cài đặt lại mọi thứ.

  • Không thấy ai nhắc đến FDT(Fast Data Transfer).

    • Đáng tiếc là một phần mềm tuyệt vời được viết bằng Java (xét về hiệu năng truyền tải). Nó có các tùy chọn CLI không trực quan, nhưng là phương thức truyền nhanh nhất tôi từng thấy.
    • Nó nhanh đến mức nếu không chủ động giới hạn tốc độ thì đôi khi sẽ chiếm trọn cả mạng nội bộ.
    • Có thể giới hạn tốc độ truyền theo mức chỉ định bằng tùy chọn -limit <rate>. Có thể dùng hậu tố K(KiloBytes/s), M(MegaBytes/s), G(GigaBytes/s).
    • Nó gây phân mảnh tệp ở phía đích, nhưng thực tế điều đó chẳng quan trọng với ai cả.