Btrfs yedek dosya sistemi olarak uygun mudur?

Şu anda ext4'ün üstünde oldukça geleneksel bir yedekleme dosya sistemi yapısına sahibim. Her yedekleme yapıldığında, backup-DATEdosyaların rsync'ed edildiği yeni bir klasör oluşturulur (rsync'in --link-destseçeneği kullanılarak yapılan sabit bağlantılarla ).

Bitrot hakkında okuduğumdan, tüm dosyalar için şeffaf bir şekilde bir sağlama toplamı almak istiyorum. Görünüşe göre ext4 bunu yapamaz, ancak btrfs veri sağlama toplamları (ve yerleşik bir RAID1 modu) için destek sunar. Başlangıç ​​olarak, btrfsRAID, alt hacim anlık görüntüleri, gönderme / alma, vb. Gibi gelişmiş özelliklerini kullanmadan veri sağlama toplamlarını destekleyen "aptal" bir dosya sistemi olarak kullanmak istiyorum .

Ancak, wiki'leri yedekleme amaçları için dosya sistemine gerçekten güvenmiyor:

"Birçok kişi onu güvenilir bir şekilde kullanıyor olsa da, hala sorunlar var. Verilerinizin yedeklerini tutmalı ve test etmeli ve kullanmaya hazır olmalısınız." - Başlarken

"Btrfs kararlı mı? Uzun yanıt: [..] Ne yaparsanız yapın iyi, test edilmiş, sistem dışı (ve site dışı) yedeklemeler bulundurmanızı öneririz." - SSS .

Benim kullanım durumum çevrimdışı bir yedeğe sahip olmak. Bu nedenle disk çok az kullanım görür (saatlerde olduğu gibi) ve sık sık takılır / çıkarılır (eSATA veya USB 3.0). Güvenilir bir dosya sistemine sahip olmak şarttır. Ext4 wrt'den daha kötü olmamalıdır. elektrik kesintileri, kirli kapanmalar vb.

Aslında yedekleme amacıyla btrfs'nin dosya sistemi olarak kullanılması önerilir mi? Daha az (veya daha fazla) uygun hale getirebilecek diğer btrfs özellikleri var mı?

Ben sadece kısa bir cevap vereceğim çünkü bence bu aşırı düşünülüyor.

Ana çekirdek wiki'sini btrfs (alt-) komutları hakkında okursanız, iki komut vardır:

1. "yedek" yapma :btrfs-send
2. ve geri yükle :btrfs-restore

Her ihtimale karşı, bu bir yedek değil (bir yedek olmak için değil) bir yedek olarak değil, "esnek" olarak geri alınması fikri ile bir anlık görüntü dosya sistemi olduğu anlamına gelir.

Bu nedenle - hayır, yedekleme olarak kullanmayın - bir şeyi test edebileceğiniz ve geri dönebileceğiniz sürümlü bir dosya sistemi olarak kullanın. Ona güvenme.

Son zamanlarda güncel bir çekirdek 4.10.0'da bir btrfs dosya sistemiyle ilgili sorunlar yaşadım. Dosya sistemi bir sanal kutu sanal makinesinde imha edildi, çünkü TRIM bir yere doğru bir şekilde uygulanmadı ve AFAIK'in alt hacimlerin dizin sayılarıyla ilgisi vardı. VMware'e geçtikten sonra dosya sistemi hala bozuktu ve şaşırtıcı bir şekilde btrfs checkhatayı bulamadı ve düzeltemedi. Sonunda ext4'e geri döndüm.

İyi olan şey: Veri kaybetmedim. btrfs en azından okumak için her zaman tutarlı görünmektedir, ancak bana hala üretim hazırlığından çok uzak olduğunu gösterdi.

Her neyse, bir sunucuda hala yedekleme birimi olarak kullanıyorum çünkü tekilleştirme için inek kopyalama özelliğine ihtiyacım var (tam olarak kullanım durumunuz). Veriler, geleneksel bir dosya sistemi için çok fazla boyuttadır.

Güncelleme

Sunucumda hala dosya sistemi var (yukarıya bakın), ancak bunu buraya gönderdikten hemen sonra bozuldu. Şimdi, her şeyi kullanarak kopyalamaya çalışırsam ext4'te ~ 7 TB'a genişleyecek 700G'lik büyük bir salt okunur yedekleme hacmim var tar|tar. Zaman eksikliğinden dolayı, henüz yeni çekirdek sürümlerinin işleyip işlemediğini kontrol etmedim. Asıl sorun yazılabilir montajdan ~ 2 saniye sonra oluşan ve salt okunur hacmi yeniden dolduran bir "işlem iptali" dir. Orijinal neden muhtemelen btrfs-convertbu birimi oluşturduğumda yıllar önce kullandığım kırık bir versiyon ve hala btrfs checken azından bir işlemde geri dönüşe neden olan bir birimdeki tüm hasarları bulabilmesi gereken sınırlı bir özellik seti. dosya sistemimin sağlıklı olduğunu söylemek yerine