Mengkloning laptop melalui NVMe over TCP

 (copyninja.in)
2 poin oleh GN⁺ 2024-03-13 | 1 komentar | Bagikan ke WhatsApp
  • Alih-alih menyiapkan laptop baru dari awal lagi, seluruh disk laptop lama diekspos melalui NVMe over TCP lalu dikloning apa adanya lewat jaringan
  • Lingkungan lama menggunakan enkripsi seluruh disk dan disk 512GB, sementara laptop baru memakai NVMe 1TB sehingga setelah kloning perlu memperluas partisi, LUKS, dan BTRFS
  • Untuk mengekspor disk, alih-alih systemd-storagetm.service, kedua laptop di-boot dengan GRML rescue CD lalu dikonfigurasi menggunakan nvmet-tcp dan /sys/kernel/config/nvmet
  • Penyalinan aktual dilakukan dengan dd, dan karena laptop baru tidak memiliki port Ethernet sehingga hanya menggunakan WiFi, hasilnya kloning 512GB memakan waktu sekitar 7 jam 30 menit dengan kecepatan sekitar 18~20MB/s
  • Setelah kloning, dilakukan penyesuaian agar seluruh 1TB bisa digunakan melalui parted, growpart, cryptsetup resize, dan resize BTRFS, sehingga lingkungan laptop lama bisa diteruskan hampir apa adanya

Mengekspor disk lama dengan NVMe over TCP

  • Untuk menghindari mengulang prosedur penyiapan laptop baru, dipilih metode menyalin seluruh disk laptop lama sesuai saran rekan kerja

  • Sebelum mulai, ada dua kendala

    • Tidak ada alat untuk membuka laptop lama dan menghubungkan disk baru lewat USB
    • Laptop lama menggunakan enkripsi seluruh disk dan disk 512GB, sedangkan laptop baru memakai NVMe 1TB sehingga perlu penyesuaian ukuran LUKS

  • Alur kerjanya terdiri dari tiga tahap: mengekspos disk, menyalin, dan memperluas kapasitas

    • Mengekspor disk dari laptop lama dengan nvmet-tcp
    • Menyalin disk tersebut di laptop baru
    • Memperluas partisi ke seluruh kapasitas 1TB
    • Menyesuaikan ukuran LUKS
    • Terakhir, menyesuaikan ukuran disk root BTRFS

  • Menggunakan GRML alih-alih systemd-storagetm.service

    • Cara termudah sebenarnya adalah menggunakan systemd-storagetm.service
    • Ini bisa dipanggil dengan boot ke storage-target-mode.target menggunakan rd.systemd.unit=storage-target-mode.target
    • Namun, pendekatan ini mengharuskan layanan jaringan disertakan dalam image initrd dracut, dan dalam mode tersebut konfigurasi WiFi cukup merepotkan, sehingga tidak dipilih
    • Sebagai gantinya, kedua laptop di-boot dengan GRML rescue CD, lalu disk NVMe dari laptop lama diekspor menggunakan modul Linux nvmet-tcp
    modprobe nvmet-tcp
cd /sys/kernel/config/nvmet
mkdir ports/0
cd ports/0
echo "ipv4" > addr_adrfam
echo 0.0.0.0 > addr_traaddr
echo 4420 > addr_trsvcid
echo tcp > addr_trtype
cd /sys/kernel/config/nvmet/subsystems
mkdir testnqn
echo 1 >testnqn/allow_any_host
mkdir testnqn/namespaces/1
cd testnqn


# replace the device name with the disk you want to export
echo "/dev/nvme0n1" > namespaces/1/device_path
echo 1 > namespaces/1/enable
ln -s "../../subsystems/testnqn" /sys/kernel/config/nvmet/ports/0/subsystems/testnqn
    • Dengan konfigurasi ini, perangkat target diekspos melalui NVMe over TCP
    • Di laptop baru, perangkat yang diekspor kemudian ditemukan dan dihubungkan
    nvme discover -t tcp -a <ip> -s 4420
