gparted live 내부에서 파티션 크기를 조정하는 동안 커널이 GPF에 도달하여 머신을 재부팅해야 했습니다. (여기에 dmesg를 입력하세요.https://pastebin.com/LGqXA3p9). 공교롭게도 이동 중인 파티션은 md RAID5 어레이에 있었고 시스템 부팅과 전혀 관련이 없었습니다. 즉, 백업 및 실행 중이며 좀 더 살펴볼 수 있다는 의미입니다.
dumpef2s를 실행하면 'dumpe2fs: 저널 슈퍼 블록을 읽는 동안 손상된 익스텐트 헤더'가 생성되고 fsck.ext4에는 "수퍼 블록에 잘못된 저널(inode 8)이 있습니다."라는 메시지가 표시됩니다. 저는 아직 그것을 클리어하지 못했습니다. testdisk는 새 파티션만 볼 수 있고 파일은 볼 수 없습니다. Photorec은 그만한 가치가 있는 것보다 더 번거로울 것입니다. Testdisk는 이동된 파일의 절반만 표시하고 그 외에는 아무것도 표시하지 않습니다.
resize2fs 도구의 마지막 메시지는 "node 279256 / 593596231"였는데, 어떻게 해석해야 할지 모르겠습니다. 이동되지 않은 파일 시스템 데이터를 활용할 수 있는 방법이 있습니까?
답변1
표면 아래를 파헤친 후 운이 좋았습니다. r-studio라는 (독점) 도구가 파일 시스템 슈퍼 블록을 발견했습니다. e2image는 아직 원래 파일 시스템을 덮어쓰지 않았습니다. 섹터 번호로 무장하여 데이터 손실이 전혀 없는 기존 파티션을 간단히 다시 만들 수 있었습니다. 나는 아직 가지고 있는 UUID를 찾기 위해 볼륨을 탐색하는 중이었습니다. 이는 대략 동일한 접근 방식이지만 앞서 언급한 도구와 비교하여 수동으로 수행되었습니다. 말할 필요도 없이 파일 시스템 메타 데이터의 e2image 백업을 만들었고 gparted가 실패한 이유를 조사할 것입니다.