Score:14

ไม่สามารถเมานต์ระบบไฟล์ XFS จากอาร์เรย์ Linux RAID6 ("บันทึกไม่สอดคล้องกัน")

ธง fr
Bob

โพสต์ครั้งแรก - ขออภัยหากไม่รักษามารยาทให้ถูกต้อง

ฉันมีอาร์เรย์ RAID6 ~ 200TB พร้อมดิสก์ 30 แผ่นและไม่สามารถเมานต์ได้ - ฉันเพิ่งได้รับข้อความ:

เมานต์ /dev/md125 /export/models
เมานต์: / dev / md125: ไม่สามารถอ่าน superblock

ถ้าฉันวิ่ง mdadm --รายละเอียด บนมันแสดงว่าสะอาด:

/dev/md125:
           เวอร์ชัน : 1.2
     Creation Time : พุธ 13 ก.ย. 15:09:40 2017
        ระดับการจู่โจม : การจู่โจม 6
        ขนาดอาร์เรย์ : 218789036032 (203.76 TiB 224.04 TB)
     ขนาด Dev ที่ใช้ : 7813894144 (7.28 TiB 8.00 TB)
      อุปกรณ์จู่โจม : 30
     รวมอุปกรณ์ : 30
       การคงอยู่: Superblock นั้นคงอยู่

     บิตแมปเจตนา: ภายใน

       อัปเดตเวลา : วันศุกร์ที่ 20 พฤษภาคม 23:54:52 น. 2022
             รัฐ : สะอาด
    อุปกรณ์ที่ใช้งานอยู่ : 30
   อุปกรณ์การทำงาน : 30
    อุปกรณ์ที่ล้มเหลว : 0
     อุปกรณ์สำรอง : 0

            รูปแบบ : สมมาตรซ้าย
        ขนาดก้อน : 512K

นโยบายความสอดคล้อง: บิตแมป

              ชื่อ : localhost.localdomain:SW-RAID6
              UUID : f9b65f55:5f257เพิ่ม:1140ccc0:46ca6c19
            เหตุการณ์ : 1152436

    หมายเลขหลักรอง RaidDevice สถานะ
       0 8 1 0 การซิงค์ที่ใช้งานอยู่ /dev/sda1
       1 65 161 1 แอคทีฟซิงค์ /dev/sdaa1
       2 65 177 2 แอคทีฟซิงค์ /dev/sdab1
       3 65 193 3 แอคทีฟซิงค์ /dev/sdac1
       4 65 209 4 แอคทีฟซิงค์ /dev/sdad1
       5 8 17 5 การซิงค์ที่ใช้งานอยู่ /dev/sdb1
       6 8 33 6 การซิงค์ที่ใช้งานอยู่ /dev/sdc1
       7 8 49 7 การซิงค์ที่ใช้งานอยู่ /dev/sdd1
       8 8 65 8 การซิงค์ที่ใช้งานอยู่ /dev/sde1
       9 8 81 9 การซิงค์ที่ใช้งานอยู่ /dev/sdf1
      10 8 97 10 การซิงค์ที่ใช้งานอยู่ /dev/sdg1
      11 8 113 11 การซิงค์ที่ใช้งานอยู่ /dev/sdh1
      12 8 129 12 การซิงค์ที่ใช้งานอยู่ /dev/sdi1
      13 8 145 13 การซิงค์ที่ใช้งานอยู่ /dev/sdj1
      14 8 161 14 การซิงค์ที่ใช้งานอยู่ /dev/sdk1
      15 8 177 15 การซิงค์ที่ใช้งานอยู่ /dev/sdl1
      16 8 193 16 การซิงค์ที่ใช้งานอยู่ /dev/sdm1
      17 8 209 17 การซิงค์ที่ใช้งานอยู่ /dev/sdn1
      18 8 225 18 การซิงค์ที่ใช้งานอยู่ /dev/sdo1
      19 8 241 19 การซิงค์ที่ใช้งานอยู่ /dev/sdp1
      20 65 1 20 การซิงค์ที่ใช้งานอยู่ /dev/sdq1
      21 65 17 21 แอคทีฟซิงค์ /dev/sdr1.dll
      22 65 33 22 การซิงค์ที่ใช้งานอยู่ /dev/sds1
      23 65 49 23 การซิงค์ที่ใช้งานอยู่ /dev/sdt1
      24 65 65 24 การซิงค์ที่ใช้งานอยู่ /dev/sdu1
      25 65 81 25 การซิงค์ที่ใช้งานอยู่ /dev/sdv1
      26 65 97 26 การซิงค์ที่ใช้งานอยู่ /dev/sdw1
      27 65 113 27 การซิงค์ที่ใช้งานอยู่ /dev/sdx1
      28 65 129 28 แอคทีฟซิงค์ /dev/sdy1.dll
      29 65 145 29 แอคทีฟซิงค์ /dev/sdz1

