ฉันกำลังพยายามค้นหาว่าสแน็ปช็อต LVM ทำงานอย่างไร ดังนั้นฉันจึงสามารถนำไปใช้กับไฟล์เซิร์ฟเวอร์ของฉันได้ แต่ฉันมีปัญหาในการค้นหาสิ่งใดบน Google ที่อธิบายวิธีการทำงาน แทนที่จะใช้สำหรับระบบสำรองข้อมูลพื้นฐาน

จากที่อ่านมา คิดว่าน่าจะประมาณนี้

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

ใครสามารถแก้ไขฉันที่ฉันผิด อย่างดีที่สุด ฉันเดาว่าฉันไม่พบสิ่งใดใน google


vgdiplay

obu1:/home/jail/home/qps/backup/D# vgdisplay
  --- Volume group ---
  VG Name               fileserverLVM
  System ID
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  3
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                2
  Open LV               2
  Max PV                0
  Cur PV                1
  Act PV                1
  VG Size               931.51 GB
  PE Size               4.00 MB
  Total PE              238467
  Alloc PE / Size       238336 / 931.00 GB
  Free  PE / Size       131 / 524.00 MB
  VG UUID               qSGaG1-SQYO-D2bm-ohDf-d4eG-oGCY-4jOegU
answer

ทำไมไม่ลองดูที่ส่วนสแนปชอตของ LVM-HOWTOล่ะ

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

สแน็ปช็อต LVM "ใช้งานจริง" ภายในกลุ่มวอลุ่มที่โฮสต์วอลลุมขึ้นอยู่กับสแนปชอต ไม่ใช่โวลุ่มอื่น คำสั่งของคุณ "...มีเนื้อที่ว่างที่ไม่ได้ถูกจัดสรรจำนวนมากและไม่ใช่พาร์ติชั่น" ทำให้ดูเหมือนว่าคุณกำลังคิดว่าสแน็ปช็อต "ใช้งานจริง" นอกกลุ่มวอลุ่มขึ้นอยู่กับสแนปชอต ซึ่งไม่ถูกต้อง กลุ่มวอลุ่มของคุณอาศัยอยู่ในพาร์ติชั่นฮาร์ดดิสก์ และโวลุ่มจะขึ้นอยู่กับสแนปชอตและช็อตช็อตใดๆ ที่คุณถ่ายสดในกลุ่มวอลุ่มนั้น

วิธีปกติที่ใช้สแน็ปช็อต LVM ไม่ใช่สำหรับการจัดเก็บระยะยาว แต่เพื่อให้ได้ "รูปภาพ" ที่สม่ำเสมอของระบบไฟล์เพื่อให้สามารถสำรองข้อมูลได้ เมื่อสำรองข้อมูลเสร็จแล้ว สแน็ปช็อตจะถูกยกเลิก

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

แก้ไข:

บริการ Microsoft Volume Shadow Copy และสแน็ปช็อต LVM ทำอะไรไม่ได้แตกต่างกันมากนัก โซลูชันของ Microsoft นั้นมีความครอบคลุมมากกว่าเล็กน้อย (ตามปกติในกรณีของ Microsoft -- ให้ดีขึ้นหรือแย่ลง เครื่องมือและผลิตภัณฑ์ของพวกเขามักจะพยายามแก้ปัญหาที่ค่อนข้างใหญ่เมื่อเทียบกับการมุ่งเน้นที่สิ่งใดสิ่งหนึ่ง)

VSS เป็นโซลูชันที่ครอบคลุมมากขึ้นซึ่งรวมการสนับสนุนสำหรับอุปกรณ์ฮาร์ดแวร์ที่สนับสนุนสแน็ปช็อตและสแน็ปช็อตที่ใช้ซอฟต์แวร์เป็น API เดียว นอกจากนี้ VSS ยังมี API ที่อนุญาตให้แอปพลิเคชันหยุดทำงานผ่าน API สแน็ปช็อต ในขณะที่สแน็ปช็อต LVM เกี่ยวข้องกับสแน็ปช็อตเท่านั้น ปัญหาของคุณคือแอปพลิเคชันที่หยุดนิ่ง (การทำให้ฐานข้อมูลอยู่ในสถานะ "สำรองข้อมูล" เป็นต้น)

