btrfs เหมาะสมกับระบบไฟล์สำรองหรือไม่?

ตอนนี้ฉันมีโครงสร้างระบบไฟล์สำรองแบบดั้งเดิมที่ยอดเยี่ยมของ ext4 ทุกครั้งที่ทำการสำรองข้อมูลโฟลเดอร์ใหม่backup-DATEจะถูกสร้างขึ้นซึ่งไฟล์ใดเป็น rsync'ed (โดยมีการทำลิงก์โดยใช้--link-destตัวเลือกของ rsync )

ตั้งแต่ฉันได้อ่านเกี่ยวกับ bitrot ฉันต้องการตรวจสอบไฟล์ทั้งหมดอย่างโปร่งใส เห็นได้ชัดว่า ext4 ไม่สามารถทำได้ แต่ btrfs รองรับการตรวจสอบข้อมูล (และแม้กระทั่งโหมด RAID1 ในตัว) สำหรับการเริ่มต้นฉันต้องการใช้btrfsเป็นระบบไฟล์ "dumb" ซึ่งรองรับการตรวจสอบข้อมูลโดยไม่ใช้คุณสมบัติขั้นสูงเช่น RAID, สแน็ปช็อต subvolume, ส่ง / รับ ฯลฯ

อย่างไรก็ตามวิกิของพวกเขาไม่ได้สร้างแรงบันดาลใจให้กับความมั่นใจในระบบไฟล์เพื่อการสำรองข้อมูล:

"ในขณะที่คนจำนวนมากใช้อย่างน่าเชื่อถือ แต่ก็ยังพบปัญหาอยู่คุณควรเก็บและทดสอบการสำรองข้อมูลของคุณและเตรียมพร้อมที่จะใช้งาน" - เริ่มต้น

"btrfs เสถียรหรือไม่ตอบนาน: [.. ] ไม่ว่าคุณจะทำอะไรเราขอแนะนำให้ทำการสำรองข้อมูลที่ดีทดสอบนอกระบบ (และนอกสถานที่)" - คำถามที่พบบ่อย

กรณีการใช้งานของฉันคือการสำรองข้อมูลออฟไลน์ ด้วยเหตุนี้ดิสก์จะเห็นการใช้งานน้อยมาก (ในชั่วโมง) และจะถูกเสียบ / ถอดปลั๊ก (eSATA หรือ USB 3.0) บ่อยครั้ง ต้องมีระบบไฟล์ที่เชื่อถือได้ ต้องไม่เลวร้ายยิ่งกว่า ext4 wrt ไฟฟ้าขัดข้องการปิดเครื่องไม่สะอาด ฯลฯ

แนะนำให้ใช้ btrfs เป็นระบบไฟล์เพื่อการสำรองข้อมูลหรือไม่? มีคุณสมบัติอื่น ๆ ของ btrfs ซึ่งอาจทำให้มีความเหมาะสมน้อยลง (หรือมากกว่า)?

ฉันจะให้คำตอบสั้น ๆ เพราะฉันคิดว่านี่เป็นเรื่องที่คิดมากเกินไป

หากคุณอ่านเคอร์เนลหลักของ wiki เกี่ยวกับคำสั่ง btrfs (sub-)คุณจะพบว่ามีสองคำสั่งสำหรับ:

1. ทำ "สำรองข้อมูล" :btrfs-send
2. และคืนค่า :btrfs-restore

ในกรณีนี้หมายความว่ามันไม่ใช่การสำรองข้อมูล (ออกแบบให้เป็น) แต่เป็นระบบไฟล์สแน็ปช็อตโดยมีแนวคิดว่าจะย้อนกลับหากจำเป็นไม่ใช่เป็นข้อมูลสำรอง แต่เป็น "ยืดหยุ่น"

ดังนั้น - ไม่ใช้เป็นข้อมูลสำรอง - ใช้เป็นระบบไฟล์เวอร์ชันที่คุณสามารถทดสอบสิ่งต่าง ๆ และย้อนกลับ อย่าพึ่งมัน

ฉันเพิ่งมีปัญหากับระบบไฟล์ btrfs ในเคอร์เนลที่ทันสมัย ​​4.10.0 ระบบไฟล์ถูกทำลายใน virtualbox VM เพราะ TRIM ดูเหมือนจะไม่ถูกนำไปใช้อย่างถูกต้องที่ไหนสักแห่งและ AFAIK มีบางสิ่งที่เกี่ยวข้องกับหมายเลขดัชนีของไดรฟ์ย่อย หลังจากเปลี่ยนมาใช้ VMware ระบบไฟล์ยังคงเสียหายและน่าประหลาดใจที่btrfs checkไม่สามารถค้นหาและแก้ไขข้อผิดพลาดได้ ในที่สุดฉันก็เปลี่ยนกลับเป็น ext4

สิ่งที่ดี: ฉันไม่ได้สูญเสียข้อมูล btrfs ดูเหมือนจะสอดคล้องกันอย่างน้อยเสมอสำหรับการอ่าน แต่มันแสดงให้ฉันเห็นว่ามันยังห่างไกลจากความพร้อมในการผลิต

อย่างไรก็ตามบนเซิร์ฟเวอร์ฉันยังคงใช้มันเป็นโวลุ่มการสำรองข้อมูลเพราะมีฉันต้องการคุณสมบัติของการคัดลอกวัวสำหรับการคัดลอกข้อมูลซ้ำ ข้อมูลมีขนาดใหญ่เกินไปสำหรับระบบไฟล์ดั้งเดิม

ปรับปรุง

ฉันยังคงมีระบบไฟล์บนเซิร์ฟเวอร์ของฉัน (ดูด้านบน) แต่มันยากจนทันทีหลังจากที่ฉันโพสต์ที่นี่ ตอนนี้ผมต้องอ่านอย่างเดียวปริมาณสำรองใหญ่ของ 700G ซึ่งจะขยายไปยัง ~ 7TB บน ext4 tar|tarถ้าฉันพยายามที่จะคัดลอกออกไปทุกอย่างโดยใช้ เนื่องจากไม่มีเวลาฉันยังไม่ได้ตรวจสอบว่าเคอร์เนลที่ใหม่กว่าสามารถจัดการได้หรือไม่ ปัญหาที่แท้จริงคือ "ทรานแซคชันการยกเลิก" ซึ่งจะเกิดขึ้น ~ 2 วินาทีหลังจากการติดตั้งแบบเขียนได้และที่เมานต์ปริมาณอ่านอย่างเดียว สาเหตุดั้งเดิมน่าจะเป็นรุ่นbtrfs-convertที่ใช้งานไม่ได้ซึ่งฉันใช้เมื่อหลายปีก่อนเมื่อฉันสร้างโวลุ่มนี้และยังคงมีชุดคุณสมบัติที่ จำกัด ในปัจจุบันbtrfs checkซึ่งอย่างน้อยน่าจะสามารถพบความเสียหายทั้งหมดในปริมาณที่ทำซ้ำได้ หรือปัญหาอื่น ๆ แทนที่จะบอกว่าระบบไฟล์ของฉันแข็งแรง