Apakah btrf cocok sebagai sistem file cadangan?


9

Saat ini saya memiliki struktur sistem file cadangan yang cukup tradisional di atas ext4. Setiap kali cadangan dibuat, folder baru backup-DATEdibuat untuk file yang rsync'ed (dengan hardlink dibuat menggunakan --link-destopsi rsync ).

Karena saya telah membaca tentang bitrot, saya ingin memiliki checksum untuk semua file, secara transparan. Tampaknya ext4 tidak dapat melakukan itu, tetapi btrf memang menawarkan dukungan untuk checksum data (dan bahkan mode RAID1 bawaan). Sebagai permulaan, saya ingin menggunakan btrfssistem file "bodoh" yang mendukung checksum data tanpa menggunakan fitur-fitur canggihnya seperti RAID, subvolume snapshots, kirim / terima, dll.

Namun, wiki mereka tidak benar-benar menginspirasi kepercayaan pada sistem file untuk keperluan backup:

"Sementara banyak orang menggunakannya dengan andal, masih ada masalah yang ditemukan. Anda harus menyimpan dan menguji cadangan data Anda, dan bersiaplah untuk menggunakannya." - Memulai

"Apakah btrf stabil? Jawaban panjang: [..] Apa pun yang kamu lakukan, sebaiknya simpan cadangan yang baik, teruji, off-system (dan off-site)." - FAQ .

Kasing penggunaan saya adalah memiliki cadangan offline. Karena alasan itu disk akan melihat sangat sedikit penggunaan (seperti dalam jam) dan akan sering dicolokkan / dicabut (eSATA atau USB 3.0). Memiliki sistem file yang dapat diandalkan adalah suatu keharusan. Itu tidak boleh lebih buruk dari ext4 wrt. gangguan listrik, pemadaman najis, dll.

Apakah sebenarnya disarankan untuk menggunakan btrfs sebagai sistem file untuk keperluan cadangan? Apakah ada properti lain dari btrf yang mungkin membuatnya kurang (atau lebih) cocok?


3
Lihat unix.stackexchange.com/questions/140360/… . Dengan BTRFS Anda dapat menggunakan snapshot subvolume alih-alih hardlink.
StrongBad

1
Anda dapat membaca artikel yang bagus tentang penggunaan btrfs di sini tetapi untuk cadangan saya akan merekomendasikan ZFS (yang ditemukan pada sistem BSD dan Solaris). Anda juga dapat menggunakannya di Linux wiki
kirill-a

@ StrongBad indikator ruang bebas yang dapat diandalkan jelas merupakan sesuatu di mana btrf tidak benar-benar unggul. Namun pertanyaannya bukan tentang mengganti hardlink dengan snapshot subvolume, melainkan keandalan btrfs sebagai sistem file untuk disk cadangan.
Lekensteyn

@ kirill-a Saya memang mempertimbangkan ZFS, tetapi karena ini bukan mainline, saya ragu untuk menggunakannya.
Lekensteyn

@Lekensteyn Saya pikir snapshot subvolume memenuhi syarat sebagai "Apakah ada properti lain dari btrf yang mungkin membuatnya kurang (atau lebih) cocok sebagai sistem file cadangan?"
StrongBad

Jawaban:


3

Saya hanya akan memberikan jawaban singkat karena saya pikir ini sedang dipikirkan.

Jika Anda membaca wiki kernel utama tentang perintah btrfs (sub-) , Anda akan menemukan bahwa ada dua perintah untuk:

  1. membuat "cadangan" :btrfs-send
  2. dan pulihkan :btrfs-restore

Untuk jaga-jaga, ini berarti bahwa itu bukan (dirancang untuk menjadi) cadangan, tetapi untuk menjadi sistem file snapshot, dengan gagasan untuk memutar kembali jika diperlukan, bukan sebagai cadangan tetapi sebagai "fleksibel".

Karena itu - tidak, jangan menggunakannya sebagai cadangan - gunakan sebagai sistem file berversi tempat Anda dapat menguji berbagai hal dan kembali. Jangan mengandalkan itu.


1

Baru-baru ini saya memiliki masalah dengan sistem file btrfs pada kernel 4.10.0 terbaru. Sistem file hancur di VM virtualbox karena TRIM tampaknya tidak diterapkan dengan benar di suatu tempat, dan AFAIK ada hubungannya dengan nomor indeks sub volume. Setelah beralih ke VMware, sistem file masih rusak dan yang mengejutkan btrfs checktidak dapat menemukan dan memperbaiki kesalahan. Akhirnya saya beralih kembali ke ext4.

Hal yang baik: Saya tidak kehilangan data. btrfs tampaknya selalu konsisten setidaknya untuk membaca, tetapi itu menunjukkan saya masih jauh dari kesiapan produksi.

Bagaimanapun, pada server saya masih menggunakannya sebagai volume cadangan karena di sana saya memerlukan fitur copy-sapi untuk deduplikasi (tepatnya case use Anda). Ukuran data terlalu banyak untuk sistem file tradisional.

Memperbarui

Saya masih memiliki filesystem di server saya (lihat di atas), tetapi rusak setelah saya memposting ini di sini. Sekarang, saya memiliki volume cadangan read-only besar 700G yang akan diperluas ke ~ 7TB pada ext4 jika saya mencoba untuk menyalin semuanya menggunakan tar|tar. Karena kurangnya waktu, saya belum memeriksa apakah versi kernel yang lebih baru dapat menanganinya. Masalah sebenarnya adalah "transaksi dibatalkan" yang terjadi ~ 2 detik setelah pemasangan dapat ditulisi dan yang menghitung ulang volume hanya-baca. Penyebab asli mungkin adalah versi yang rusak btrfs-convert, yang saya gunakan bertahun-tahun yang lalu ketika saya membuat volume ini, dan masih set fitur terbatas saat ini btrfs checkyang setidaknya harus dapat menemukan semua kerusakan pada volume yang secara reproduktif menyebabkan pengguguran transaksi atau masalah lain, alih-alih hanya mengatakan bahwa sistem file saya sehat.

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.