nvme connectl-all -t tcp -a <> -s 4420
    • Setelah itu, perangkat yang terhubung di laptop baru bisa dicek lewat nvme list, lalu penyalinan disk dapat dilakukan

Penyalinan disk dan penyesuaian ukuran

  • Menyalin 512GB dengan dd

    • Penyalinan disk root dilakukan dengan perintah dd
    • Karena laptop baru tidak memiliki port Ethernet dan hanya menggunakan WiFi, penyalinan penuh 512GB memakan waktu sekitar 7 jam 30 menit
    • Kecepatan transfernya berada di kisaran 18~20MB/s
    • Alternatif lain adalah membuat partisi dan file system awal lalu menyalin disk root dengan rsync, atau menggunakan transfer file system bawaan BTRFS
    dd if=/dev/nvme2n1 of=/dev/nvme0n1 status=progress bs=40M

  • Memperluas partisi, LUKS, dan BTRFS

    • parted mendeteksi bahwa tabel partisi tidak sesuai dengan ukuran disk, lalu setelah konfirmasi otomatis memperbaikinya
    • Untuk memperluas partisi kedua, cloud-guest-utils dipasang dan growpart digunakan
    growpart /dev/nvem0n1 p2
    • Pada langkah berikutnya, ukuran kontainer LUKS diperbesar dengan cryptsetup
    cryptsetup luksOpen /dev/nvme0n1p2 ENC
cryptsetup resize ENC
    • Setelah reboot ke disk dan dipastikan berjalan normal, ukuran file system BTRFS disesuaikan setelah login
    • BTRFS harus dalam keadaan ter-mount untuk resize, sehingga tidak bisa dicoba saat boot live
    btfs fielsystem resize max /
    • Hasil akhirnya, laptop baru memberikan lingkungan yang terasa seperti tetap menggunakan laptop lama
    • Biasanya butuh sekitar 1~2 minggu untuk benar-benar beradaptasi dengan laptop baru, tetapi cara ini memangkas waktu tersebut
    • Bonusnya, ada juga pembelajaran tentang cara mengekspor disk lewat NVMe over TCP

Bacaan terkait

