손실된 ext4 파티션: testdisk에 파일이 나열되지만 파티션 테이블을 수정하지 못함

손실된 ext4 파티션: testdisk에 파일이 나열되지만 파티션 테이블을 수정하지 못함

요약:

Testdisk는 손실된 ext4 파티션을 찾고 포함된 파일을 나열할 수 있지만 디스크에 파티션 구조를 쓰려고 하면 아무 일도 일어나지 않습니다.

업데이트: 실행 후 e2fsck -f /dev/sdc1디스크가 마운트되어 정상적으로 실행되는 것 같습니다. 그러나 일부 오류도 보고되었습니다(아래 15. 참조).

무슨 일이에요:

나는 문제와 관련하여 내가 한 모든 일을 나열하려고 노력할 것입니다:

  1. FAT32(Intenso라는 이름)로 사전 포맷된 새 외장 5TB 하드 드라이브를 받았습니다.
  2. 해당 파티션을 삭제하고 gparted(Intenso5TB라는 이름)를 사용하여 새 ext4 파티션을 만들었습니다.
  3. 파티션이 루트에 속해 있으므로 소유자와 그룹을 내 사용자로 변경했습니다.
  4. 수백 GB의 데이터를 해당 파티션으로 옮긴 다음 안전하게 제거했습니다.
  5. 다음에 하드 드라이브를 연결했을 때 읽기 전용으로 마운트되었습니다. 내 사용자가 여전히 소유자였습니다.
  6. Ubuntu의 "디스크" 유틸리티의 마운트 옵션에 "rw"를 추가하고 드라이브를 마운트 해제했습니다.
  7. 그러면 디스크 유틸리티가 /dev/sdc1 파티션을 "type 알 수 없음"으로 표시하고 마운트할 수 없습니다.
  8. 저는 "Edit Partition"을 선택하고 "Type linux (0x83)"를 선택했습니다(어떤 유형도 미리 선택되지 않았습니다). 변경 사항이 없습니다(아직 유형을 알 수 없음).
  9. 나는 달려 sudo testdisk /dev/sdc가서 빠른 분석을 했고 그 결과는 다음과 같았습니다.

    * Linux                    0   4  5 76000  41  9 1220942336 [Intenso5TB]
    

    누르면 p내가 파티션으로 이동한 파일이 표시됩니다., 그래서 Testdisk에게 파티션 구조를 디스크에 쓰라고 지시했습니다.

  10. 파티션 테이블을 새로 고치기 위해 다시 재부팅한 후 동작은 다시 7에 설명된 대로 이루어졌습니다.
  11. 나는 9를 다시 썼다.; 이번에 사용해 보았는데

    partprobe /dev/sdc
    

    다시 재부팅하지 않으려고 했으나 다음 메시지가 표시되었습니다.

    Error: Partition(s) 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64 on /dev/sdc have been written, but we have been unable to inform the kernel of the change, probably because it/they are in use.  As a result, the old partition(s) will remain in use.  You should reboot now before making further changes.
    
  12. sudo fdisk -lu보고

    Disk /dev/sdc: 4,6 TiB, 5000981078016 bytes, 1220942646 sectors
    Units: sectors of 1 * 4096 = 4096 bytes
    Sector size (logical/physical): 4096 bytes / 4096 bytes
    I/O size (minimum/optimal): 4096 bytes / 33550336 bytes
    Disklabel type: dos
    Disk identifier: 0x4400838c
    
    Device     Boot Start        End    Sectors  Size Id Type
    /dev/sdc1  *      256 1220942591 1220942336  4,6T 83 Linux
    
  13. sudo parted /dev/sdc그런 다음 아무 작업도 수행하지 않고 실행했습니다 rescue 256 1220942591(지연 없음, 출력 없음, parted 내부에 새 명령 프롬프트만 표시됨). 또는 rescue 0 1220942591와 동일합니다 .rescue 1 1220942591rescue 1 -1

  14. Testdisk를 사용하여 심층 검색을 실행했는데 다음과 같은 몇 가지 동일한 줄이 보고되었습니다.

    Linux                    0   4  5 76000  41  9 1220942336 [Intenso5TB]
    

    게다가:

    check_FAT: can't read FAT boot sector
    Invalid FAT boot sector
     0 D FAT16 LBA            252822 192 45 254047 161 57   19677685
      FAT16 LBA            252822 192 45 254047 161 57   19677685
    

    다음을 실행하고 닫는 동안:

    TestDisk 7.0, Data Recovery Utility, April 2015
    Christophe GRENIER <[email protected]>
    http://www.cgsecurity.org
    
    Disk /dev/sdc - 5000 GB / 4657 GiB - CHS 76000 255 63
    
    The harddisk (5000 GB / 4657 GiB) seems too small! (< 16 TB / 15 TiB)
    Check the harddisk size: HD jumpers settings, BIOS detection...
    
    The following partition can't be recovered:
         Partition               Start        End    Size in sectors
    >  FAT16 LBA            252822 192 45 254047 161 57   19677685
    
    
    
    
    
    
    
    
    
    
    [ Continue ]
    80 GB / 75 GiB
    
  15. 실행 후 e2fsck -f /dev/sdc1런처에 디스크가 표시되었습니다. 더 많은 내용을 알 때까지 추가 변경을 피하기 위해 e2fsck을 (를) 취소했습니다 . Ctrl+C그런 다음 클릭 시 드라이브가 성공적으로 마운트되었습니다. 읽고 쓸 수 있을 것 같습니다. 출력 e2fsck:

    e2fsck -f /dev/sdc1
    e2fsck 1.42.13 (17-May-2015)
    ext2fs_open2: Bad magic number in super-block
    e2fsck: Superblock invalid, trying backup blocks...
    Superblock needs_recovery flag is clear, but journal has data.
    Recovery flag not set in backup superblock, so running journal anyway.
    Intenso5TB: recovering journal
    Pass 1: Checking inodes, blocks, and sizes
    Inode 59883521 is in use, but has dtime set.  Fix<y>? yes
    Inode 59883521 has imagic flag set.  Clear<y>? yes
    Inode 59883521 has compression flag set on filesystem compression support.  Clear<y>? yes
    Inode 59883521 has INDEX_FL flag set but is not a directory.
    Clear HTree index<y>? yes
    Inode 59883521, i_blocks is 16777216, should be 0.  Fix<y>? yes
    Deleted inode 59885573 has zero dtime.  Fix<y>? yes
    Deleted inode 59885574 has zero dtime.  Fix<y>? yes
    ^CIntenso5TB: e2fsck cancelled.
    
    Intenso5TB: ***** FILE SYSTEM WAS MODIFIED *****
    

내 질문:

  1. 처음에 이 문제를 일으킬 수 있었던 명백한 실수가 있습니까?

  2. 손실된 파티션을 복구할 수 있는 희망이 있습니까? 새로운 질문: 보고된 오류는 e2fsck걱정할 이유가 있나요? 물리적으로 손상된 드라이브를 암시할 수 있습니까?

  3. partprobe11에서 오류 메시지가 나타나는 이유는 무엇입니까 ?

(데이터는 제가 한 번도 건드린 적이 없는 다른 디스크에서 옮겨졌기 때문에 지금은 보이지 않지만 거기에서 복구할 수는 있을 것입니다.)

답변1

실행하면 e2fsck -f /dev/sdc1잘못된 슈퍼 블록이 수정되었으며 장치는 문제 없이 인식되었습니다. 그런 다음 e2fsck발견된 모든 문제를 해결 하도록 했습니다 . 후속 실행에서는 e2fsck더 이상 오류가 보고되지 않았습니다.

smartctl오류 없이 9시간 후에 완료되는 연장된 오프라인 테스트 (자동 스핀다운이 테스트를 중단하는 것을 방지하기 위해 저는이 해결 방법).

관련 정보