손상된 드라이브(IO 오류)에 대한 고급 NTFS 파티션 파일 복구 기술이 있습니까?

Question

저는 최근 몇 개의 VM에 영향을 미치는 ESXi 호스트의 하드 드라이브에 엄청나게 작지만 매우 중요한 손상을 입었습니다. 꼭 복구하고 싶은 파일이 있는데, 당연히 그 파일은 정기적인 백업에서 제외되었습니다. 가장 최근 사본은 6개월 된 것입니다. 알고 보니 그게 필요했는데... 이런.

세부:

1) Parted Magic 부팅 가능 ISO 내에서 ddrescue(AWESOME 도구)를 사용하여 문제의 VM 드라이브를 99.98% 복구했습니다. 불행하게도 오류는 거의 전적으로 최근 파일 쓰기에서 발생한 것으로 보입니다. 물론 이는 정확히 제가 가장 많이 복구해야 하는 섹터입니다.

2) 드라이브는 불량 섹터 읽기 시 IO 오류를 표시하지만 때때로 이전 불량 섹터를 읽는 데 성공합니다! 따라서 아직 복구가 가능합니다. 그보다 약간 더 자주 일종의 중대한 오작동이 발생하고 드라이브 회전 속도가 느려졌다가 다시 시작됩니다. 아, 그리고 스핀다운의 약 1/4은 다시 발생하지 않습니다. (하드 전원 주기가 필요하며 종료가 작동하지 않습니다.) 마지막으로 거의 모든 불량 섹터 읽기가 듣기 좋은 딸깍 소리와 함께 제공됩니다.

3) 중요한 VM 디스크는 NTFS로 포맷되어 있습니다.

4) 일반적으로 손상된 NTFS 볼륨을 읽기 전용으로 마운트할 수 있으며, 필요한 파일이 포함된 폴더로 이동할 수 있습니다(약간 덜 자주). 그러나 문제의 파일은 폴더에 대해 'ls'를 수행할 때 항상 IO 오류를 발생시키는 것으로 보입니다. 폴더의 다른 파일에는 IO 오류가 발생하지 않습니다.

5) ntfsinfo/etc를 사용해 보았습니다... 정확히 제가 필요한 것 같지만... 파티션이 전혀 열리지 않습니다. ('마운트'가 보통 그렇게 되기 때문에 실망스럽습니다)

6) 파일은 Excel 2003 시대의 XLS 파일이므로 원시 디스크 이미지를 검색할 수 있는 문자열이 있는지 잘 모르겠습니다. (아마도 6개월 이전 버전의 일부일까요?)

나는 정말로 debugfs의 기능과 같은 것을 사용하고 싶습니다. 그러나 매뉴얼 페이지에 따르면 ntfs 도구를 사용하여 파티션을 열 수 있는 경우에만 해당 작업을 수행할 수 있는 것으로 나타납니다. 특히 IO 오류가 순전히 파일의 메타데이터 내에 있을 수 있는지, 파일 내용을 복사할 수 있을 만큼 디렉터리 레코드를 복원할 수 있는지 궁금합니다. 최후의 수단으로, 내가 검색할 수 있는 부분 파일 내용이 무엇이든 좋습니다.

이전에 비교적 간단한 커널 모듈을 작성했으므로 더 많은 디버그 정보를 활성화(또는 추가)하여 특수 NTFS 모듈을 컴파일할 수 있습니다. (이 파일은 복구를 시도하기 위해 적어도 며칠 동안 만질 가치가 있습니다... 게다가 그 과정에서 멋진 것들을 배우고 있습니다.)

어떤 조언이 있습니까?

편집하다:

추가 드라이브 오류 정보:

물론 /var/log/messages에는 많은 NTFS-fs 오류가 표시됩니다. 하지만 마침내 일반적으로 받는 처리되지 않은 감지 코드 메시지(sense key 0x3, ASC=0x11, ASCQ=0x4)를 번역하려고 애썼습니다. (복구되지 않은 읽기 오류 - 자동 재할당 실패로 변환되는 것으로 나타남)

드라이브의 회전 속도가 느려지면 "scsi0:*BusLogic BT-958 초기화됨" 메시지. Linux SCSI 드라이버인지, ESXi 드라이버인지, 아니면 드라이브 자체가 드라이브 스핀다운을 결정하는지 잘 모르겠습니다. Linux 드라이버라면 드라이버를 수정할 수 있을 것입니다. 스핀다운을 방지하기 위해 이러한 전체 복구 작업은 전원 주기가 필요한 스핀다운으로 인해 훨씬 ​​더 고통스럽습니다.

