☰

물리적 오류가 있는 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에서도 !romount -t ext3 -o ro ~ 할 것이다저널을 재생하고 디스크에 기록해 보십시오!)

사용dd_rescue또는구출가능한 한 많은 디스크 이미지를 다른 시스템에 복사하려면 디스크를 치우고 이미지의 복사본을 만드십시오. 복사본 중 하나에서 모든 복구 시도를 수행합니다.

이제 외부 데이터 복구에 대한 몇 가지 팁을 알려드렸습니다.여기. 즉,

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

답변2

전문 데이터 복구 서비스의 일반적인 장단점을 모두 겪었다고 가정하고, 손실된 데이터의 비용과 직접 복구하는 위험을 비교해 보았습니다... 사용자는 데이터가 $000의 가치가 없다고 결정했습니다. 하지만 그것은~이다당신의 시간과 시간의 가치가 있습니다 ...

내가 할 일은 다음과 같습니다.

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

너~할 수 있었다디스크에 대해 Testdisk를 실행합니다. 그것~할 것 같다일하다. 비용/위험으로 인해 다른 옵션이 필요하지 않다면... 그것은 귀하의 선택입니다. 효과가 있을 수도 있습니다.

일반적으로 이러한 문제는 정치적 지뢰밭입니다. 사용자는 너무 당황해서 동료에게 파일을 다시 보내달라고 요청할 수 없거나 관리자에게 직면하고 싶지 않고 정기적인 백업을 실행하지 않았음을 인정하고 이제 데이터 복구에 수천 달러를 소비해야 합니다. 그들은 당신이 문제를 해결하고 모든 문제를 해결해 줄 수 있기를 바라고 있습니다. 그리고 그 과정에서 드라이브가 스스로 파괴된다면 말이죠. 그들은 자신들의 목숨을 구하기 위해 당신을 버스 밑으로 던져버릴 것입니다.

관련 정보