Windows 컴퓨터의 SMB 공유에서 폴더를 삭제했습니다. 확인 제로로 인해 전체 폴더가 삭제되었습니다. 처음으로 달리다사진술마지막으로 복사한 파일을 제외한 대부분의 파일을 추출했습니다. 1. 추가 테스트확장 삭제4~5개의 파일을 제외한 전체 폴더를 가져올 수 있습니다. 그러나 가장 중요한 파일은 복구되지 않았습니다. 아이노드를 보면 복구된 파일에 연속된 아이노드가 있는 것을 알 수 있습니다. 그래서 정확한 아이노드 범위를 좁힐 수 있었습니다. 하지만 해당 특정 인덱스 노드를 복원하려고 하면 다음 메시지가 나타납니다.
Loading filesystem metadata ... 59613 groups loaded.
Loading journal descriptors ... 29932 descriptors loaded.
Unable to restore inode 60596808 (file.60596808): No undeleted copies found in the journal.
그러나 해당 inode를 검색하면 다음과 같은 데이터를 얻습니다.
Loading filesystem metadata ... 59613 groups loaded.
Group: 14794
Contents of inode 60596809:
0000 | e4 81 e8 03 dd df b2 1b 43 2d 08 5d 53 2d 08 5d | ........C-.]S-.]
0010 | fd 97 05 5d 53 2d 08 5d e8 03 00 00 00 00 00 00 | ...]S-.]........
0020 | 00 00 08 00 01 00 00 00 0a f3 00 00 04 00 00 00 | ................
0030 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
0040 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
0050 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
0060 | 00 00 00 00 70 57 ff 3f 00 00 00 00 00 00 00 00 | ....pW.?........
0070 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
0080 | 20 00 00 00 ec e9 88 2a b0 16 cf 0f 1c 76 bb a2 | ......*.....v..
0090 | 3c 2d 08 5d d4 64 6c a9 00 00 00 00 00 00 00 00 | <-.].dl.........
00a0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
00b0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
00c0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
00d0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
00e0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
00f0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
Inode is Unallocated
File mode: 33252
Low 16 bits of Owner Uid: 1000
Size in bytes: 464707549
Access time: 1560816963
Creation time: 1560816979
Modification time: 1560647677
Deletion Time: 1560816979
Low 16 bits of Group Id: 1000
Links count: 0
Blocks count: 0
File flags: 524288
File version (for NFS): 1073698672
File ACL: 0
Directory ACL: 0
Fragment address: 0
Direct blocks: 62218, 4, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
Indirect block: 0
Double indirect block: 0
Triple indirect block: 0
사용디버그 파일나는 inode를 덤프하려고 시도했지만 내가 얻은 것은 올바른 크기이지만 0인 파일뿐이었습니다.
크기(바이트), 날짜, 이것이 내가 필요한 정확한 inode 파일이라고 99% 확신합니다. 이 데이터는 기본적으로 디스크의 정확한 위치에 대한 포인터가 누락된 스텁입니까? 이 inode 데이터를 사용하여 실제 데이터를 복구할 수 있는 방법이 있습니까?
답변1
바라보다https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout#The_Contents_of_inode.i_block
"파일 플래그: 524288"의 16진수 값은 0x80000이므로 "extents" 플래그입니다. 따라서 블록을 직접/간접/이중 간접/삼중 간접 블록 포인터로 extundelete해석했지만 이는 잘못된 것입니다. inode.i하지만 우리는 여전히 그것을 스스로 해독할 수 있습니다.
"직접 블록" 필드의 첫 번째 숫자는 62218이며 이는 0xF30A 16진수입니다. eh_magic이는 범위 트리 모드( )의 매직 번호로 "파일 플래그" 값을 확인합니다. 이전 스타일의 블록 포인터는 리틀 엔디안 32비트이지만 범위 모드 매직 넘버는 16비트이므로 이 eh_entries필드가 첫 번째 "직접 블록" 번호의 일부로 나타날 것이라는 것을 알고 있습니다. 표시된 매직 넘버를 손상시키지 않으므로 eh_entries0이어야 합니다.
마찬가지로 "직접 블록"의 두 번째 숫자는 4이며, 이는 두 개의 16비트 숫자(0은 4, eh_max0은 0) 로 디코딩됩니다 eh_depth. 블록의 나머지 부분은 inode.i0으로 보입니다.
inode.i범위 모드에 따라 해석되는 블록의 내용은 다음과 같습니다.
eh_magic= 62218, 맞습니다.eh_entries= 0, 헤더 뒤에 유효한 항목이 없습니다.eh_max= 4, 최대 4개 항목inode.i.eh_depth= 0, 익스텐트 노드는 데이터 블록을 직접 가리킵니다.eh_generation= 0 (표준은 사용되지 않음ext4)
나머지는 모두 0이므로 여기에는 유효한 노드 도 inode.i없고 확인 값도 0이다.struct ext4_extentstruct ext4_extent_idxeh_entries
따라서 불행하게도 범위 테이블은 삭제 작업의 일부로 0으로 지워진 것으로 보이며 디스크의 파일 블록 위치를 나타내는 실제 포인터는 사라진 것입니다. 그래서 당신 말이 맞습니다. 이것은 실제로 단지 스텁입니다.