Cara menyalin sistem file btrfs

Bagaimana cara membuat salinan lengkap dari isi sistem file btrfs? Dengan salinan lengkap yang saya maksud bukan hanya data saat ini , tetapi juga subvolume yang berbeda dengan snapshot mereka , idealnya menjaga struktur Kontrak Karya mereka (yaitu: tidak menduplikasi blok dengan konten yang sama.

Tampaknya salinan level blok (seperti dengan dd) bukan ide yang baik, karena duplikat UUID, dan tampaknya tidak ada cara untuk dengan mudah mengubahnya .

Opsi 1 - Salin data bodoh kemudian ubah UUID

Pastikan partisi sumber tidak di-mount dan tidak akan di-otomatiskan.

Gunakan salah satu dd(lambat, bisu) ataupartclone.btrfs -b -s /dev/src -o /dev/target

Gunakan btrfstune -uuntuk mengubah UUID setelah menyalin dan sebelum pemasangan.

Data kerugian peringatan : Do NOT mencoba untuk (auto) me-mount baik asli atau salinan sampai UUID telah berubah

Pilihan 2 - btrfs-clone

Saya belum mencoba secara pribadi btrfs-clone, tetapi dimaksudkan untuk mengkloning sistem file BTRFS yang ada ke yang baru, mengkloning setiap subvolume secara berurutan.

Saya belum menemukan solusi yang siap pakai sampai hari ini (2016-05-06), tetapi menyelesaikan masalah untuk tujuan saya, termasuk penanganan Copy-on-Write. Langkah-langkah untuk "clone" /sourceuntuk /targetadalah:

1. Dapatkan daftar sub-volume diperintahkan oleh ogen: btrfs subvolume list -qu --sort ogen /source. Penyortiran mungkin cukup untuk menjamin bahwa snapshot atau subvolume yang bergantung pada yang sebelumnya ditangani terlebih dahulu. Ini penting untuk berurusan dengan Copy-on-Write, karena kita perlu mentransfer volume dasar terlebih dahulu.

2. Buat semua subvolume hanya-baca menggunakan btrfs property set -ts /source/some-volume ro true.

3. Sekarang, untuk setiap subvolume dari daftar di atas, mulai dari atas, lakukan hal berikut:

   1. Jika volume tidak memiliki UUID induk (ditampilkan sebagai -) atau UUID induk tidak ada lagi dalam daftar, jalankan:btrfs send /source/some/volume | btrfs receive /target/some/

   2. Jika volume memang memiliki UUID induk yang masih ada, kita seharusnya sudah mentransfernya karena --sort ogendan kita dapat menggunakannya sebagai basis untuk menghindari duplikasi data. Oleh karena itu, cari jalur induk UUID di daftar dan jalankan: btrfs send -p /source/parent/volume/ -c /source/parent/volume/ /source/some/volume/ | btrfs receive /target/some/(btrfs mungkin akan menebak -pargumen secara otomatis, tetapi saya lebih memilih untuk menjadi eksplisit).

   3. Setelah menjalankan salah satu perintah di atas membuat target dan sumber baca-tulis lagi: btrfs property set -ts /source/some/volume ro false; btrfs property set -ts /target/some/volume ro false. Langkah ini dapat dilewati jika sumber sebelumnya hanya-baca.

Ini harus menangani banyak kasus. Peringatan:

1. Mungkin ada beberapa komplikasi sehubungan dengan pemesanan saat membuat subvolume / snapshot.

2. Seluruh proses jelas lebih menyenangkan ketika dituliskan.

3. btrfs sendmenerima beberapa -cargumen sumber klon ( ). Mungkin menguntungkan untuk tidak hanya menentukan jalur volume induk, tetapi juga jalur leluhur atau volume apa pun yang sebelumnya dikirim. Itu tidak membuat perbedaan di sini, tetapi mungkin - hanya tebakan - membantu untuk menghindari duplikasi data dalam beberapa kasus.

4. Saya tidak yakin apakah ada informasi meta tentang snapshot atau subvolume yang hilang di sepanjang jalan, tetapi hampir semua hal menarik lainnya untuk sebagian besar kasus penggunaan harus dipertahankan.

Seluruh proses membantu saya mentransfer sistem file 800 GB dengan 3,8 GB yang digunakan (menurut df) ke gambar 10 GB dengan 3,8 GB yang digunakan. Mentransfer tanpa -pdan -cakan menggunakan sekitar 190 GB, sehingga duplikasi data memang dihindari.

Saya telah membuat alat python yang dapat melakukan ini. Saya melakukan ini karena saya mencoba pendekatan @Thomas Luzat di implementasi saya sendiri dan @Johannes Ernst, dan ruang yang digunakan dua kali lipat dari 20GB menjadi 40GB dalam prosedur kloning. Saya pikir sesuatu yang lebih efisien diperlukan.

Pertimbangkan riwayat sistem file yang umum ini:

current ---------------------------------\
             |       |        |          |
           snap4   snap3    snap2      snap1

Dengan algoritma Thomas, "saat ini" akan dikloning terlebih dahulu, dan semua snapshot (menjadi snapshot dari status "saat ini") akan menggunakan "saat ini" sebagai sumber / induk klon. Jelas, akan lebih baik untuk mendasarkan snap3 pada snap4, snap2 pada snap3, dll.

Dan ini hanyalah puncak gunung es; menemukan sumber klon "terbaik" (dalam hal penghematan ruang) dalam sistem file btrfs dengan sejarah yang kompleks adalah masalah yang tidak sepele. Saya telah datang dengan 3 strategi lain untuk menyelesaikan masalah ini, yang tampaknya menggunakan ruang jauh lebih efisien. Seseorang benar-benar menghasilkan ukuran klon sedikit di bawah sumbernya.

Anda dapat membaca detailnya di halaman github jika Anda tertarik.

Ada pertanyaan serupa di unix.stackexchange.com yang menunjuk ke partclone.btrfs, tapi saya tidak tahu spesifik tentang hal ini.

Ada juga diskusi di mailing list kernel , tidak benar-benar terlihat menjanjikan ...

Dengan btrfs-send, yang terakhir saya lihat, masih patch eksperimental melayang di milis btrfs.