แมว /proc/stat แสดง:

[root@knox ~]# cat /proc/mdstat
บุคลิก : [raid1] [raid6] [raid5] [raid4]
md125 : ใช้งาน Raid6 sdo1[18] sdh1[11] sdad1[4] sdd1[7] sdb1[5] sdi1[12] sdt1[23] sdr1[21] sdp1[19] sdx1[27] sdg1[10] sdn1[ 17] sdm1[16] sdab1[2] sdu1[24] sdl1[15] sde1[8] sdf1[9] sdw1[26] sdc1[6] sdq1[20] sdy1[28] sds1[22] sdv1[25] sdac1[3] sdz1[29] sdaa1[1] sda1[0] sdj1[13] sdk1[14]
      218789036032 บล็อก super 1.2 ระดับ 6, 512k อัน, อัลกอริทึม 2 [30/30] [UUUUUUUUUUUUUUUUUUUUUUUUUUUUUU]
      บิตแมป: 0/59 หน้า [0KB], ก้อน 65536KB

md126 : ใช้งานการจู่โจม 1 sdae3[0] sdaf2[1]
      976832 บล็อกซุปเปอร์ 1.0 [2/2] [UU]
      บิตแมป: 0/1 หน้า [0KB], ก้อน 65536KB

md127 : ใช้งานการจู่โจม 1 sdaf1[1] sdae1[0]
      100554752 บล็อกซุปเปอร์ 1.2 [2/2] [UU]
      บิตแมป: 1/1 หน้า [4KB], ก้อน 65536KB

อุปกรณ์ที่ไม่ได้ใช้: <ไม่มี>

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

/dev/sda1:
          เมจิก : a92b4efc
        เวอร์ชัน : 1.2
    แผนที่คุณลักษณะ : 0x1
     อาร์เรย์ UUID : f9b65f55:5f257add:1140ccc0:46ca6c19
           ชื่อ : localhost.localdomain:SW-RAID6
  Creation Time : พุธ 13 ก.ย. 15:09:40 2017
     ระดับการจู่โจม : การจู่โจม 6
   อุปกรณ์จู่โจม : 30

 Avail Dev Size : 15627788288 ภาค (7.28 TiB 8.00 TB)
     ขนาดอาร์เรย์ : 218789036032 KiB (203.76 TiB 224.04 TB)
    Data Offset : 262144 ภาค
   ซูเปอร์ออฟเซ็ต : 8 ภาค
   พื้นที่ที่ไม่ได้ใช้ : ก่อน=262056 ภาค, หลัง=0 ภาค
          รัฐ : สะอาด
    UUID ของอุปกรณ์ : 917e739e:36fa7cf6:c618d73c:43fb7dec

บิตแมปภายใน: 8 ภาคจาก superblock
    อัปเดตเวลา : วันศุกร์ที่ 20 พฤษภาคม 23:54:52 น. 2022
  Bad Block Log : 512 รายการที่ offset 72 ภาค
       เช็คซัม : 2b5e9556 - ถูกต้อง
         เหตุการณ์ : 1152436

         รูปแบบ : สมมาตรซ้าย
     ขนาดก้อน : 512K

   บทบาทของอุปกรณ์ : อุปกรณ์ที่ใช้งานอยู่ 0
   Array State : AAAAAAAAAAAAAAAAAAAAAAAAAAAAA ('A' == ใช้งาน, '.' == หายไป, 'R' == แทนที่)

