วิธีคัดลอกระบบไฟล์ btrfs


17

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

ดูเหมือนว่าสำเนาระดับบล็อก (เช่นมีdd) ไม่ได้เป็นความคิดที่ดีเพราะมันทำซ้ำ UUID และไม่มีทางที่จะสามารถเปลี่ยนมันเห็นได้ชัด

คำตอบ:


4

ตัวเลือก 1 - คัดลอกข้อมูลเป็นใบ้จากนั้นเปลี่ยน UUID

ตรวจสอบให้แน่ใจว่าไม่ได้ต่อเชื่อมพาร์ติชันต้นทางและจะไม่ถูกเมาต์อัตโนมัติ

ใช้อย่างใดอย่างหนึ่งdd(ช้าใบ้) หรือpartclone.btrfs -b -s /dev/src -o /dev/target

ใช้btrfstune -uเพื่อเปลี่ยน UUID หลังจากการคัดลอกและก่อนการติดตั้ง

คำเตือนการสูญเสียข้อมูล : ทำไม่ได้พยายามที่จะ (อัตโนมัติ) ติดทั้งต้นฉบับหรือคัดลอกจน UUID มีการเปลี่ยนแปลง


ตัวเลือก 2 - btrfs-clone

ฉันไม่ได้ลองเป็นการส่วนตัวbtrfs-cloneแต่เป็นการอ้างว่าจะโคลนระบบไฟล์ BTRFS ที่มีอยู่ไปเป็นระบบใหม่โดยทำการโคลนแต่ละไดรฟ์ย่อยตามลำดับ


1
เพื่อความสมบูรณ์นี่ถูกเพิ่มเป็นตัวเลือกสำหรับ btrfs-progs ในช่วงปี 2558: github.com/kdave/btrfs-progs/commit/
......

16

ฉันไม่พบวิธีแก้ปัญหาใด ๆ ณ วันนี้ (2016-05-06) แต่แก้ไขปัญหาสำหรับวัตถุประสงค์ของฉันรวมถึงการจัดการ Copy-on-Write ขั้นตอนในการ "โคลน" /sourceถึง/targetคือ:

  1. รับรายชื่อของ subvolumes รับคำสั่งจาก:ogen btrfs subvolume list -qu --sort ogen /sourceการเรียงลำดับอาจเพียงพอที่จะรับประกันได้ว่าสแน็ปช็อตหรือไดรฟ์ย่อยที่ขึ้นอยู่กับรายการก่อนหน้าจะได้รับการจัดการก่อน นี่เป็นสิ่งสำคัญสำหรับการจัดการกับการคัดลอกเมื่อเขียนเนื่องจากเราจำเป็นต้องโอนปริมาณพื้นฐานก่อน

  2. ทำให้ subvolumes btrfs property set -ts /source/some-volume ro trueทั้งหมดอ่านอย่างเดียวโดยใช้

  3. ทีนี้สำหรับแต่ละหัวข้อย่อยจากรายการด้านบนเริ่มต้นที่ด้านบนทำต่อไปนี้:

    1. หากปริมาณไม่มี UUID หลัก (แสดงเป็น-) หรือ UUID หลักไม่มีอยู่อีกต่อไปในรายการให้รัน:btrfs send /source/some/volume | btrfs receive /target/some/

    2. หากปริมาณมี UUID หลักที่ยังคงมีอยู่เราควรโอนย้ายไปแล้วเนื่องจาก--sort ogenและเราสามารถใช้เป็นฐานเพื่อหลีกเลี่ยงการทำซ้ำข้อมูล ดังนั้นค้นหาพา ธ ของ UUID ของผู้ปกครองในรายการและเรียกใช้: btrfs send -p /source/parent/volume/ -c /source/parent/volume/ /source/some/volume/ | btrfs receive /target/some/(btrfs อาจจะคาดเดา-pข้อโต้แย้งโดยอัตโนมัติ แต่ฉันชอบที่จะชัดเจน)

    3. btrfs property set -ts /source/some/volume ro false; btrfs property set -ts /target/some/volume ro falseหลังจากที่ทำงานของคำสั่งดังกล่าวทำให้เป้าหมายและแหล่งที่มาอ่านเขียนอีกครั้ง: สามารถข้ามขั้นตอนนี้ได้หากแหล่งที่มาเป็นแบบอ่านอย่างเดียวก่อนหน้านี้

สิ่งนี้ควรจัดการกับหลายกรณี คำเตือน:

  1. อาจมีปัญหาบางอย่างเกี่ยวกับการสั่งซื้อเมื่อทำการซ้อน subvolumes / snapshots

  2. เห็นได้ชัดว่ากระบวนการทั้งหมดนั้นสนุกมากขึ้นเมื่อใช้สคริปต์

  3. btrfs sendยอมรับ-cข้อโต้แย้งหลายแหล่งที่มาของโคลน ( ) มันอาจเป็นประโยชน์ที่ไม่เพียง แต่ระบุเส้นทางเสียงของผู้ปกครอง แต่ยังรวมถึงเส้นทางของบรรพบุรุษหรือเพียงแค่ปริมาณที่ส่งก่อนหน้านี้ มันไม่ได้สร้างความแตกต่างที่นี่ แต่อาจเป็นเพียงการเดาเพื่อช่วยหลีกเลี่ยงการทำซ้ำข้อมูลในบางกรณี

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

