불량 섹터에서 "손상된 파일"까지-Linux / ext3 용으로 Windows / NTFS 용으로 할 수 있습니까?

디스크의 SMART 검사에서 불량 섹터가보고되면 불량 섹터가있는 파일을 식별하고 백업에서 복원 할 수 있어야합니다. 아래에서는 Linux / ext3 VMWARE 서버에서이 작업을 수행 한 방법을 보여 주지만 Windows / NTFS에서이 작업을 수행 할 수 있는지 아는 사람이 있습니까?

Linux / ext3에서 수행 한 방법은 다음과 같습니다. 먼저 드라이브에 하드웨어 표면 스캔 (온 드라이브 SMART 회로를 사용하여 OS 수준 아래)을 수행하도록 요청했습니다.

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에 대해 동등한 절차가 있습니까?

— 티시오 드라
소스

참고로, 현재 보류중인 숫자 9는 하나가 아닌 9 개의 불량 섹터가 있음을 의미합니다. 확장 된 자체 테스트는 처음 발견 할 때 중지됩니다. 백업에서 복원하기 전에에 0을 써서 불량 섹터를 처리하려고합니다 dd. 그러면 드라이브가 드라이브를 복구하거나 재 할당해야합니다.

— psusi

그렇습니다. 복원 후, 나는 또 다른 SMART 검사를 수행하고 모든 것이 정상이라는 것을 알았습니다. 따라서 파일 쓰기는 9 + 1 개의 불량 섹터를 기록했습니다 (스테이징 영역은 대체물을 제공했습니다). 그러나 Windows는 어떻습니까? :-)

— ttsiodras

파티션의 섹터 오프셋 계산이 잘못되었다고 생각합니다. 섹터 32는 1이 아닌 파티션 섹터 32-32 == 0이므로 섹터 번호 (물리적 CHS가 아닌 다른 것)는 모두 0을 기준으로합니다.

놀랍게도 아직 1 년이 넘은 오래된 질문에 대해 아무도 말하지 않았습니다 . 드라이브에서 불량 섹터를 보기 시작 하면 드라이브의 자동 내부 불량 블록 리매핑이 너무 많아서 더 이상 보상 할 수 없다는 것을 의미합니다. 백업에서 죽어가는 드라이브 로 복원하는 대신 드라이브 를 교체하고 새 드라이브로 복원해야합니다.

— voretaq7

NTFS FS가 있고 해당 FS에서 창을 실행한다는 것을 알고 있습니다. 해당 드라이버에서 작동하도록 라이브 Linux를 "부팅"할 수 있는지 모르겠습니다.

CD 또는 USB에서 Linux를 부팅 할 수 있으면 ntfsprogs를 사용할 수 있습니다. 보다 -

ntfscluster 

ntfsinfo

ntfscluster가 특정 클러스터가 저장하는 파일을 알려줍니다. 이것이 올바른 방향으로 나아가기를 바랍니다.

— JM 베커
소스

다른 파일 시스템 에서이 작업을 수행하는 유틸리티 래퍼가 있고이 ntfscluster도 사용하는이 포럼 게시물을 발견했습니다. ubuntuforums.org/showthread.php?t=1943721

— Lethargy

예, ddrutility 기능 : 불량 섹터와 관련된 파일을 찾습니다. 섹터 목록이있는 파일을 사용할 수도 있습니다. 아마도 "badblocks -nvs"+ "ddrutility"를 사용할 수 있습니다

— diyism