Question 1

วันก่อนฉันมีช่วงผายลมที่เหมาะสมในขณะที่ขยายดิสก์บน Linux guest ภายใต้ Vmware ฉันขยายไฟล์ดิสก์ Vmware เป็นขนาดที่ต้องการแล้วฉันก็ทำในสิ่งที่ฉันมักจะทำกับแขก Linux ที่ไม่มี LVM: ฉันลบพาร์ติชัน LVM และสร้างใหม่โดยเริ่มจากจุดเดิม แต่ขยายเป็นขนาดใหม่ ดิสก์ (ซึ่งจะตามด้วย fsck และ resize2fs)

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

Virtual Linux guest ที่มีดิสก์เดียว แบ่งพาร์ติชั่นเป็นหนึ่งพาร์ติชั่น /boot (หลัก) (/dev/sda1) 256MB และที่เหลือในพาร์ติชั่นเสริมเชิงตรรกะ (/dev/sda5)

จากนั้น /dev/sda5 จะถูกตั้งค่าเป็นฟิสิคัลวอลุ่มที่มี pvcreate และหนึ่งกลุ่มวอลุ่ม (vgroup00) ที่สร้างไว้ด้านบนด้วยคำสั่ง vgcreate ปกติ จากนั้น vgroup00 จะถูกแบ่งออกเป็นสองโลจิคัลวอลุ่ม root และ swap ซึ่งใช้สำหรับ / และ swap อย่างมีเหตุผล / เป็นระบบไฟล์ ext4

เนื่องจากฉันมีข้อมูลสำรองของแขกที่เสียหาย ฉันจึงสามารถสร้างกลุ่มวอลุ่มขึ้นใหม่ด้วย vgcfgrestore จากการตั้งค่า LVM สำรองที่อยู่ภายใต้ /etc/lvm/backup โดยมี UUID เดียวกันสำหรับฟิสิคัลวอลุ่มและทั้งหมดนั้น หลังจากรันสิ่งนี้ ฉันมีโลจิคัลวอลุ่มสองอันที่มีขนาดเท่ากันกับก่อนหน้านี้ โดยมีพื้นที่ว่าง 4GB ที่ฉันขยายดิสก์

อย่างไรก็ตาม เมื่อฉันพยายามเรียกใช้ "fsck /dev/mapper/vgroup00-root" มันบ่นเกี่ยวกับ superblock ที่เสีย ฉันพยายามค้นหา superblock สำรองโดยเรียกใช้ "mke2fs -n /dev/mapper/vgroup00-root" แต่ไม่มีสิ่งใดที่ใช้งานได้ จากนั้นฉันพยายามเรียกใช้TestDiskแต่เมื่อฉันขอให้มันค้นหา superblocks มันทำให้เกิดข้อผิดพลาดเกี่ยวกับการไม่สามารถเปิดระบบไฟล์ได้เนื่องจากระบบไฟล์เสีย

ดังนั้น ด้วยนโยบายการจัดสรรเริ่มต้นสำหรับ LVM2 ใน Ubuntu Server 10.04 64 บิต เป็นไปได้ไหมที่โลจิคัลวอลุ่มจะได้รับการจัดสรรจากส่วนท้ายของกลุ่มวอลุ่ม นั่นจะอธิบายได้อย่างแน่นอนว่าทำไมโลจิคัลวอลุ่มที่กู้คืนจึงไม่มีข้อมูลที่คาดหวัง ฉันสามารถกู้คืนได้โดยการสร้าง /dev/sda5 ใหม่ด้วยขนาดและตำแหน่งของดิสก์ที่เท่ากันทุกประการเหมือนก่อนหน้านี้หรือไม่? มีเครื่องมืออื่นใดที่ฉันสามารถใช้เพื่อค้นหาและกู้คืนระบบไฟล์ได้หรือไม่ (และที่แน่ๆ คำถามไม่ใช่ว่าผมควรจะทำแบบที่ต่างไปจากเดิมหรือเปล่า ผมรู้ดี นี่เป็นคำถามที่ว่าจะทำอย่างไรเมื่ออึเข้าเรื่องแฟนแล้ว)

Question 2

ทุกครั้งที่คุณดำเนินการกับ LVM ตามค่าเริ่มต้น ข้อมูลเมตาก่อนหน้านี้จะถูกเก็บถาวรในรูปแบบ/etc/lvm/archive. คุณสามารถใช้vgcfgrestoreเพื่อกู้คืนหรือคว้าส่วนขยายด้วยมือ (ยากกว่า แต่lvcreate(8)ควรปิดไว้)

แก้ไข:

และเพื่อให้ง่ายที่สุด ฉันควรเพิ่มว่าคุณสามารถค้นหาข้อมูลสำรองล่าสุดก่อนดำเนินการทำลายโดยดูที่คำอธิบาย:

# grep description /etc/lvm/archive/vg01_*
/etc/lvm/archive/vg01_00001.vg:description = "Created before executing 'lvremove -f /dev/vg01/foo'"
/etc/lvm/archive/vg01_00002.vg:description = "Created before executing 'lvremove -f /dev/vg01/bar'"
/etc/lvm/archive/vg01_00003.vg:description = "Created before executing 'lvremove -f /dev/vg01/baz'"

แก้ไข:

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

Question 3

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

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

คำตอบข้างต้นยังมีหัวข้อเกี่ยวกับการปรับขนาดวอลุ่ม LVM ด้วย การขยายวอลลุมนั้นปลอดภัยพอสมควร และมักจะดีกว่าที่จะใช้lvresizeแทนการลบและสร้างใหม่

ในประเด็นที่เกี่ยวข้อง: เนื่องจากคุณใช้ VMware คุณควรดูแลให้ฮาร์ดดิสก์เขียนแคชฟลัช (อุปสรรคในการเขียน) เผยแพร่อย่างถูกต้องจากเคอร์เนล Linux ของแขกผ่านไฮเปอร์ไวเซอร์และระบบปฏิบัติการโฮสต์ใดๆ สิ่งสำคัญคือต้องมีการตั้งค่าอุปสรรคในการเขียนใน guest FS และ guest kernel ซึ่งควรเป็น 2.6.33 หรือสูงกว่า

answer