สแน็ปช็อต LVM เป็นตัวอย่างของโซลูชันสแน็ปช็อตการคัดลอกเมื่อเขียนตามที่ Evan กล่าว วิธีการทำงานแตกต่างจากที่อีวานพูดเป็นนัยเล็กน้อย แต่ก็ไม่มากนัก

เมื่อคุณมีโวลุ่ม LVM ที่ไม่มีสแน็ปช็อต การเขียนไปยังโวลุ่มนั้นจะเกิดขึ้นตามที่คุณคาดหวัง บล็อกมีการเปลี่ยนแปลงและนั่นคือมัน

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

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

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

เมื่อคุณกำจัดสแน็ปช็อต LVM จะลดพูลสแน็ปช็อตและอัพเดตแผนผังสแน็ปช็อตตามต้องการ หากสแนปชอตที่หลุดเป็นส่วนหนึ่งของแผนผังสแนปชอต บางบล็อคจะถูกคัดลอกไปยังสแนปชอตระดับล่าง หากเป็นสแน็ปช็อตต่ำสุด (หรือเพียงอันเดียว) พูลก็จะหลุดและการดำเนินการก็เร็วมาก


ระบบไฟล์บางระบบมีสแน็ปช็อตในระบบไฟล์ ZFS และ BTRFS เป็นเพียงสองระบบที่รู้จักกันดี พวกมันทำงานเหมือนกัน แม้ว่าระบบไฟล์จะจัดการการแมปที่เปลี่ยนแปลง/ไม่เปลี่ยนแปลง นี่เป็นวิธีที่ดีกว่าในการดำเนินการ เนื่องจากคุณสามารถ fsck ตระกูลสแน็ปช็อตทั้งหมดเพื่อความสอดคล้อง ซึ่งเป็นสิ่งที่คุณไม่สามารถทำได้ด้วย LVM ตรงๆ

สแน็ปช็อต LVM นั้นไม่มีประสิทธิภาพ ยิ่งมีสแน็ปช็อตมากเท่าไหร่ ระบบก็จะยิ่งทำงานช้าลงเท่านั้น

ฉันสนับสนุน xfs เท่านั้นตามที่เราใช้ และ xfs_freeze สามารถใช้เพื่อหยุดการเข้าถึงระบบไฟล์ใหม่และสร้างอิมเมจที่เสถียรบนดิสก์

ใช้ Copy on Writeเพื่อให้ใช้พื้นที่ดิสก์ได้อย่างมีประสิทธิภาพ

คุณได้สร้างระบบไฟล์ในโลจิคัลวอลุ่มที่มีพื้นที่ว่างสำหรับสแน็ปช็อต

นี่คือตัวอย่างจาก FAQ

คุณไม่ได้ระบุว่าคุณกำลังใช้ Linux หรือ HP-UX ใน HP-UX คุณสร้างโลจิคัลวอลุ่มและติดตั้งเป็นสแน็ปช็อตของโลจิคัลวอลุ่มอื่น ใน Linux คุณสร้างโลจิคัลวอลุ่มเป็นวอลุ่มสแน็ปช็อต

การลบสแน็ปช็อตใน HP-UX ทำได้โดยเพิ่มวอลลุ่ม ใน Linux ทำได้โดยใช้ lvremove เพื่อลบโลจิคัลวอลุ่ม

ไม่ว่าในกรณีใด การเปลี่ยนแปลงจะเป็นสิ่งเดียวที่เก็บไว้ในสแนปชอตของคุณ ยิ่งสแนปชอตยังคงใช้งานได้นานเท่าใด การเปลี่ยนแปลงในสต็อกก็จะมากขึ้นเท่านั้น และมีโอกาสที่สแนปชอตจะเต็มได้หากไม่ได้ปรับขนาดหรือเผยแพร่อย่างเหมาะสม

ความเร็วของการเข้าถึงดิสก์บนโวลุ่มสแน็ปช็อตช้ากว่าวอลลุ่มปกติ คุณต้องคำนึงถึงสิ่งนั้น