กระบวนการทั้งหมดช่วยให้ฉันถ่ายโอนระบบไฟล์ 800 GB ที่ใช้ 3.8 GB (ตามdf) ไปยังอิมเมจ 10 GB ที่ใช้ 3.8 GB การถ่ายโอนโดยไม่มี-pและ-cจะใช้ประมาณ 190 GB ดังนั้นการทำสำเนาข้อมูลจึงหลีกเลี่ยงได้แน่นอน


คำตอบที่เขียนเป็นอย่างดีขอบคุณ คุณช่วยอธิบายความogenหมายได้อย่างไร
drumfire

@drumfire ogenเป็น "กำเนิดรุ่น" ของ subvolume ฉันต้องยอมรับว่าฉันไม่เข้าใจความแตกต่างอย่างสมบูรณ์หรือไม่ว่าการใช้รุ่น (ที่ไม่ใช่แหล่งกำเนิด) จะถูกต้อง แต่สมมติว่ามีการทดสอบบางอย่างระบุว่าสิ่งนี้ทำงานได้ดีขึ้น (หลีกเลี่ยงการทำซ้ำ) การสร้างดูเหมือนจะได้รับการปรับปรุงเมื่อสร้างสแนปชอตโดยอ้างอิงจากไดรฟ์ย่อย ฉันสนใจที่จะฟังเกี่ยวกับสิ่งที่ค้นพบ อาจเป็นการดีที่สุดที่จะตรวจสอบ IRC หรือรายชื่อผู้รับจดหมาย Btrfs
โทมัส Luzat

2
ฉันเอาอัลกอริทึมของ @ThomasLuzat เสริมปุยบางรอบ (ข้อผิดพลาดในการตรวจสอบ ฯลฯ ) และวางไว้ที่นี่: github.com/jernst/btrfs-copy-filesystem/blob/master/... มันใช้งานได้สำหรับปัญหาของฉันในการปิดดิสก์ที่เสียหายและไม่มีการรับประกันว่ามันจะใช้ได้กับทุกคน แต่ฉันจะโพสต์สิ่งนี้ที่นี่ในกรณีที่ทุกคนต้องการเริ่มจากที่อื่นนอกเหนือจากการลบรหัสนี้ ขณะนี้ขึ้นอยู่กับวิธี UBOS ใหม่ แต่ควรง่ายต่อการพอร์ต
Johannes Ernst

6

ฉันได้สร้างเครื่องมือหลามซึ่งสามารถทำได้ ฉันทำสิ่งนี้เพราะฉันได้ลองวิธีการของ @Thomas Luzat ทั้งของฉันเองและ @Johannes Ernst และการใช้พื้นที่สองเท่าจาก 20GB ถึง 40GB ในขั้นตอนการโคลนนิ่ง ฉันคิดว่าบางสิ่งจำเป็นต้องมีประสิทธิภาพมากขึ้น

พิจารณาประวัติระบบไฟล์ทั่วไปนี้:

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

ด้วยอัลกอริธึมของโทมัส "กระแส" จะถูกโคลนก่อนและสแนปชอตทั้งหมด (เป็นสแน็ปช็อตของอดีตรัฐของ "กระแส") จะใช้ "กระแส" เป็นแหล่งกำเนิด / ผู้ปกครองโคลน เห็นได้ชัดว่ามันจะดีกว่าถ้าจะยึดฐาน snap3 บน snap4, snap2 บน snap3 ฯลฯ

และนี่เป็นเพียงส่วนปลายของภูเขาน้ำแข็ง การค้นหาแหล่งโคลนที่ดีที่สุด (ในแง่ของการประหยัดพื้นที่) ในระบบไฟล์ btrfs ที่มีประวัติที่ซับซ้อนเป็นปัญหาที่ไม่สำคัญ ฉันคิดหากลยุทธ์ 3 อย่างเพื่อแก้ปัญหานี้ซึ่งดูเหมือนว่าจะใช้พื้นที่ได้อย่างมีประสิทธิภาพมากขึ้น มีผลทำให้ขนาดของโคลนจริงต่ำกว่าแหล่งที่มาเล็กน้อย

คุณสามารถอ่านรายละเอียดได้ที่หน้า GitHubหากคุณสนใจ


2

มีคำถามคล้ายกันใน unix.stackexchange.comที่ชี้ไปที่ partclone.btrfs แต่ฉันไม่ทราบรายละเอียดใด ๆ เกี่ยวกับเรื่องนี้

นอกจากนี้ยังมีการอภิปรายในรายชื่อส่งเมลเคอร์เนลไม่ได้ดูมีแนวโน้ม ...


2

ด้วยbtrfs-sendซึ่งครั้งสุดท้ายที่ฉันเห็นก็ยังแพทช์ทดลองลอยรอบในรายการ btrfs ทางไปรษณีย์


linuxreviews.org/Btrfsนี้wiki มักจะมีคำแนะนำที่ดี
dotbit
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.