☰

ext4 전체 장치 파일 시스템 및 손상된 GPT 파티션 테이블 복구

tag-icon • tag-icon partition ext4 gpt
ext4 전체 장치 파일 시스템 및 손상된 GPT 파티션 테이블 복구

여기에 있는 문제와 매우 비슷한 문제가 있습니다.

https://askubuntu.com/questions/1370421/restore-ext4-hd-after-creating-gpt-partition-table

내 문제는 블록 장치에 직접 존재하는 ext4 파일 시스템이 있고 완전히 다른 드라이브에 Windows를 설치하면 해당 장치의 파티션 테이블이 엉망이 된다는 것입니다.부족파티션 테이블).

부팅하면 드라이브에 다음과 같은 GPT 파티션 테이블이 있습니다.

λ  sudo fdisk -l /dev/nvme1n1
Disk /dev/nvme1n1: 931.51 GiB, 1000204886016 bytes, 1953525168 sectors
Disk model: Samsung SSD 970 EVO 1TB
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 73405727-65E8-485F-99F8-C2D65E99D767

Device         Start        End    Sectors   Size Type
/dev/nvme1n1p1  2048 1953525127 1953523080 931.5G Linux filesystem

하지만 파티션을 마운트할 수 없으며 파일 시스템이 잘못된 것 같습니다. 그러나 다음을 실행하여 모든 데이터를 다시 가져올 수 있습니다 fsck.ext4 /dev/nvme1n1. 그러나 이것은 파티션이 아니라 전체 장치이므로 그렇게 하면 GPT 테이블이 폭파될 것 같습니다.

λ  sudo fdisk -l /dev/nvme1n1
The primary GPT table is corrupt, but the backup appears OK, so that will be used.
...

를 사용하여 테이블을 다시 작성할 수 있지만 gdisk그러면 손상된 파일 시스템으로 돌아갑니다. 이렇게 앞뒤로 전환할 수 있지만 실제로 원하는 작업, 즉 유효한 GPT 파티션 테이블을 생성하고 기존 파일 시스템을 여기에 복원하는 방법을 모르겠습니다.

나는 좋은 결과 없이 명시적인 슈퍼블록을 전달하려고 시도했습니다.

λ  sudo fsck.ext4 -p -b 32765 -B 4096 /dev/nvme1n1p1
fsck.ext4: Bad magic number in super-block while trying to open /dev/nvme1n1p1

답변1

(그런 식으로는) 불가능해요.

동일한 블록 장치에 파티션 테이블과 파일 시스템을 가질 수 없습니다.

/dev/nvme1n1에 파티션을 생성하면 새 블록 장치 /dev/nvme1n1p1이 제공됩니다. 파일 시스템에는 새 블록 장치를 사용해야 합니다.

이는 모든 데이터를 파티션 오프셋으로 이동하는 것을 의미합니다. 파일 시스템 데이터를 이전 오프셋으로 유지하는 것은 작동하지 않습니다. fsck는 이 문제를 해결해 주지 않습니다. 따라서 (당신이 하려고 하는 방식으로는) 할 수 없습니다.

따라서 귀하의 옵션은 다음과 같습니다.

  • 베어 드라이브를 그대로 계속 사용하고 msdos/gpt 파티션 테이블 헤더를 완전히 제거합니다( wipefsmsdos/gpt 파티션 헤더를 제거하는 경우에만 해당).

  • 파일 시스템을 2MiB만큼 축소한 다음 1MiB(또는 다른 파티션 오프셋)만큼 이동합니다. 드라이브의 시작과 끝 부분에 GPT 헤더를 위한 공간을 확보하려면 축소가 필요합니다.

  • 모든 파일을 백업하고 새 파티션과 파일 시스템을 사용하여 처음부터 올바르게 설정한 다음 파일을 복원하세요.

마지막 옵션을 권장합니다. 데이터 오프셋 전송은 이론적으로 수행할 수 있지만(gparted와 같은 도구가 도움이 될 수 있음) 실제로 수행하는 것은 매우 위험하며 문제가 발생하면 장치를 사용할 수 없게 되며 간단한 수정 방법이 없습니다.

이론적으로는 베어 드라이브를 직접 사용하는 것이 가능하지만 실제로는 다른 것이 파티션 테이블을 생성하는 데 "도움이 되어" 프로세스에서 데이터가 손상되는 상황에 직면하게 됩니다.

따라서 분할된 테이블을 갖는 것은 선택 사항이 아닙니다.

관련 정보