편집2:

문제의 파일이 포함된 디렉터리를 'ls'한 직후에 "end_request: I/O 오류, dev sda, 섹터 7238859" 로그 메시지를 사용하여 ddrescue 작업의 대상을 해당 섹터로 지정했습니다. 나는 현재 기회를 잡고 이것이 성공하면 해당 섹터를 라이브 디스크에 다시 쓸 계획입니다. 아마도 이런 식으로 문제의 파일을 천천히 다시 빌드할 수 있을 것입니다. 그럼에도 불구하고 대부분의 복구 가능한 불량 섹터는 20회 미만의 재시도만으로 복구됩니다... 이것은 지금까지 150회가 넘습니다... *한숨*

편집3:

필요한 파일의 'ls'에서 발생한 섹터 오류는 완전히 비협조적입니다(밤새 1000번 이상 시도했지만 운이 없었습니다). 나는 당신이 'ls'를 할 때 그것이 단지 메타데이터이길 바라고 있습니다. :)

대부분의 ddrescue 복사본을 가지고 있지만 마운트되지 않습니다(또는 파일 없이 마운트되지 않습니다). 손상된 드라이브는 대부분의 경우 올바르게 마운트됩니다. 손상된 드라이브 포스 '마운트'의 IO 오류로 인해 작동하는 미러로 돌아갈 수 있습니까?

** 편집4:**

지금은 포기하고 추가 제안을 기다리고 있습니다. 드라이브를 제거하고 상자를 다시 만들었습니다. 무슨 일이 생길 경우를 대비해 운전을 계속하겠습니다.

Answer 1

내 경험에서 나온 몇 가지 참고 사항:

1. (원인)HD 액세스 시도 중에 이상한 소리가 들리고 임의의 디스크 위치에서 문제가 발생하지 않는 경우 근본 원인은 아마도 전자 장치가 아닌 디스크 표면에 있을 가능성이 높습니다. 불행하게도 이는 슬픈 일입니다. 대본. 전자 장치만 "단지"였다면 데이터의 대부분 또는 전부를 복구할 수 있는 기회가 있었을 것입니다.
2. (불량 섹터)아직 수행하지 않았다면 웹에서 디스크 제조업체의 부팅 가능한 진단/복구 도구를 검색하여 다운로드하고 부팅하고 심층 테스트를 실행한 후 불량 섹터를 다시 매핑해 보십시오. 이것이 무료 방법 중 가장 좋은 방법입니다. 불량 섹터는 커지는 경향이 있습니다. 따라서 2314번째 읽기 시도 후 파일의 한 덩어리를 포착하더라도 이러한 시도로 인해 인근 불량 섹터가 커져 다른 부분을 복구할 가능성이 효과적으로 줄어들 가능성이 있습니다. 파일의.
3. (NTFS 복구 중)MS Windows 기본 도구뿐만 아니라 NTFS 파일 시스템도 고칠 수 없습니다. NTFS 이미지를 마운트할 수 없는 경우(전체 디스크가 아닌 파티션을 마운트하려고 했는지도 확인하세요!) testdiskLinux에서와 같은 작업을 시도할 수 있지만 실패할 경우 Windows가 chkdisk도움을 줄 수 있습니다. 가상 머신 아래에 Windows가 설치되어 있는 경우 에서 얻은 원시 이미지를 ddrescue해당 가상 머신에서 지원하는 형식(예: VDI또는 VMDK)으로 변환하고 이를 VM에 추가한 다음 명령줄 모드에서 Windows를 부팅하여 파일 시스템을 수정할 수 있습니다.VirtualBox를 사용하는 경우 해당 이미지를 변환하는 명령은 VBoxManage convertfromraw <filename> <outputfile>선택적으로 --format VDI|VMDK|VHD지정된 출력 형식을 얻기 위해 사용됩니다.

Answer 2

이는 귀하의 경우에 적용될 수도 있고 적용되지 않을 수도 있지만 최후의 수단 중 하나는 "냉동고 트릭"입니다. 보다손상된 하드 드라이브에서 데이터 복구: "냉동 장치 트릭"방법에 대한 논의를 위해.