OS 업그레이드 후 파일 시스템이 감지되지 않습니다. 디버깅 방법은 무엇입니까?

OS 업그레이드 후 파일 시스템이 감지되지 않습니다. 디버깅 방법은 무엇입니까?

두 개의 하드 드라이브가 있는 컴퓨터가 있습니다. 하나는 운영 체제와 기타 여러 가지 항목을 담고 있고, 다른 하나는 추가 테라바이트 저장 공간을 위한 덤프 공간으로 /media에 마운트되어 있습니다. 최근에 시스템을 Ubuntu Maverick에서 Debian Jessie로 업그레이드했습니다. 여기에는 호환되지 않는 여러 패키지를 제거하고 추가 설치가 포함되었으며, 재부팅할 때 하드 드라이브가 죽어가고 있을 수도 있습니다. .

해당 드라이브에는 완전히 중요한 것은 없지만 다시 구축하기보다는 검색하고 싶습니다. 게다가 문제를 덮어두고 계속 진행하기보다는 무엇이 잘못되었는지 알고 싶습니다. 그래서 제가 요청하는 것은 하드 드라이브 파일 시스템이 더 이상 인식되지 않는 이상한 하드 드라이브 오류를 디버깅하는 방법에 대한 조언입니다. 이 질문이 여기서 적절하지 않다면 사과드리며 더 나은 곳으로 안내하겠습니다!

업그레이드 전 기본 드라이브는 /dev/sda이고 보조 드라이브는 /dev/sdb였습니다. 이제 다음과 같이 나타납니다.

$ sudo parted -l
Model: ATA WDC WD1002FAEX-0 (scsi)
Disk /dev/sda: 1000GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 

Number  Start   End     Size    Type     File system  Flags
 1      32.3kB  1000GB  1000GB  primary


Model: ATA ST31000333AS (scsi)
Disk /dev/sdb: 1000GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 

Number  Start   End     Size    Type      File system     Flags
 1      1049kB  997GB   997GB   primary   ext4            boot
 2      997GB   1000GB  3143MB  extended
 5      997GB   1000GB  3143MB  logical   linux-swap(v1)

/dev/sdb의 파일 시스템이 올바르게 표시되며(대부분의 TB는 ext4, 부팅 가능한 파티션 및 3GB 스왑임) /dev/sda의 파티션은 대부분 정확할 가능성이 높습니다(이전에 설정하지 않았지만). 업그레이드) 파티션 테이블 덤프), 파일 시스템이 나열되지 않습니다.

fsck /dev/sda1을 시도하면 다음 오류가 발생합니다.

$ sudo fsck /dev/sda1
fsck from util-linux 2.25.2
e2fsck 1.42.12 (29-Aug-2014)
ext2fs_open2: Bad magic number in super-block
fsck.ext2: Superblock invalid, trying backup blocks...
fsck.ext2: Bad magic number in super-block while trying to open /dev/sda1

The superblock could not be read or does not describe a valid ext2/ext3/ext4
filesystem.  If the device is valid and it really contains an ext2/ext3/ext4
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>
 or
    e2fsck -b 32768 <device>

가능한 슈퍼블록 옵션 목록에서는 유용한 결과가 나오지 않았지만 파티션 테이블 오프셋이 있는지 궁금합니다. 유효한 슈퍼블록을 검색할 수 있는 방법이 있나요?

또한 이것이 ext3/ext4 파일 시스템인지 100% 확신할 수 없습니다. 다른 파일 시스템을 사용하고 있을 수도 있지만 무엇인지 모르겠습니다. 추가 파일 시스템 드라이버를 설치할 수 있도록 파티션을 탐색하고 파티션이 무엇을 사용할지 알아낼 수 있는 방법이 있습니까?

어떤 조언이라도 도움이 될 것입니다. 감사해요!

편집: doktor5000은 testdisk를 잡고 내용을 확인하라고 제안했습니다.

Disk /dev/sda - 1000 GB / 931 GiB - CHS 121601 255 63
Current partition structure:
     Partition                  Start        End    Size in sectors

No ext2, JFS, Reiser, cramfs or XFS marker
 1 P Linux                    0   1  1 121600 254 63 1953520002
 1 P Linux                    0   1  1 121600 254 63 1953520002
No partition is bootable

"빠른 검색"을 선택하면 다음과 같은 결과가 나타납니다.

Disk /dev/sda - 1000 GB / 931 GiB - CHS 121601 255 63
     Partition               Start        End    Size in sectors
>* Linux                    0  32 33 118619 237 18 1905627136
 P Linux Swap           118620  14 51 121601  57 56   47892480

fdisk가 이전에 말한 내용을 인용하는 것을 잊어버렸으므로 다음과 같습니다.

$ sudo fdisk /dev/sda -l

Disk /dev/sda: 931.5 GiB, 1000204886016 bytes, 1953525168 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
Disklabel type: dos
Disk identifier: 0x000a56a5

Device     Boot Start        End    Sectors   Size Id Type
/dev/sda1          63 1953520064 1953520002 931.5G 83 Linux

따라서 내가 본 차이점은 다음과 같습니다. fdisk는 파티션이 63에서 시작한다고 생각하지만 testdisk는 32라고 말합니다(제 생각에는). testdisk는 거기에 스왑 파티션이 있다고 말합니다. 이는 나에게 이해가 되지 않습니다(보조 드라이브입니다. 왜 스왑 공간을 할당해야 하는지 모르겠습니다). 하지만 멋지네요. 파일 시스템을 자세히 살펴보고 파일을 복사할 수 있습니다! 이것은 내가 마지막으로 디스크 복구를 시도했을 때 겪었던 것과 비교하면 굉장합니다. 하지만 그것은 1990년대 OS/2에서였기 때문에 놀라운 일이 아닙니다. :)

나는 testdisk가 새 파티션 테이블을 작성하도록 할 만큼 자신감이 있습니다. 예! 모든 데이터가 있고 읽을 수 있으며 드라이브가 제대로 작동하는 것 같습니다. doktor5000님, 정말 감사합니다! 그럼 후속 질문입니다. 파티션 테이블이 어떻게 손상되었는지 아시나요?

답변1

가장 확실한 방법은 다음을 통해 파티션을 심층적으로 검색하는 것입니다.테스트 디스크.
그들의 모습을 봐실행 방법에 대한 일반적인 지침그리고/또는단계별 문서

그런 다음 testdisk에서 찾은 파티션 테이블을 현재 아무것도 변경하지 않고 표시되는 것과 비교하고 여기에 게시할 수도 있습니다.

적어도 ext2/3/4에 대한 또 다른 옵션은 다음을 사용하는 것입니다.디버그 명령그러나 이것은 훨씬 더 복잡하고 testdisk만큼 간단하지 않습니다.

어떤 경우든 해당 디스크의 콘텐츠를 복구하려면 더 많은 데이터가 손실될 위험이 없도록 해당 디스크에서 이미지를 만들고 해당 이미지로만 작업하는 것이 좋습니다. 바라보다실패한 드라이브의 데이터 저장이를 수행하는 방법에 대한 몇 가지 제안.

관련 정보