1 komentar

 
GN⁺ 2024-03-13
Komentar Hacker News

  • Dalam skenario penulis, pada akhirnya yang dilakukan hanya penyalinan blok serial dengan dd(1), jadi hampir tidak ada keuntungan memakai NVMe/TCP. Perintah yang rumit bisa diganti dengan netcat yang sederhana
    Laptop tujuan: $ nc -l -p 1234 | dd of=/dev/nvme0nX bs=1M
    Laptop sumber: $ nc x.x.x.x 1234
    dd di sisi tujuan dipakai untuk membuffer penulisan agar lebih cepat dan efisien. Jika menambahkan gzip/gunzip di sumber/tujuan, proses bisa jauh lebih cepat saat disk tidak penuh dan ada banyak blok 0. Ini secara pribadi adalah cara favorit saya saat membuat image PC lewat jaringan, dan saya sudah beberapa kali melakukannya
    Di GigE, kompresi sering menjadi bottleneck, jadi sebaiknya berikan --fast ke gzip, atau lebih baik lagi pakai lz4/unlz4 alih-alih gzip/gunzip agar lebih cepat. Dulu saya pernah meng-image laptop Windows baru dengan NVMe 1TB lewat GigE, butuh sekitar 20 menit, dan karena ruang kosong terkompresi hampir menjadi 0, image hasilnya hanya 20GB. Biasanya saya menyimpan backup image lz4 itu, lalu beberapa tahun kemudian saat mendonasikan laptop, cukup pulihkan dengan unlz4 | dd, sangat praktis
    Namun saya belum tahu soal modul kernel Linux nvme-tcp, dan tiap hari memang selalu ada hal baru yang dipelajari. Ini tampaknya lebih berguna untuk me-mount filesystem di atas NVMe jarak jauh daripada untuk akses mentah dengan dd
    Sebagai tambahan, ukuran maksimum buffer pipe di Linux adalah 64kB, jadi secara teknis argumen dd bs=X tidak perlu lebih besar dari itu. Meski begitu, bs=1M juga tidak merugikan dan akan menggabungkan pembacaan 64kB sampai menjadi 1MB, sekaligus antisipasi jika ukuran pipe nanti membesar. Beberapa versi netcat punya opsi ukuran blok I/O sehingga dd bs=X tidak diperlukan, tetapi netcat di disk pemulihan biasanya versi yang tidak punya opsi itu

    • Buffer pipe Linux bisa diperbesar, dan nilai maksimum bawaannya setahu saya biasanya sekitar 1MB. Memang agak repot dilakukan dari command line, tetapi ada contoh implementasi yang memungkinkan di https://unix.stackexchange.com/a/328364
    • Memang agak berantakan, tetapi jika memakai pv di kedua sisi alih-alih dd, tidak perlu khawatir menentukan ukuran blok yang tepat, dan grafik progresnya juga enak dilihat
    • Sekitar 9 tahun lalu saya pernah datang sebagai konsultan ke perusahaan yang mengalami peretasan internal, dan salah satu salah satu pendiri yang menyimpan dendam telah menyiapkan semacam dead man's switch yang menyalin 20MB awal dari semua disk ke suatu bucket lalu menimpanya dengan 0. Untuk memulihkan data, kami harus merekonstruksi tabel partisi dengan testdisk, tetapi sebelumnya kami tidak ingin menyentuh disk yang rusak, jadi kami menyalin sekitar 40TB dengan flash disk pemulihan, netcat, dan drive
      Beberapa server slot RAID fisiknya sudah penuh, jadi tidak bisa memakai slot disk cadangan, dan kami kira-kira menggunakan dd if=/dev/sdc bs=xxx | gzip | nc -l -p 8888 beserta perintah kebalikannya di sisi lain. Hasilnya bekerja cukup baik. Satu hal yang perlu diperhatikan adalah mencoba kombinasi dd bs agar sesuai dengan ukuran sektor, karena ukuran yang tepat sangat memengaruhi throughput dd
    • Cara memakai dd seperti ini bisa menyebabkan kerusakan. Diperlukan iflag=fullblock agar blok tidak terpotong, dan walaupun mungkin hanya kebiasaan yang diikuti mentah-mentah, conv=sync juga tidak merugikan. Secara pribadi saya lebih memilih nc -l -p 1234 > /dev/nvme0nX
    • Jaringan lokal kebanyakan tampaknya tidak akan lebih cepat daripada kecepatan transfer SSD. Meski begitu, saya penasaran apakah ada alat kloning perangkat blok dengan I/O simultan untuk orang-orang yang punya lingkungan seperti itu
      Jika menambahkan pv ke pipeline, kita bisa melihat perkiraan waktu selesai, meskipun mungkin ada sedikit dampak pada performa

  • Terima kasih kepada AWS/Annapurna/Nitro/Lightbits karena telah membawa NVMe-over-TCP ke Linux
    https://www.techtarget.com/searchstorage/news/252459311/Ligh...
    “Konsorsium NVM Express meratifikasi NVMe/TCP sebagai binding transport layer pada November 2018. Standar ini berkembang dari basis kode yang awalnya diajukan ke NVM Express oleh tim engineering Lightbits.”
    https://www.lightbitslabs.com/blog/linux-distributions-nvme-...
    https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

  • Dibandingkan ini, yang di bawah tampak jauh lebih merepotkan: nbdkit file /dev/nvme0n1, nbdcopy nbd://otherlaptop localfile

    • Cara ini sebenarnya jauh lebih baik, karena nbdcopy bisa menangani sparse file, jumlah koneksi dan thread bisa disesuaikan dengan jumlah core, bisa memaksa flush sebelum selesai, dan progress bar juga bisa diaktifkan. Untuk drive yang tidak terenkripsi, TLS juga didukung

  • Baru-baru ini perlu memasang xubuntu di laptop baru. Dulu biasanya dikloning, tetapi kali ini ingin merapikan ulang beberapa pengaturan dari awal
    Sangat terbantu karena bisa transfer 10Gb/s lewat kabel USB-C. Pilihan lain satu-satunya cuma WiFi
    Tinggal colokkan kedua komputer satu sama lain, jaringan sementara akan terbentuk, lalu kirim saja dengan rsync. Dari tampilannya, link-nya sudah jenuh, jadi memakai protokol lain tampaknya tidak akan banyak berarti. Tentu belajar hal baru itu bagus, tetapi mungkin bukan pada saat sedang mengkloning laptop

    • Penasaran apakah itu langsung jalan begitu saja. Terakhir kali saya mencoba koneksi langsung selain Ethernet itu di era 90-an, jadi saya bertanya serius
    • Saya juga pernah melakukannya, tetapi agar jaringan bisa berfungsi saya harus membeli kabel Thunderbolt 4 yang harganya lebih dari 30 dolar. Kabel USB3-C biasa saja tidak cukup
      Transfernya sendiri sangat cepat, 1TB pindah dalam beberapa menit. Kali ini saya tidak memakai enkripsi, jadi jauh lebih sederhana
    • Penasaran apakah Anda mem-boot dari live disk lalu memindahkan seluruh filesystem, atau memasang sistem dasarnya dulu lalu hanya memindahkan file

  • Saya tidak paham kenapa tidak me-pipe btrfs lewat jaringan. Buat dulu snapshot btrfs, lalu btrfs send => nc => network => nc => btrfs receive, maka hanya blok yang terpakai yang akan ditransfer

    • Begitu melihat Anda memakai btrfs, itu juga yang pertama kali terpikir oleh saya. Saya selalu memakai btrfs send/receive lewat SSH dan hasilnya sangat bagus. Mestinya juga mudah menjalankan server SSH dari sesi live GRML
      Namun ada satu hal yang perlu diperhatikan. Di btrfs, snapshot tidak bisa dikirim secara rekursif, jadi kalau ada banyak snapshot rekursif, cukup sulit untuk mencerminkan struktur yang sama ke disk baru. Ini bisa terjadi di Docker/LXD/Incus. Saya suka btrfs, tetapi untuk send/receive rekursif, ZFS memang lebih baik

  • Baru-baru ini saya harus menyalin sekitar file 200GB lewat WiFi. Agar tidak harus mengulang dari awal kalau koneksi gagal, dan supaya tidak ada kehilangan data, saya memakai rsync, tetapi tetap butuh setidaknya 6 jam. Penasaran apakah ada cara yang lebih baik
    Dan saya juga ingin tahu jaminan apa yang diberikan metode dd. Apakah perlu membandingkan md5 perangkat blok hasilnya?

    • 6 jam untuk memindahkan 200GB lewat WiFi bukan throughput yang mengesankan untuk transfer lokal. Sepertinya sebaiknya memakai kabel Ethernet
      WiFi punya jauh lebih banyak potensi sumber bottleneck performa. Bahkan jika hanya satu perangkat saja yang dihubungkan ke router dengan kabel, sementara yang lain tetap nirkabel, itu sudah cukup membantu
    • Jika filenya sangat banyak dan kecil-kecil, besar kemungkinan bottleneck-nya adalah rsync yang mentransfer satu file pada satu waktu. Anda bisa membagi daftar file dengan xargs/parallel lalu menjalankan beberapa instance rsync, atau memakai sesuatu seperti rclone yang mendukung transfer paralel secara bawaan
    • 6 jam berarti kira-kira 10MB/s, jadi kemungkinan besar sebenarnya bisa jauh lebih cepat. Penasaran apakah Anda memakai -z untuk kompresi. Jika bisa memakai Ethernet, pada kebanyakan perangkat mestinya bisa mendekati 100MB/s, jadi sekitar 35 menit
    • Jika metode transfer rsync-nya lewat SSH, itu sering menjadi bottleneck. Secara historis OpenSSH pernah punya batasan performa yang aneh, dan untuk mengakalinya dulu bahkan sempat perlu patch yang tidak begitu dikenal. Jika CPU bukan bottleneck, mengaktifkan kompresi juga bisa membantu
    • WiFi berbagi media udara dengan semua perangkat nirkabel lain. Saat mendeteksi tabrakan, ia berhenti lalu menunggu selama waktu acak
      “Dalam jaringan komputer, carrier-sense multiple access with collision avoidance (CSMA/CA) adalah metode akses ganda jaringan yang menggunakan carrier sensing, tetapi node baru mulai mentransmisikan setelah kanal terdeteksi ‘idle’, dalam upaya menghindari tabrakan. Saat mentransmisikan, node mengirim seluruh data paketnya
      Ini sangat penting khususnya untuk jaringan nirkabel, karena pemancar nirkabel tidak dapat mendeteksi tabrakan saat sedang mengirim paket, karena penerimanya dibuat tidak peka dan dimatikan selama transmisi paket
      CSMA/CA tidak dapat diandalkan karena masalah hidden node
      CSMA/CA adalah protokol yang bekerja di lapisan data link.”
      https://en.wikipedia.org/wiki/Carrier-sense_multiple_access_...

  • Pendekatan ini punya kelebihannya, tetapi dulu saat memindahkan laptop saya menjalankan installer di kedua sisi lalu menggabungkan dd dan nc. Kalau tidak salah, saya juga menambahkan gzip agar area nol yang besar bisa ditransfer lebih cepat
    Jika laptop baru tidak punya port Ethernet, cara saya yang agak hacky mungkin sedikit lebih cepat berkat kompresi. Lagi pula, pada link jaringan yang cepat, saya tidak akan mendekati batas yang ditambahkan oleh kompresi

    • Jika dalam keadaan full-disk encryption, maka tanpa memberi tahu LUKS untuk meneruskan TRIM, dengan cara yang dijelaskan penulis Anda pada dasarnya hanya akan mendapatkan data acak

  • Kenapa tidak pakai saja Clonezilla? Ia hanya menyalin blok data yang benar-benar terpakai dan juga bisa menyesuaikan ukuran partisi secara otomatis. Saya selalu begitu
    Tentu saja, biasanya saya mencabut disk NVMe dari laptop lalu memasangnya ke dock berkecepatan tinggi

    • Clonezilla memang bagus. Tugasnya satu dan biasanya berhasil pada percobaan pertama. Satu-satunya keluhan saya adalah kurva belajar awalnya membuat kita harus oprek sedikit
      Saya masih belum cukup percaya untuk membiarkannya tanpa pengawasan. Backup tidak sama dengan gabungan backup dan restore, jadi pengujian tetap disarankan. Clonezilla juga bisa bermasalah saat membuat ulang partisi ke disk yang sangat berbeda dari sumbernya

  • Sudah puluhan tahun saya tidak benar-benar “menginstal” sistem operasi di desktop atau laptop, dan selalu menyalin file lalu hanya menyesuaikan bagian yang perlu. Biasanya saya memanfaatkan kesempatan ini untuk membuat filesystem baru sambil memperbarui parameter seperti jenis filesystem, ukuran blok, enkripsi, dan semacamnya, lalu memindahkan file dengan rsync
    Meski begitu, kalau Anda tipe yang suka merencanakan dari awal, pendekatan yang lebih deklaratif seperti NixOS, yang hanya menyalin konfigurasi dan menginstal ulang sisanya secara otomatis, mungkin lebih baik

  • Jika perangkat-perangkat dihubungkan langsung lewat WiFi tanpa AP perantara, kecepatan transfer bisa meningkat dua kali lipat. Dalam situasi ini tampaknya cukup layak dicoba