รายการที่เกี่ยวข้องใน dmesg แสดง:

[13297.001208] XFS (md125): การติดตั้งระบบไฟล์ V5
[13297.008854] XFS (md125): บันทึกไม่สอดคล้องกัน (ไม่พบส่วนหัวก่อนหน้า)
[13297.008874] XFS (md125): ไม่พบส่วนหัวของบันทึก
[13297.008878] XFS (md125): การเมานต์บันทึก/การกู้คืนล้มเหลว: ข้อผิดพลาด -5
[13297.008934] XFS (md125): การเมานต์บันทึกล้มเหลว

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

น่าเสียดายที่มันไม่ได้สำรองข้อมูลไว้ (ฉันหมายถึงว่าคุณสำรองข้อมูล 200TB ไว้ที่ไหน!?!) ไม่ควรเก็บสิ่งของมีค่าไว้ที่นี่ แต่มนุษย์ สิ่งของมีค่าบางอย่างถูกเก็บไว้ที่นั่น

ฉันได้ดูที่ xfs_repair แต่ฉันไม่แน่ใจว่าฉันควรรันบนอาร์เรย์ RAID (md125) หรือบนอุปกรณ์ sd* แต่ละเครื่อง

ขอบคุณ

อัปเดต (ประวัติเบื้องหลังทั้งหมด):

อุปกรณ์นี้เป็นเซิร์ฟเวอร์ SuperMicro ที่ใช้ CentOS 7 (3.10.0-1160.11.1.e17.x86_64) เวอร์ชัน 4.1 â 2018-10-01 ของ mdadm พร้อมดิสก์ 30 x 8TB ในการกำหนดค่า RAID6 นอกจากนี้ยังมีการบู๊ตและรูทบนอาร์เรย์ RAID1 2 ตัว – อาร์เรย์ RAID6 สำหรับข้อมูลเท่านั้น พื้นที่ว่างเต็มแล้ว ดังนั้นเราจึงตัดสินใจเพิ่มไดรฟ์ในอาร์เรย์ (สามารถเก็บไดรฟ์ได้ทั้งหมด 45 ไดรฟ์)

เนื่องจากดิสก์ดั้งเดิมในอาร์เรย์เป็นไดรฟ์ 4kN และอุปกรณ์ที่ให้มาคือ 512e จึงจำเป็นต้องฟอร์แมตใหม่ด้วย sg_format เพื่อแปลง (ขั้นตอนที่ Western Digital รองรับ) ฉันเริ่มด้วยดิสก์หนึ่งแผ่นเป็นการทดสอบ น่าเสียดายที่กระบวนการถูกขัดจังหวะระหว่างทาง ดังนั้นฉันจึงเริ่มต้นใหม่และดำเนินการตามตกลงจนเสร็จสิ้น เหมือนกับว่าได้แปลงดิสก์เป็น 4096k แล้ว แต่เกิดข้อผิดพลาด I/O หนึ่งหรือสองข้อผิดพลาด แต่ดูเหมือนไม่เกี่ยวข้องกันมากนักและฉัน หากมีปัญหาก็จะแสดงในสองสามขั้นตอนถัดไป ฉันได้ค้นพบบันทึก dmesg ตั้งแต่นั้นมา และนั่นบ่งชี้ว่ามีข้อผิดพลาด I/O มากกว่าที่ฉันคิดไว้อย่างมาก

อย่างไรก็ตาม เนื่องจาก sg_format ดูเหมือนจะเสร็จสมบูรณ์ ฉันจึงย้ายไปยังขั้นตอนต่อไปซึ่งก็คือการแบ่งพาร์ติชันดิสก์ด้วยคำสั่งต่อไปนี้

     parted -a เหมาะสมที่สุด /dev/sd<x>
     (แยกส่วน) mklabel msdos
     (แยกส่วน) mkpart หลัก 2048s 100% (ต้องตรวจสอบว่าการเริ่มต้นถูกต้อง)
     (แยกส่วน) จัดตำแหน่งตรวจสอบที่ดีที่สุด 1 (ตรวจสอบการจัดตำแหน่งของพาร์ติชัน 1)
     (แยกส่วน) ตั้ง 1 การโจมตี (ตั้งค่า FLAG เป็น RAID)
     (แยก) พิมพ์

