strategi partisi dan subvol dengan btrfs


10

Saya baru mengenal btrfs dan saya ingin saran tentang strategi partisi dan subvolume. Sistem ini adalah server web tugas ringan, dan menganggapnya hanya memiliki satu disk.

Dengan sistem file ext, saya selalu membuat partisi terpisah untuk /, / var, swap (dan mungkin / boot dan / home). Bagi saya, / var selalu berisi semua data server web yang berharga (mis. Database MySQL) dan tidak ada kode. Itu memungkinkan saya untuk dengan mudah memindahkan data ke sistem yang berbeda (memindahkan atau menyalin / var) atau menginstal ulang OS tanpa mengganggu data (memformat /) dll.

Menggunakan btrfs, saya bisa melakukan hal yang sama, menggunakan skema partisi yang sama, dan memiliki sistem file btrfs terpisah pada setiap partisi. Atau, saya dapat memiliki satu partisi, dan menggunakan subvolume btrfs untuk /, / var dan sebagainya. Apa yang akan menjadi pro dan kontra dari itu?

Menurut saya mungkin ada beberapa keuntungan dalam memiliki snapshot / -only dan / var-only, misalnya ("Kembalikan semua data ke pos pemeriksaan sebelumnya" vs "kembalikan semua kode" vs "kembalikan keduanya"). Apakah itu benar, atau apakah hanya tampak seperti itu?

Pertanyaan bonus: apakah ada keuntungan menggunakan lvm di bawah sistem file btrfs?

Pertanyaan bonus 2: bagaimana saran Anda berubah jika sistem memiliki dua disk dengan ukuran yang sama?

Setiap petunjuk untuk "ini adalah apa yang saya lakukan dan bagaimana itu bekerja untuk saya" artikel juga akan dihargai. Saya dapat menemukan banyak materi tentang apa yang dapat saya lakukan, tetapi saya gagal menemukan banyak yang mengatakan "ini adalah apa yang saya coba dan inilah mengapa ini berhasil atau tidak".


1
Pertanyaan bagus! Saya ingin bertanya hampir sama. Saya ingin menggunakan enkripsi raid1 dan luks, tetapi sulit untuk menemukan info yang relevan tentang dasar-dasarnya. Misalnya apakah saya dapat menginstal sistem op pada volume duplikat tunggal dan dapat menggunakan subvolume untuk / swap, dll. Tanpa kekurangan. Mungkin saya harus membaca manual, tetapi saya tidak suka teks yang panjang. : D
inf3rno

Jawaban:


6

Jika Anda tidak memiliki kebutuhan khusus, gunakan btrfs karena Anda akan menggunakan sistem file lain. Memisahkan / rumah adalah praktik yang baik.

Secara pribadi, pada server rumah, satu-satunya subvolume saya adalah / etc, jadi saya dapat membuat snapshots dari konfigurasi. Ini dapat diotomatisasi dengan alat seperti kakap.

Biasanya, ada sedikit minat memulihkan hanya versi / var sebelumnya, karena kebutuhan untuk juga mengembalikan / lib / barang. Ini adalah situasi semua atau tidak sama sekali.

Snapshots dari / home bisa SANGAT besar, sehingga manajemen ukuran disk segera menjadi masalah. Ini bisa dilakukan tanpa masalah, tapi awasi ruang yang tersisa. Juga, karena snapshot hanya dapat dibuat pada disk yang sama, itu bukan solusi untuk cadangan jika terjadi kegagalan disk. Anggap mereka sebagai sesuatu untuk situasi seperti "oups, saya menghapus file ini dua jam yang lalu, tetapi saya masih membutuhkannya".

Bonus 1: tidak ada. Bahkan, btrfs dirancang untuk menyederhanakan stack mdadm + lvm + fs. Jadi lebih baik menghindarinya.

Bonus 2: Tidak, tetapi buatlah RAID 1! Sederhana dan efisien, data Anda akan mencintaimu :)

Bonus Ninja: Anda mungkin benar-benar ingin melihat-lihat wiki btrfs .


btrfs mendukung mirroring dan konfigurasi RAID'ish lainnya. Bahkan Anda harus menghindari mereproduksi RAID6, Anda dapat dengan mudah membuat mirror hanya dengan menambahkan partisi setelah instalasi. Anda bisa menemukan caranya di sini ( complang.tuwien.ac.at/anton/btrfs-raid1.html )
JOduMonT

0

Saya telah meninjau kembali akhir-akhir ini dan berpikir saya akan berbagi posting dipikirkan dengan sangat baik yang mengusulkan satu partisi dengan direktori tingkat atas yang mengandung subvolume: https://bbs.archlinux.org/viewtopic.php?id=194491

TL; DR

subvolid=0
      ├── subvol_root
      │        └── /usr, /bin, /sbin, /.snapshots, etc
      ├── subvol_snapshots
      ├── subvol_home
      └── subvol_opt
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.