☰

ext3 파일 시스템에서 물리적 오류가 있는 파일을 복구하세요.

tag-icon • tag-icon linux data-recovery ext2
ext3 파일 시스템에서 물리적 오류가 있는 파일을 복구하세요.

불만족스러운 소유자가 가능하면 돌려받고 싶어하는 파일이 포함된 손상된 Linux 랩톱의 디스크가 있습니다(백업 솔루션 없음). 이전에는 그 일과 아무 관련이 없었습니다. 디스크는 OS X와 ​​Ubuntu 11.10 모두에서 인식됩니다.

root@ubuntu1110:~# fdisk -l /dev/sdc

Disk /dev/sdc: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders, total 976773168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x80d549b4

   Device Boot      Start         End      Blocks   Id  System
/dev/sdc1   *          63   953602334   476801136   83  Linux
/dev/sdc2       953602335   976768064    11582865    5  Extended
/dev/sdc5       953602398   976768064    11582833+  82  Linux swap / Solaris

이는 스왑 파티션이 있는 Linux 배포판의 일반 설치와 일치하는 것으로 보입니다.

불행하게도 Ubuntu가 sdc1 파티션을 마운트할 수 없다고 말한 후 다소 짜증나는 메시지가 dmesg에 나타났습니다.

[  181.228092] sd 6:0:0:0: [sdc] 976773168 512-byte logical blocks: (500 GB/465 GiB)
[  181.232176] sd 6:0:0:0: [sdc] Write Protect is off
[  181.232181] sd 6:0:0:0: [sdc] Mode Sense: 21 00 00 00
[  181.236359] sd 6:0:0:0: [sdc] No Caching mode page present
[  181.236364] sd 6:0:0:0: [sdc] Assuming drive cache: write through
[  181.246696] sd 6:0:0:0: [sdc] No Caching mode page present
[  181.246707] sd 6:0:0:0: [sdc] Assuming drive cache: write through
[  182.835915]  sdc: sdc1 sdc2 < sdc5 >
[  182.854199] sd 6:0:0:0: [sdc] No Caching mode page present
[  182.854204] sd 6:0:0:0: [sdc] Assuming drive cache: write through
[  182.854208] sd 6:0:0:0: [sdc] Attached SCSI disk
[  218.250174] sd 6:0:0:0: [sdc] Unhandled sense code
[  218.250179] sd 6:0:0:0: [sdc]  Result: hostbyte=DID_ERROR driverbyte=DRIVER_SENSE
[  218.250182] sd 6:0:0:0: [sdc]  Sense Key : Hardware Error [current] 
[  218.250187] Info fld=0x0
[  218.250188] sd 6:0:0:0: [sdc]  Add. Sense: No additional sense information
[  218.250193] sd 6:0:0:0: [sdc] CDB: Read(10): 28 00 00 00 01 08 00 00 08 00
[  218.250200] end_request: I/O error, dev sdc, sector 264
[  218.250206] Buffer I/O error on device sdc, logical block 33
[  255.398994] sd 6:0:0:0: [sdc] Unhandled sense code
[  255.399029] sd 6:0:0:0: [sdc]  Result: hostbyte=DID_ERROR driverbyte=DRIVER_SENSE
[  255.399032] sd 6:0:0:0: [sdc]  Sense Key : Hardware Error [current] 
[  255.399037] Info fld=0x0
[  255.399038] sd 6:0:0:0: [sdc]  Add. Sense: No additional sense information
[  255.399053] sd 6:0:0:0: [sdc] CDB: Read(10): 28 00 00 00 01 08 00 00 08 00
[  255.399061] end_request: I/O error, dev sdc, sector 264
[  255.399066] Buffer I/O error on device sdc, logical block 33
[  281.340599] sd 6:0:0:0: [sdc] Unhandled sense code
[  281.340609] sd 6:0:0:0: [sdc]  Result: hostbyte=DID_ERROR driverbyte=DRIVER_SENSE
[  281.340618] sd 6:0:0:0: [sdc]  Sense Key : Hardware Error [current] 
[  281.340653] Info fld=0x0
[  281.340655] sd 6:0:0:0: [sdc]  Add. Sense: No additional sense information
[  281.340659] sd 6:0:0:0: [sdc] CDB: Read(10): 28 00 00 00 00 67 00 00 08 00
[  281.340667] end_request: I/O error, dev sdc, sector 103
[  281.340739] EXT3-fs (sdc1): error: can't read group descriptor 4

나의 현재 이론은 하드 드라이브에 추가 블록이 부족하여 파티션이 마운트될 때 사용된 영역에 실제 불량 블록이 도입되었다는 것입니다. dd는 이것을 확인했습니다:

