Від поганого сектора до "пошкодженого файлу" - це робилося для Linux / ext3, чи можу це зробити для Windows / NTFS?

Коли перевірка SMART на диску повідомляє про поганий сектор, важливо вміти ідентифікувати файл із поганим сектором - та відновити його з резервних копій. Нижче я показую, як я це зробив для свого сервера VMWARE Linux / ext3 - але хтось знає, чи можна це зробити для Windows / NTFS?

Ось як я це зробив для Linux / ext3: я спершу попросив накопичувач зробити апаратне сканування поверхні (нижче рівня ОС, з 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

Так, ви праві. Після відновлення я зробив ще одну перевірку SMART і виявив, що все в порядку - тому написання файлу, мабуть, написало 9 + 1 поганих секторів (а область постановки надала замінники). А як щодо Windows? :-)

— ttsiodras

Я думаю, що ваш розрахунок за зміщення сектору в розділі є невірним. Номери секторів (крім фізичних, відомих також як CHS) базуються на нулі, оскільки сектор 32 - це сектор розділів 32-32 == 0, а не 1.

Шокуюче ніхто ще не сказав цього питання за рік + старе питання: Коли ви починаєте бачити погані сектори на накопичувачі, це означає, що у вас стільки автоматичного внутрішнього поганого блоку перезавантаження блоку диска вже не можна компенсувати. Замість того, щоб відновити з резервного копіювання на відмираючий диск , слід замінити диск та відновити його на новому диску.

— voretaq7

Я знаю, що у вас є NTFS FS і запустіть вікна на цьому FS. Я не знаю, ви могли б "запустити" живий Linux для роботи на цьому драйвері чи ні.

Якщо ви можете завантажувати Linux з CD або USB, ви можете використовувати ntfsprogs. подивись на -

ntfscluster 

ntfsinfo

Я вважаю, що ntfscluster розповість, який файл зберігає певний кластер. Я сподіваюся, що це направить вас у правильне русло.

— Дж. М. Беккер
джерело

Я знайшов цю сторінку на форумі, яка має програму для обговорення утиліти для різних файлових систем, а також використовує ntfscluster. ubuntuforums.org/showthread.php?t=1943721

— Летаргія

Так, ddrutility особливість: Знаходить файли , пов'язані з поганими секторами, може також використовувати файл зі списком сектора, можливо , ми могли б використовувати «badblocks -nvs» + «ddrutility»

— diyism