Coba tar
, pax
, cpio
, dengan sesuatu buffering.
(cd /home && bsdtar cf - .) |
pv -trab -B 500M |
(cd /dest && bsdtar xpSf -)
Saya menyarankan bsdtar
alih-alih tar
karena setidaknya pada beberapa distribusi Linux tar
adalah GNU tar yang bertentangan dengan bsdtar
(dari libarchive
) tidak menangani pelestarian atribut yang diperluas atau ACL atau atribut linux.
pv
akan buffer hingga 500 juta data sehingga dapat mengakomodasi fluktuasi kecepatan baca dan tulis pada kedua sistem file dengan lebih baik (meskipun dalam kenyataannya, Anda mungkin akan memiliki disk yang lebih lambat sehingga yang lain dan mekanisme penulisan kembali OS akan melakukan buffering sebagai baik jadi itu mungkin tidak akan membuat banyak perbedaan). Versi lama yang pv
tidak mendukung -a
(untuk pelaporan kecepatan rata-rata), Anda dapat menggunakannya pv -B 200M
sendirian di sana.
Bagaimanapun, mereka tidak akan memiliki batasan cp
, yang membaca dan menulis secara berurutan. Di sini kita punya dua yang tar
bekerja bersamaan, sehingga yang satu dapat membaca satu FS sementara yang lain sibuk menunggu FS yang lain selesai menulis.
Untuk ext4 dan jika Anda menyalin ke partisi yang setidaknya sama besar dengan sumbernya, lihat juga clone2fs
yang berfungsi ntfsclone
, yaitu menyalin blok yang dialokasikan saja dan secara berurutan, jadi pada penyimpanan rotasi mungkin akan menjadi yang paling efisien.
partclone menggeneralisasikan itu ke beberapa sistem file yang berbeda.
Sekarang beberapa hal yang perlu dipertimbangkan ketika kloning sistem file.
Kloning akan menyalin semua direktori, file dan isinya ... dan yang lainnya. Sekarang segalanya berbeda dari sistem file ke sistem file. Bahkan jika kita hanya mempertimbangkan fitur umum dari sistem file Unix tradisional, kita harus mempertimbangkan:
- tautan: tautan simbolik dan tautan keras. Terkadang, kita harus mempertimbangkan apa yang harus dilakukan dengan symlink absolut atau symlink yang menunjukkan sistem file / direktori untuk dikloning
- modifikasi terakhir, akses dan waktu perubahan: hanya dua yang pertama yang dapat disalin menggunakan API sistem file (cp, tar, rsync ...)
- sparseness: Anda mendapatkan file jarang 2TB yang merupakan disk image VM yang hanya membutuhkan 3GB ruang disk, sisanya jarang, melakukan salinan naif akan mengisi drive tujuan.
Kemudian jika Anda mempertimbangkan ext4
dan sebagian besar sistem file Linux, Anda harus mempertimbangkan:
- ACL dan atribut diperluas lainnya (seperti yang digunakan untuk
SELinux
)
- Atribut Linux seperti flag immutable atau append-only
Tidak semua alat mendukung semua itu, atau ketika mereka melakukannya, Anda harus mengaktifkannya secara eksplisit seperti --sparse
, --acls
... opsi rsync
, tar
... Dan ketika menyalin ke sistem file yang berbeda, Anda harus mempertimbangkan kasus di mana mereka tidak mendukung set fitur yang sama.
Anda mungkin juga harus mempertimbangkan atribut sistem file itu sendiri seperti UUID, ruang yang disediakan untuk root, frekuensi fsck, perilaku penjurnalan, format direktori ...
Lalu ada sistem file yang lebih kompleks, di mana Anda tidak dapat benar-benar menyalin data dengan menyalin file. Pertimbangkan misalnya zfs
atau btrfs
ketika Anda dapat mengambil snapshot dari subvolume dan cabut mereka ... Mereka akan memiliki alat khusus mereka sendiri untuk menyalin data.
Salinan byte ke byte perangkat blok (atau setidaknya blok yang dialokasikan bila memungkinkan) sering kali paling aman jika Anda ingin memastikan bahwa Anda menyalin semuanya. Namun waspadalah terhadap masalah bentrokan UUID, dan itu menyiratkan Anda menyalin ke sesuatu yang lebih besar (meskipun Anda dapat mengubah ukuran salinan snapshot dari sumber sebelum menyalin).
cp
lambat, metode lain juga akan lambat. Kecuali jika itu bukan penyalinan berorientasi file