ฉันเพิ่มดิสก์ใหม่ลงในอาร์เรย์แล้ว:

     mdadm --add /dev/md125 /dev/sd<x>

และมันก็เสร็จสิ้นโดยไม่มีปัญหาใด ๆ

จากนั้นฉันก็ขยายอาร์เรย์ต่อไป:

     mdadm --grow --raid-devices=31 --backup-file=/grow_md125.bak /dev/md125

ฉันตรวจสอบสิ่งนี้ด้วย cat /proc/mdstat และพบว่ากำลังปรับรูปร่างใหม่ แต่ความเร็วเป็น 0K/วินาที และการปรับรูปร่างไม่คืบหน้าจาก 0%

ประมาณ 12 ชั่วโมงต่อมา เนื่องจากการปรับรูปร่างไม่คืบหน้าจาก 0% ฉันจึงมองหาวิธีการยกเลิก เช่น mdadm --stop /dev/md125 ซึ่งใช้ไม่ได้ ดังนั้นฉันจึงลงเอยด้วยการรีบูตเซิร์ฟเวอร์

เซิร์ฟเวอร์ขึ้นมาในโหมดฉุกเฉิน

ฉันสามารถเข้าสู่ระบบในฐานะรูทได้ แต่อาร์เรย์ RAID6 ws ติดอยู่ในสถานะสร้างใหม่