root@ubuntu1110:~# dd if=/dev/sdc1 of=/dev/null bs=10240 conv=noerror
dd: reading `/dev/sdc1': Input/output error
2+0 records in
2+0 records out
20480 bytes (20 kB) copied, 44.7084 s, 0.5 kB/s
dd: reading `/dev/sdc1': Input/output error
9+1 records in
9+1 records out
96256 bytes (96 kB) copied, 162.933 s, 0.6 kB/s
dd: reading `/dev/sdc1': Input/output error
9+1 records in
9+1 records out
96256 bytes (96 kB) copied, 180.083 s, 0.5 kB/s

불량 블록이 초기에 발생하고 프로세스 후반에도 전송 속도가 매우 느립니다(표시되지 않음).

이제 내 질문은 여기에서 어떻게 가는가입니다. 손상된 ext2/ext3 파일 시스템에서 읽을 수 있는 것이 필요합니다. 그래야 아직 남아 있는 디스크에서 해당 파일을 복사할 수 있습니다. 지난 15년 동안 Linux 시스템 관리를 많이 하지 않았기 때문에 잘 모르겠습니다. 검색할 용어를 수정하세요.

밤새 디스크 이미지를 복사할 수도 있지만 그렇게 되면 "이 블록은 잘못되었습니다"라는 메시지가 손실될 수 있습니다.

이 상황에서는 어떤 절차가 유용할까요?

답변1

디스크 복구의 첫 번째 규칙:디스크 사용을 중지하세요. 하드웨어 문제(예: 헤드 충돌)가 있는 경우 파일 시스템이 손상되면 추가 손상이 발생할 수 있으며 손상으로 인해 상황이 더욱 악화 mount될 수 있습니다 . fsck(모드에서도 ro! 참고해주세요.mount -t ext3 -o ro ~ 할 것이다로그를 재생하고 디스크에 기록해 보세요! )

사용dd_rescue또는구조하다가능한 한 많은 디스크 이미지를 다른 시스템에 복사하려면 디스크를 축소한 다음 이미지 복사본을 만드십시오. 복제본 중 하나에서 모든 복원 시도가 수행됩니다.

이제 확장된 데이터 복구에 대한 몇 가지 팁을 알려드리겠습니다.여기. 요컨대,

  • 파티션 레이아웃이 여전히 작동하는 것 같습니다. 그렇지 않은 경우 다음을 사용할 수 있습니다.테스트 디스크또는부분파티션 테이블을 복원해 보십시오.
  • e2fsck파일 시스템을 마운트 가능한 상태로 복원하는 것이 가능할 수도 있습니다. 매달린 inode를 배치 /lost+found하고 오류를 보고합니다.
  • ext4magic기록된 메타데이터에서 데이터 복구를 시도합니다. 로그에서 파일을 복구할 수 있는지 여부는 행운과 우연에 달려 있지만 거기에는 뭔가가 있을 수도 있습니다.
  • 탐정 키트대부분의 파일 시스템 구조를 구문 분석하고 출력할 수 있습니다. 파일 시스템의 내부 레이아웃에 대해 어느 정도 알고 있고 편리한 16진수 편집기가 있는 경우("수퍼블록이 손상되었고 백업 수퍼블록이 더 이상 사용되지 않지만 충분한 데이터를 선택하여 직접 수행할 수 있음"과 같은 작업을 수행할 수 있음) "와 같은 것), IMO에서는 확실히 대부분의 데이터를 복구하는 데 가장 유용한 도구입니다.
  • 사진 기록파일처럼 보이는 일련의 바이트를 찾으려고 시도합니다. 파일의 시작/끝만 추측할 뿐 디렉터리, 파일 이름 등 파일 시스템 구조에 대해 아무것도 알 수 없으며 조각난 파일을 찾지 않습니다.

답변2

전문적인 데이터 복구 서비스의 일반적인 장단점을 모두 이해하고 데이터 손실에 따른 비용과 직접 복구하는 데 따르는 위험을 비교 평가해 보았다고 가정합니다. 사용자는 데이터가 000달러의 가치가 있다고 생각하지 않습니다.예몇 시간의 시간을 투자할 가치가 있습니다...

이것이 내가 할 일이다.

dd에서 지속적으로 0.5kB/s를 얻는다면 아마도 이것을 시도하는 데 시간을 투자할 가치가 없을 것입니다.

너할 수 있다디스크에서 Testdisk를 실행합니다. 그것가능한일하다. 비용/위험으로 인해 다른 옵션이 없다면... 그건 귀하의 결정입니다. 효과가 있을 수도 있습니다.

전반적으로 이러한 문제는 정치적 지뢰밭입니다. 사용자는 동료에게 파일을 다시 보내달라고 요청하기가 너무 부끄럽거나 관리자에게 직면하고 싶지 않고 정기적으로 백업하지 않았으며 이제 데이터 복구에 수천 달러를 지출해야 함을 인정합니다. 그들은 당신이 문제를 해결하고 모든 문제를 해결할 수 있기를 바라고 있습니다. 그리고 그 과정에서 드라이브가 스스로 파괴되는 경우도 있습니다. 그들은 자신을 구하기 위해 당신을 버스 밑으로 던질 것입니다.

관련 정보