จากเซ็กเตอร์ที่ไม่ดีไปจนถึง“ ไฟล์ที่เสียหาย” - ทำสำหรับ Linux / ext3 ฉันสามารถทำได้สำหรับ Windows / NTFS หรือไม่


17

เมื่อสมาร์ทตรวจสอบดิสก์จะรายงานเซกเตอร์เสียมันเป็นสิ่งสำคัญที่จะสามารถระบุไฟล์ที่มีเซกเตอร์เสีย - และกู้คืนจากการสำรองข้อมูล ด้านล่างนี้ฉันแสดงให้เห็นว่าฉันทำสิ่งนี้กับเซิร์ฟเวอร์ Linux / ext3 VMWARE ของฉันได้อย่างไร แต่ทุกคนทราบว่าสามารถทำได้สำหรับ Windows / NTFS หรือไม่

นี่เป็นวิธีที่ฉันทำสำหรับ Linux / ext3: ฉันขอให้ไดรฟ์ทำการสแกนพื้นผิวของฮาร์ดแวร์ (ด้านล่างระดับ OS โดยมีวงจร SMART บนไดรฟ์):

vserver:~# smartctl -t long /dev/sdc

ฉันดูผลลัพธ์:

vserver:~# smartctl -a /dev/sdc
...
196 Reallocated_Event_Count 0x0032   100   100   000    Old_age   Always       -       1
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       9
...
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Extended offline    Completed: read failure       90%     27679         591363172

ดังนั้นหนึ่งเซ็กเตอร์ถูกทำเครื่องหมายว่าแย่แล้ว 9 ถูกทำเครื่องหมายเพื่อแทนที่จากพื้นที่เซกเตอร์ "การจัดเตรียม" ที่สำคัญบล็อกโลจิคัลที่อยู่ (LBA) แรกที่ไม่สามารถอ่านได้คือ 591363172

ฉันพบพาร์ทิชัน (และชดเชยภายใน) ที่หมายเลขนี้ "แปล" เป็น:

vserver:~# fdisk -lu /dev/sdc
Device Boot      Start         End      Blocks   Id  System
/dev/sdc1           32   976773119   488386544   83  Linux

พาร์ติชันเริ่มต้นที่เซกเตอร์ 32 ดังนั้นเซกเตอร์ที่ไม่ดีคือ ...

vserver:~# bc -l
591363172-32+1
591363141

... ที่ออฟเซ็ตของภาค 591363141 จากจุดเริ่มต้นของพาร์ติชัน

ตอนนี้ฉันสามารถหาไฟล์ที่ถูก "hosed":

vserver:~# tune2fs -l /dev/sdc1 | grep Block\ size
Block size:               4096

ขนาดบล็อกของระบบไฟล์ EXT3 นี้คือ 4096 ไบต์ดังนั้นเซกเตอร์เสียจะทำลายบล็อกนี้ในระบบไฟล์:

vserver:~# bc -l
591363141*512/4096
73920392.62500000000000000000

และหมายเลขบล็อก (73920392) ตรงกับไฟล์นี้:

vserver:~# debugfs
debugfs 1.41.3 (12-Oct-2008)
debugfs:  open /dev/sdc1
testb 73920392
debugfs:  testb 73920392
Block 73920392 marked in use
debugfs:  icheck 73920392
Block           Inode number
73920392        18472967
debugfs:  ncheck 18472967
Inode           Pathname
18472967        /path/to/filewithbadsector

และฉันกู้คืนไฟล์นั้นจากข้อมูลสำรองของฉัน

มีขั้นตอนเทียบเท่าที่ฉันสามารถติดตาม Windows / NTFS ได้หรือไม่


FYI: จำนวนที่ค้างอยู่ในปัจจุบันของ 9 หมายความว่ามีเซกเตอร์เสีย 9 แห่งไม่ใช่แค่หนึ่งเซ็กเตอร์ การทดสอบตัวเองแบบขยายจะหยุดที่การทดสอบแรกที่พบ ddก่อนที่คุณจะเรียกคืนจากการสำรองข้อมูลคุณยังต้องการที่จะจัดการกับภาคที่ไม่ดีโดยการเขียนเลขศูนย์ไปด้วย นี่จะเป็นการบังคับให้ไดรฟ์ทำการซ่อมแซมหรือทำการจัดสรรใหม่
psusi

ใช่คุณพูดถูก หลังจากการคืนค่าฉันทำการตรวจสอบสมาร์ทอีกครั้งและพบว่าทั้งหมดก็โอเค - ดังนั้นการเขียนของไฟล์ที่เขียนบนเซกเตอร์เสีย 9 + 1 (และพื้นที่การจัดเตรียมเตรียมไว้ใช้แทน) แต่ Windows ล่ะ :-)
ttsiodras

ฉันคิดว่าการคำนวณของคุณสำหรับเซกเตอร์ชดเชยในพาร์ติชันไม่ถูกต้อง หมายเลขเซกเตอร์ (อื่น ๆ ที่มีอยู่จริงหรือที่รู้จักกันในชื่อ CHS) เป็นศูนย์ทั้งหมดเนื่องจากเซกเตอร์ 32 คือเซกเตอร์พาร์ติชัน 32-32 == 0 ไม่ใช่ 1

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

คำตอบ:


7

ฉันรู้ว่าคุณมี NTFS FS และเรียกใช้ windows ใน FS นั้น ฉันไม่ทราบว่าคุณ "สามารถ" บูต Linux สดเพื่อทำงานกับไดรเวอร์นั้นหรือไม่

หากคุณสามารถบูต Linux จากซีดีหรือ USB คุณสามารถใช้ ntfsprogs ดูที่ -

ntfscluster 

ntfsinfo 

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


ฉันพบโพสต์ในฟอรัมนี้ซึ่งมีตัวห่อหุ้มยูทิลิตี้เพื่อทำสิ่งนี้ผ่านระบบไฟล์ที่แตกต่างกันและใช้ ntfscluster ด้วย ubuntuforums.org/showthread.php?t=1943721
Lethargy

ใช่คุณสมบัติ ddrutility: ค้นหาไฟล์ที่เกี่ยวข้องกับเซ็กเตอร์ที่ไม่ดียังสามารถใช้ไฟล์ที่มีรายการเซกเตอร์บางทีเราอาจใช้ "badblocks -nvs" + "ddrutility"
diyism
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.