질문
내 Armbian 기반 Orange Pi 웹 서버가 충돌했습니다(아마도 정전으로 인해). ext4가 탄력성이 더 뛰어나고 과거에는 대개 그랬기 때문에 이것이 좋을 것이라고 생각했지만 이번에는 어떤 이유에서인지 재부팅하는 대신 그냥 멈췄습니다. 확인해 보니 "드라이브"(실제로는 메모리 카드)인 것으로 나타났습니다."유효한 파일 시스템이 없습니다".
카드를 빼내고 백업 이미지(카드 공간 32GB 중 4.5GB 정도)를 만들어 헥스에디터와 각종 프로그램에서 확인했습니다. 또한 메타데이터 값을 비교하기 위해 Armbian ISO를 동일한 메모리 카드에 구웠습니다.
나는 몇 년 전의 시스템 사본을 다른(동일한 카드가 아님)에 가지고 있지만 그 이후로 서버가 상당히 변경되었습니다. 적어도 비교를 위한 더 많은 정보를 제공할 수 있기를 바랍니다.
관찰 결과
몇 가지 문제를 발견했습니다.
대부분의 프로그램은 카드에 파일 시스템이 포함되어 있는지 감지할 수 없습니다. 아니요,,,
fsck등이testdisk작동하지 않습니다.bad magic number, 또는wrong fs type, bad option, bad superblock, or missing codepage,filesystem seems damaged또는bad relative sector, 또는 기타 차단 오류에 대해 불평합니다.슈퍼 블록이 손상되었습니다(그리고 백업을 찾을 수 없습니다). 대부분의 항목은 괜찮은 것 같지만 다음 항목에는 분명히 비정상적이거나 잘못된 값이 있습니다. 당연히 다를 수 있는 파티션 크기나 설치 횟수 등의 값을 무시하고 손상된 시스템의 값을 새 시스템과 비교했습니다. 물음표가 있는 기대값은 드라이브별로 확실하지 않은 값, 즉 잘못된 것인지 알 수 없는 값입니다.
| 대지 | 실제 값 | 기대값 |
|---|---|---|
| 그룹당 블록 수 | 0 | 32768 |
| 각 클립 그룹 | 0 | 32768 |
| 그룹당 인덱스 노드 수 | 5680 | ? 8160 |
| 최대 설치 수 | 0x7777 | 0xffff |
| 매직 시그니처 | 0x6753 | 0xef53 |
| 파일 시스템 상태 |
답변1
ext2/3/4 파일 시스템은 동일한 파일 시스템에 새로운 기능이 추가된 다양한 변형이므로 디스크 구조의 대부분이 동일합니다. 그렇기 때문에 파일 시스템의 세 가지 변형 모두 하나의 마법 값만 갖습니다. ext3의 새로운 주요 기능은 이며 has_journal, ext4에는 extents몇 가지 추가 기능이 추가되었습니다.
프로그램 사본을 얻기 위해 e2fsprogs 소스 코드(다른 시스템/카드)를 다운로드하고 빌드하는 것을 고려할 수 있습니다 findsuper. 파티션 테이블의 손상 여부에 관계없이 슈퍼블록에서 ext2/3/4 매직 값을 찾는 장치의 섹터 스캔을 수행합니다. 이는 각 파일 시스템이 있는 파티션의 시작 오프셋을 바이트 단위로 식별하여 파티션을 재구축/복원하는 데 도움이 될 수 있습니다.
답변2
논의된 바와 같이 ext/ext2/3/4는 매우 유사하며 다음에서 파생됩니다.초고속 파일 시스템/FFS(당신은 또한 볼 수 있습니다1그리고2) FFS(유닉스 최초의 파일 시스템)에 공통되는 아이노드, 블록, 포인터(간접 블록 등)를 기준으로 동일한 방식으로 데이터를 정렬합니다. Linux는 Unix의 파생물이며 ext는 몇 가지 추가 기능을 갖춘 FFS입니다. Linux 파일 시스템 API는 커널에 내장되어 있으며 모든 버전의 ext와 호환됩니다.
inode 테이블 재생성 측면에서 파일 시스템의 핵심은 각 파일의 데이터가 포함된 블록에 대한 포인터 목록입니다. 이 목록이 없으면 각 파일에 해당하는 블록만 추측할 수 있습니다. Ext4는 연속 블록을 할당하는 데 특히 좋습니다("다중 블록 할당" 또는 mballoc 기능이 포함되어 있습니다.) 따라서 이 추측은 아마도 괜찮을 것입니다. 그러나 조각화될 수 있는 대용량 파일의 경우 작업이 어려워지고 내가 아는 한 조각난 청크에서 파일을 재구성할 수 있는 알려진 도구가 없습니다. 나는 ext2가 연속된 블록을 할당하는 데 능숙하다는 점을 다시 강조합니다(주어진 파일의 블록은 거의 항상 서로 가깝습니다).여기에서 ext2/3/4의 하위 수준 구조에 대해 읽을 수 있습니다.. 조각화의 경우 블록을 직접 찾아야 하는데, 이는 대용량 파일의 경우 매우 어렵습니다. 파일이 클수록 조각화될 가능성이 높습니다.
메타데이터(각 파일에 해당하는 inode)는 데이터 자체만큼 중요합니다. 메타데이터가 없으면 데이터가 더 이상 존재하는 것으로 간주되지 않습니다. 비록 변경되지 않은 방식으로 디스크에 여전히 존재하더라도 엄밀히 말하면 데이터 블록은 다음에서 재구성될 수 없습니다. 따라서 inode 테이블이 없으면 큰 조각난 파일이 손실됩니다.
유일한 옵션은 데이터 조각 도구(PhotoRec 등)와 데이터 구성에 대한 자신만의 경험적 방법을 사용하는 것입니다. 이는 파일을 재구성하는 데 도움이 될 수 있습니다.
e2image메타데이터의 중요성과 그것이 얼마나 쉽게 손상될 수 있는지를 고려하여 전체 백업 크기의 일부인 메타데이터만 백업하도록 정기적으로 예약하는 것을 고려할 수 있습니다 . 물론 백업 후 파일 시스템이 변경되면 메타데이터는 관련성이 없게 됩니다.