ฉันพยายามแล้ว mdadm --assemble --update=revert-reshape --backup-file=/grow_md125.bak --verbose --uuid= f9b65f55:5f257add:1140ccc0:46ca6c19 /dev/md125 และสิ่งนี้ผลิต:

     mdadm: ไม่พบ super block บน /dev/sde (คาดว่าเวทย์มนตร์ a92b4efc ได้รับ <จำนวนที่ต่างกัน>
     mdadm: ไม่มี RAID super block บน /dev/sde
     .
     .
     mdadm: /dev/sde1 ถูกระบุว่าเป็นสมาชิกของ /dev/md125 ช่อง 6
     .
     .
     mdadm: /dev/md125 มีการปรับรูปร่างที่ใช้งานอยู่ - ตรวจสอบว่าจำเป็นต้องกู้คืนส่วนที่สำคัญหรือไม่
     mdadm: ไม่มีข้อมูลเมตาสำรองบน ​​/grow_md125.back
     mdadm: ไม่พบข้อมูลสำรองของส่วนที่สำคัญ
     mdadm: ไม่สามารถกู้คืนส่วนที่สำคัญสำหรับการปรับรูปร่าง ขออภัย

ฉันลองใช้รูปแบบที่แตกต่างกันซึ่งรวมถึง mdadm --assemble --invalid-สำรอง --force ทั้งหมดไม่มีประโยชน์

ณ จุดนี้ ฉันได้ลบดิสก์ที่ต้องสงสัยออกไปด้วย แต่สิ่งนี้ไม่ได้สร้างความแตกต่างใดๆ

แต่สิ่งที่ใกล้เคียงที่สุดที่ฉันได้แก้ไขสิ่งนี้กำลังทำงานอยู่ mdadm /dev/md125 --assemble --invalid-backup --backup-file=/grow_md125.bak --verbose /dev/sdc1 /dev/sdd1 ....... /dev/sdaf1 และสิ่งนี้ก่อให้เกิด:

     mdadm: /dev/sdaf1 ถูกระบุว่าเป็นสมาชิกของ /dev/md125 สล็อต 4
     mdadm: /dev/md125 มีการปรับรูปร่างที่ใช้งานอยู่ - ตรวจสอบว่าจำเป็นต้องกู้คืนส่วนที่สำคัญหรือไม่
     mdadm: ไม่มีข้อมูลเมตาสำรองบน ​​/grow_md125.back
     mdadm: ไม่พบข้อมูลสำรองของส่วนที่สำคัญ
     mdadm: ดำเนินการต่อโดยไม่กู้คืนข้อมูลสำรอง
     mdadm: เพิ่ม /dev/sdac1 ถึง /dev/md125 เป็น 1
     .
     .
     .
     mdadm: ล้มเหลวในการ RUN_ARRAY /dev/md125: อาร์กิวเมนต์ไม่ถูกต้อง

dmesg มีข้อมูลนี้:

     md: md125 หยุดทำงาน
     md/raid:md125: reshape_position เร็วเกินไปสำหรับการกู้คืนอัตโนมัติ - ยกเลิก
     md: pers->run() ล้มเหลว ...
     md: md125 หยุดทำงาน

จากทั้งหมดข้างต้น ฉันบูทจากซีดีกู้ข้อมูลและสามารถเปลี่ยนรูปร่างกลับเป็นอุปกรณ์เดิม 30 เครื่องและบูตกลับเข้าสู่การติดตั้งแบบเนทีฟ (ฉันต้องสังเกตอาร์เรย์นั้นจาก fstab เพื่อทำเช่นนั้น)

Nikita Kipriyanov avatar
za flag
การซ่อมแซมควรทำใน RAID นอกจากนี้ หากเป็น *พาร์ติชันได้* (ตรวจสอบกับ `fdisk -l /dev/mdXXX` ว่ามีพาร์ติชันหรือไม่) คุณควรทำงานกับพาร์ติชัน นอกจากนี้ **หลีกเลี่ยงอาร์เรย์ขนาดใหญ่เช่นนี้** ดีกว่าคือการมี "RAID60" ในรูปแบบ 3 ใน 10 (อาร์เรย์ RAID6 3 ชุดจากอุปกรณ์ 10 เครื่องแต่ละชุดที่แยกจากกัน) ใช่ คุณจะสูญเสียพื้นที่บางส่วน แต่การดำเนินการจัดการจะไม่คงอยู่เป็นเวลาหลายสัปดาห์ // นอกจากนี้ยังเกี่ยวกับประวัติที่คุณเข้าสู่สถานะนี้ การขัดจังหวะส่วนขยาย และการก่อร่างใหม่ อาจเป็นได้ง่ายๆ ว่าตอนนี้ข้อมูลไม่สามารถกู้คืนได้ เสียใจ.
fr flag
Bob
ขอบคุณ @NikitaKipriyanov .. เบื้องหลังทั้งหมดนี้ยาวมาก มีวิธีการโพสต์ข้อความขนาดใหญ่หรือไม่?
Nikita Kipriyanov avatar
za flag
ขีดจำกัดการโพสต์ของ ServerFault คือ 30k อักขระ หากข้อมูลของคุณมีมากกว่านั้น อาจไม่ใช่สำหรับ ServerFault เพราะไม่น่าเป็นไปได้ที่คำถามดังกล่าวจะคุ้มค่าสำหรับคนอื่น นอกจากนี้ เกี่ยวกับ RAID เป็นหัวข้อที่ค่อนข้างลึกและเป็นที่นิยม และมีคำถามมากมายเช่นนี้ใน Serverfault บางคำถามได้รับคำตอบ แต่มันยากมากที่จะตอบให้เหนือกว่าคำตอบทั่วไป: สร้างสแนปชอตและลองใช้หลายๆ วิธี หรือค้นหา มืออาชีพที่ได้รับค่าตอบแทนที่จะแก้ไขกรณีเฉพาะของคุณ
fr flag
Bob
ขอบคุณ @NikitaKipriyanov ฉันเพิ่งแก้ไขโพสต์ต้นฉบับของฉันเพื่อรวมพื้นหลัง
djdomi avatar
za flag
ฉันเห็นด้วยกับนิกิเทีย หยุดการเปลี่ยนแปลงใด ๆ จับมืออาชีพ
U. Windl avatar
it flag
ใน "ดังนั้นฉันจึงลงเอยด้วยการรีบูตเซิร์ฟเวอร์": ควรตรวจสอบ syslog หรือ dmesg *ก่อน* รีบูต ฉันเดาว่ามีข้อผิดพลาด I/O จำนวนมาก บางทีการพยายามลบดิสก์อีกครั้งโดยใช้ `mdadm` น่าจะฉลาดกว่า หรือพยายาม "ฮาร์ดล้มเหลว" ไดรฟ์เสียผ่านคำสั่งซอฟต์แวร์ (เช่นใน https://stackoverflow.com/a/1365156/6607497)
Score:13
ธง za

ฉันต้องการขยายคำแนะนำด้านบน

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

ฉันทำอย่างนั้นกับคิวมู qemu-nbd,ลินุกซ์ nbd.ko (โปรแกรมควบคุม Network Block Device) และไฟล์ซ้อนทับ qcow2

  1. เชื่อมต่อดิสก์เพิ่มเติมที่จะจัดเก็บโอเวอร์เลย์ โหลดไดรเวอร์ NBD ติดตั้งดิสก์เริ่มต้นของคุณที่ใดที่หนึ่ง:
modprobe nbd
เมานต์ /dev/sdXXN /tmp/โอเวอร์เลย์
  1. สร้างไฟล์ซ้อนทับ qcow2:
qemu-img สร้าง -f qcow2 -b /dev/md125 -F ดิบ /tmp/overlay/attempt1.qcow2
  1. สร้างอุปกรณ์บล็อกจากไฟล์ซ้อนทับโดยใช้ qemu-nbd:
qemu-nbd -c /dev/nbd0 /tmp/overlay/attempt1.qcow2

ตอนนี้คุณมี /dev/nbd0 ซึ่งเป็น "โคลนที่เขียนได้" ของอาร์เรย์ของคุณ คุณสามารถเขียนไปยังอุปกรณ์นี้ได้อย่างปลอดภัย การเปลี่ยนแปลงใดๆ จะถูกเขียนถึง /tmp/overlay/attempt1.qcow2. ตัวอย่างเช่น เมื่อคุณลองใช้คำแนะนำของ @shodanshok ให้นำไปใช้กับ /dev/nbd0.

  1. หากคุณติดขัด ให้ถอดโอเวอร์เลย์ออกและนำไฟล์โอเวอร์เลย์ออก
qemu-nbd -d /dev/nbd0
rm /tmp/โอเวอร์เลย์/attempt1.qcow2

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

เมื่อทำงานกับโคลนของระบบไฟล์ XFS โปรดจำไว้ว่าแต่ละระบบควรมี UUID ที่แตกต่างกัน

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

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

และฉันขอย้ำอีกครั้งว่า RAID6 จาก 30 อุปกรณ์นั้นเป็นเรื่องที่น่าปวดหัว ดีกว่ามีเช่น อาร์เรย์ RAID6 3 อาร์เรย์ ไดรฟ์ละ 10 ตัว จากนั้นรวมเข้าด้วยกันโดยใช้ MD RAID 0 หรือ LVM แบบเลเยอร์ การดำเนินการนี้จะทำให้จัดการสิ่งต่างๆ ได้ง่ายขึ้น และการดำเนินการเปลี่ยนรูปร่าง/ตรวจสอบของคุณจะใช้เวลาไม่กี่สัปดาห์จึงจะเสร็จสมบูรณ์ ใช่ คุณตรวจสอบความสม่ำเสมอของ RAID (ขัดถู) เป็นประจำ อย่างน้อยเดือนเว้นเดือนใช่ไหม

อัปเดต: มีข้อมูลที่มีค่าในความคิดเห็นซึ่งควรค่าแก่การเพิ่มที่นี่

  • ฉันสงสัยว่าเนื้อหา qemu จะพร้อมใช้งานใน Synology DSM แต่คุณสามารถเชื่อมต่อดิสก์กับพีซีธรรมดาด้วย Linux และดำเนินการต่อได้ หรือลองบูต Synology จากเครือข่ายหรือ LiveUSB â NAS ที่สามารถเชื่อมต่อดิสก์ได้ 30 แผ่น โดยพื้นฐานแล้วเป็นคอมพิวเตอร์แบบติดตั้งบนแร็ค amd64 ทั่วไป â

  • @Mark แนะนำวิธีอื่นในการสร้างภาพซ้อนทับ:

@Bob มีตัวเลือกอื่นสำหรับการสร้างภาพซ้อนทับ â ฉันใช้ธัมบ์ไดรฟ์ USB และขั้นตอนที่ https://raid.wiki.kernel.org/index.php/Recovering_a_damaged_RAID

วิธีที่ดีซึ่งใช้กรอบงาน Device Mapper น่าจะมีอยู่ใน DSM! นอกจากนี้ยังอาจเร็วกว่าวิธีการของฉัน มันคือ dmตั้งค่า คำสั่งที่สร้างอุปกรณ์เสมือนด้วยไฟล์ซ้อนทับแบบกระจาย อย่างไรก็ตาม เนื่องจากอาร์เรย์ RAID นั้นดูสะอาดในกรณีของคุณ และทั้งหมดที่เราพูดถึงคือการแก้ไขระบบไฟล์ ฉันขอแนะนำให้สร้างการซ้อนทับของอาร์เรย์แบบประกอบ (/dev/md125) แทนที่จะเป็นองค์ประกอบอาร์เรย์แต่ละรายการ

fr flag
Bob
ขอบคุณ @Nikita การตรวจสอบด้วย `fdisk -l /dev/md125` ทำให้ฉัน: ``` ดิสก์ /dev/md125: 224040.0 GB, 224039972896768 ไบต์, 54697259008 ภาคส่วน หน่วย = ภาคของ 1 * 4096 = 4096 ไบต์ ขนาดเซกเตอร์ (โลจิคัล/กายภาพ): 4096 ไบต์ / 4096 ไบต์ ขนาด I/O (ต่ำสุด/เหมาะสม): 524288 ไบต์ / 14680064 ไบต์ ```
fr flag
Bob
`แยกส่วน` ส่งคืน: ``` [root@knox ~]# แยกทางกัน GNU แยกส่วน 3.1 ใช้ /dev/sda ยินดีต้อนรับสู่ GNU Parted! พิมพ์ 'help' เพื่อดูรายการคำสั่ง (แยกส่วน) เลือก /dev/md125 ใช้ /dev/md125 (แยก) พิมพ์ ข้อผิดพลาด: /dev/md125: ป้ายชื่อดิสก์ที่ไม่รู้จัก รุ่น: Linux Software RAID Array (md) ดิสก์ /dev/md125: 224TB ขนาดเซกเตอร์ (โลจิคัล/กายภาพ): 4096B/4096B ตารางพาร์ติชัน: ไม่ทราบ แฟล็กดิสก์: ```
fr flag
Bob
คำอธิบายของคุณเกี่ยวกับกระบวนการโอเวอร์เลย์ฟังดูค่อนข้างซับซ้อน และฉันเข้าใจได้ว่าทำไมคุณถึงบอกว่าองค์กรกู้ข้อมูลนั้นคุ้มค่ากับเงินที่เสียไป สำหรับคำถามของคุณเกี่ยวกับการขัดถู คำตอบคือใช่อย่างแน่นอนสำหรับ Synology NAS ที่มีขนาดเล็กกว่าของเรา แต่ด้วยสัตว์ร้ายตัวนี้ ฉันรู้สึกละอายที่จะยอมรับว่าฉันไม่แน่ใจ ฉันไม่แน่ใจว่าฉันพูดถึงหรือไม่ว่า Linux และ Linux RAID นั้นค่อนข้างใหม่สำหรับฉันโดยเฉพาะ ดังนั้นฉันจึงไม่ค่อยเข้าใจในเรื่องนี้
Nikita Kipriyanov avatar
za flag
ฉันสงสัยว่าเนื้อหา qemu จะพร้อมใช้งานใน Synology DSM แต่คุณสามารถเชื่อมต่อดิสก์กับพีซีธรรมดาด้วย Linux และดำเนินการต่อได้ หรือลองบูต Synology จากเครือข่ายหรือ LiveUSB â NAS ที่สามารถเชื่อมต่อดิสก์ได้ 30 แผ่น โดยพื้นฐานแล้วเป็นคอมพิวเตอร์แบบติดตั้งบนแร็ค amd64 ทั่วไป
Mark avatar
tz flag
@Bob มีตัวเลือกอื่นสำหรับการสร้างภาพซ้อนทับ - ฉันใช้ธัมบ์ไดรฟ์ USB และขั้นตอนที่ https://raid.wiki.kernel.org/index.php/Recovering_a_damaged_RAID
Nikita Kipriyanov avatar
za flag
วิธีที่ดีซึ่งใช้กรอบงาน Device Mapper น่าจะมีอยู่ใน DSM! นอกจากนี้ยังอาจเร็วกว่าวิธีการของฉัน เป็นคำสั่ง `dmsetup` ที่สร้างอุปกรณ์เสมือนพร้อมไฟล์ซ้อนทับแบบกระจายอย่างไรก็ตาม เนื่องจากอาร์เรย์ RAID นั้นดูสะอาดในกรณีของคุณ และทั้งหมดที่เราพูดถึงคือการแก้ไขระบบไฟล์ ฉันขอแนะนำให้สร้างการซ้อนทับของอาร์เรย์แบบประกอบ (`/dev/md125`) แทนที่จะเป็นส่วนประกอบอาร์เรย์แต่ละรายการ
Score:10
ธง ca

บันทึก

[13297.001208] XFS (md125): การติดตั้งระบบไฟล์ V5
[13297.008854] XFS (md125): บันทึกไม่สอดคล้องกัน (ไม่พบส่วนหัวก่อนหน้า)
[13297.008874] XFS (md125): ไม่พบส่วนหัวของบันทึก
[13297.008878] XFS (md125): การเมานต์บันทึก/การกู้คืนล้มเหลว: ข้อผิดพลาด -5
[13297.008934] XFS (md125): การเมานต์บันทึกล้มเหลว

ทำให้ฉันคิดว่าการปรับรูปร่างที่ถูกยกเลิก "สับเปลี่ยน" หมายเลข LBA เพื่อให้ XFS ไม่พบบันทึกความตั้งใจนี่คงหมายถึงการฉ้อราษฎร์บังหลวงเป็นวงกว้างอย่างที่ใครๆว่าไว้ หยุดที่นี่และติดต่อบริการกู้คืนข้อมูลมืออาชีพ

หากเป็นไปไม่ได้ ฉันจะลองครั้งสุดท้ายโดยละเว้นบันทึก XFS ด้วยสิ่งที่เป็น เมานต์ -o ro, norecovery /dev/md125 /export/models แต่ใน กรณีที่ไม่น่าจะเป็นไปได้มาก ควรเตรียมพร้อมสำหรับความเสียหายของข้อมูลอย่างกว้างขวาง

อีกครั้ง หากเก็บข้อมูลสำคัญไว้ ให้ติดต่อบริษัทกู้คืนข้อมูลก่อนดำเนินการใดๆ

fr flag
Bob
ขอบคุณ @shodanshok ฉันจะลองคุยกับหัวหน้าดู
Criggie avatar
in flag
@bob หากใช้งานได้คุณต้องบันทึกการกระทำของคุณและระมัดระวัง "ปิดตูดของคุณ" แม้ว่าจะต้องเสียเงิน หากการสูญหายของข้อมูลนี้ทำให้บริษัทต้องเสียค่าใช้จ่าย พวกเขาอาจโทษคุณเอง
U. Windl avatar
it flag
ใช่ ปัญหาที่เป็นอยู่ตอนนี้ดูเหมือนจะไม่เกี่ยวข้องกับ RAID ด้านล่างนี้ ปัญหาคือ "บันทึกไม่สอดคล้องกัน" แทน คำถามที่น่าสนใจจริงๆ คือ รัฐนี้เกิดขึ้นได้อย่างไร Syslogs ในอดีตอาจมีประโยชน์
cn flag
@Bob mount ด้วยตัวเลือก "norecovery" นั้นปลอดภัย หากใช้งานได้ ให้ตรวจสอบว่าคุณสามารถเข้าถึงข้อมูลของคุณได้หรือไม่และสอดคล้องกันหรือไม่ อย่างไรก็ตาม เตรียมพร้อมสำหรับการคัดลอกข้อมูลอันมีค่าของคุณไว้ที่อื่น

โพสต์คำตอบ

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