@Evan Anderson และ @ sysadmin1138 คำตอบในขณะที่ให้คำแนะนำและตรงประเด็นสำหรับเวลาของพวกเขา (2009) ตอนนี้ค่อนข้างล้าสมัยเนื่องจากการมีอยู่ของวิธีการสแนปชอต LVM ที่แตกต่างกันสองวิธี:

  • อันแรก (เรียกว่า LVM แบบคลาสสิก) เป็นอันที่อธิบายไว้ในคำตอบข้างต้น โดยพื้นฐานแล้วจะแยกส่วนดิสก์เฉพาะสำหรับคัดลอกข้อมูลที่จะเขียนทับ ซึ่งหมายความว่าสแน็ปช็อตหลายอันทำลายประสิทธิภาพการทำงาน (เช่น: หากสแน็ปช็อตเดียวทำให้ระบบช้าลง 3-5 เท่า สแน็ปช็อตสองอันจะช้าลง 6-10 เท่า สาม สแนปชอต 12-15x เป็นต้น) ในทางกลับกัน ทำให้พวกเขาไม่สามารถสนับสนุนนโยบายภาพรวมได้ นอกจากนี้ พื้นที่จัดเก็บข้อมูลเมตา (ข้อความธรรมดา) ไม่ได้รับการปรับให้เหมาะสมกับความเร็ว อันที่จริง การใช้งานหลักของพวกเขาคือการสำรองข้อมูล: สแน็ปช็อตเดียวถูกถ่ายและหลังจากการสำรองข้อมูลจะถูกลบ

  • อันใหม่ (เรียกว่า Thin LVM หรือlvmthin ) เป็นสัตว์ร้ายที่แตกต่างไปจากเดิมอย่างสิ้นเชิง มันขึ้นอยู่กับเมตาดาต้าที่ปรับให้เหมาะสมแบบไบนารี (btree) เป็นอย่างมากเพื่อติดตามกลุ่มพื้นที่อย่างรวดเร็วและมีประสิทธิภาพ การทำสแน็ปช็อตไม่ใช้พื้นที่ดิสก์ใดๆ (เช่น: ไม่ควรประกาศขนาดสแน็ปช็อตและไม่ได้แยกออกจากกัน) ยกเว้นพื้นที่ข้อมูลเมตาที่ใช้มากกว่าบางส่วน การเขียนทับกลุ่มข้อมูลที่จัดสรรแล้วอาจส่งผลให้เกิดการอ่าน-แก้ไข-เขียนอีกครั้ง แต่สิ่งนี้สามารถหลีกเลี่ยงได้ทั้งหมดสำหรับการเขียนขนาดใหญ่ (โดยที่ "ใหญ่" หมายถึงใหญ่กว่ากลุ่มข้อมูล Thin Pool) ที่สำคัญกว่านั้น สแนปชอตหลายอันไม่ได้คัดลอกข้อมูลมากกว่าสแน็ปช็อตเดียว เนื่องจากมีการเปลี่ยนแปลงเฉพาะข้อมูลเมตาเพื่อชี้สแน็ปช็อตต่างๆ ไปยังกลุ่มข้อมูลเดียวกัน ในด้านมืด ควรสังเกตว่าสแน็ปช็อตแบบบางสามารถ "เติม" โวลุ่มทั้งหมดได้ ทำให้การเขียนทั้งหมดหยุดชะงัก

คุณควรใช้โวลุ่ม LVM ใด สำหรับระบบไฟล์รูท โดยทั่วไปแล้วฉันใช้โวลุ่ม LVM แบบคลาสสิก ซึ่งมีความแน่นหนาและกู้คืนได้ง่ายกว่า นอกจากนี้ พาร์ติชั่นรูทมักจะไม่มีข้อมูลที่มีค่ามากนัก (และขั้นตอนการสำรองข้อมูลปกติก็เพียงพอแล้ว) ในทางกลับกัน สำหรับปริมาณข้อมูล โดยทั่วไปแล้วฉันต้องการภาพรวมที่ขยายเวลาบางวัน/สัปดาห์ในอดีต ดังนั้นฉันจึงใช้ Thin LVM (หรือกลุ่ม ZFS แต่นี่เป็นอีกเรื่องหนึ่ง...) สำหรับบริบทเพิ่มเติม คุณสามารถอ่านได้ที่นี่