파일이 이상하게도 비어 있습니다. 복구 옵션?

파일이 이상하게도 비어 있습니다. 복구 옵션?

삭제된 파일 복구에 대한 여러 게시물을 보았지만 이번에는 상황이 다릅니다. 내 아내는 우리 아이들에 대한 특별한 추억과 같은 중요한 개인 정보를 많이 담고 있는 Journal.odt라는 파일을 가지고 있습니다. 어느 날 그녀가 OpenOffice에서 파일을 열려고 했을 때 포맷 문제에 대해 불평했습니다. 나는 그녀에게 클릭을 해제하고 종료하라고 요청했습니다. 내 cat파일이 완전히 비어있을 때. ls파일이 0바이트라고 합니다.

실수로 파일의 모든 텍스트를 선택하고 백스페이스 키를 누른 다음 저장해도 파일에는 여전히 OpenOffice 메타정보가 포함됩니다.

나는 할 일이 생각날 때까지 디스크에 더 이상의 변경이 발생하지 않도록 즉시 그녀의 노트북을 종료했습니다.

과거에 dd디스크에서 원시 텍스트 복구를 사용하는 것과 같은 몇 가지 복잡한 작업을 수행했지만 여기서 무엇을 해야 할지 모르겠습니다. odt 파일은 일반 텍스트가 아니기 때문에 grep을 통해 전체 디스크를 파이프할 수는 없습니다.

어떤 조언이라도 대단히 감사하겠습니다.

또한 무엇이 잘못될 수 있는지에 대한 통찰력을 갖고 있는 사람이 있다면 듣고 싶습니다.

감사해요

답변1

ext3 파일 시스템을 사용하는 경우 다음을 시도해 보십시오.Carol Wood의 HOWTO

요컨대,

  • ext3grep $IMAGE --ls --inode 2 | grep your_file찾고 있는 파일을 찾으 려면 ( $IMAGE예: 파티션은 어디에 있습니까 /dev/sda2?ext3grep)
  • 할당되지 않은 공간의 로그가 포함된 파일 시스템 블록을 찾습니다.
  • 이전에 발견된 블록을 참조하는 모든 로그 설명자를 찾습니다.
  • 블록을 복사합니다 dd.
  • 파일을 편집하여 뒤에 오는 0을 제거하십시오.
  • cat원하는 위치에 파일을 배치하세요.

출처에서:

》챕터 매뉴얼 복구 예시

아래 예에서는 작은 파일을 수동으로 복원합니다. 공간을 절약하고 예제를 더 읽기 쉽게 만들기 위해 부분 출력만 제공됩니다.

ext3grep $IMAGE --ls --inode를 사용하여 복구할 파일 이름을 찾습니다.

$ ext3grep $IMAGE --ls --inode 2 | grep carlo 3 end d 195457 D 1202352103 Thu Feb 7 03:41:43 2008 drwxr-xr-x carlo

$ ext3grep $IMAGE --ls --inode 195457 | grep 'bin$'|head -n 1 34 35 d 309540 D 1202352104 Thu Feb 7 03:41:44 2008 drwxr-xr-x bin

$ ext3grep $IMAGE --ls --inode 309540 | grep start_azureus 9 10 r 309631 D 1202351093 Thu Feb 7 03:24:53 2008 rrwxr-xr-x start_azureus

분명히 inode 309631이 삭제되었으며 파일의 블록 번호가 없습니다.

$ ext3grep $IMAGE --print --inode 309631 [...] Inode 할당되지 않은 그룹: 19 생성 ID: 2771183319 uid/gid: 1000/1000 모드: rrwxr-xr-x 크기: 0 링크 수: 0 섹터: 0 ( --> 0개의 간접 블록).

Inode 시간: 접속: 1202350961 = 2008년 2월 7일 목요일 03:22:41 파일 수정: 1202351093 = 2008년 2월 7일 목요일 03:24:53 Inode 수정: 1202351093 = 2008년 2월 7일 목요일 03:24:53 삭제시간 : 12023510 93 = 2008년 2월 7일 목요일 03:24:53

직접 차단:

그러므로 우리는 일지에서 그보다 오래된 사본을 찾으려고 노력할 것입니다. 먼저 해당 inode가 포함된 파일 시스템 블록을 찾습니다.

$ ext3grep $IMAGE --inode to block 309631 | grep은 Inode 309631에 있으며 블록 622598의 오프셋 0xf00에 있습니다.

그런 다음 블록 622598을 참조하는 모든 로그 설명자를 찾습니다.

$ ext3grep $IMAGE --journal --block 622598 [...] 블록 622598의 저널 설명자 인용: 4381294 26582 4381311 28693 4381313 28809 4381314 28814 4381321 29308 4381348 3 067 6 4381349 30986 4381350 31299 4381374 32718 4381707 1465 4381709 2132 4381755 2945 4381961 4606 4382098 6073 4382137 6672 4382138 7536 4382139 7984 4382140 8931

이는 시퀀스 번호 4381294의 트랜잭션에 블록 26582에 블록 622598의 복사본이 있다는 것을 의미합니다. 맨 아래에 있는 가장 높은 시퀀스 번호는 디스크에 기록된 마지막 데이터여야 하므로 블록 8931은 현재 블록 622598과 동일해야 합니다. 삭제되지 않은 마지막 복사본을 찾으려면 맨 아래부터 시작하여 위쪽으로 작업해야 합니다.

이러한 블록을 인쇄하려고 하면 ext3grep은 이를 inode 테이블의 블록으로 인식하고 그 안에 있는 32개 inode의 내용을 모두 인쇄합니다. 그러나 우리는 inode 309631만 보고 싶기 때문에 smart grep을 사용합니다.

$ ext3grep $IMAGE --print --block 8931 | $ ext3grep $IMAGE --print --block 8931 | $ ext3grep $IMAGE --print --block 8931 grep -A15 'Inode 309631' -------- ------Inode 309631--------- 생성 ID: 2771183319 uid / gid: 1000 / 1000 모드: rrwxr-xr-x 크기: 0 링크 수: 0 섹터: 0(--> 0 간접 블록).

Inode 시간: 접속: 1202350961 = 2008년 2월 7일 목요일 03:22:41 파일 수정: 1202351093 = 2008년 2월 7일 목요일 03:24:53 Inode 수정: 1202351093 = 2008년 2월 7일 목요일 03:24:53 삭제시간 : 12023510 93 = 2008년 2월 7일 목요일 03:24:53

직접 차단:

이는 실제로 블록 622598에서 본 것과 동일합니다. 다음으로 삭제 시간이 0인 일련 번호를 찾을 때까지 더 작은 일련 번호를 살펴봅니다. 우리가 찾은 첫 번째 것(아래에서 위로)은 블록 6073입니다:

$ ext3grep $IMAGE --print --block 6073 | $ ext3grep $IMAGE --print --block 6073 | $ ext3grep $IMAGE --print --block 6073 grep -A15 'Inode 309631' -------- ------Inode 309631--------- 생성 ID: 2771183319 uid / gid: 1000 / 1000 모드: rrwxr-xr-x 크기: 40 링크 수: 1 섹터: 8(--> 0 간접 블록).

Inode 시간: 접속: 1202350961 = 2008년 2월 7일 목요일 03:22:41 파일 수정: 1189688692 = 2007년 9월 13일 목요일 15:04:52 2007 Inode 수정: 1189688692 = 2007년 9월 13일 목요일 15:04:52 삭제 시간: 0

직접 차단: 645627

위의 작업은 자동화되어 있으며 명령줄 옵션 --show-journal-inodes를 사용하여 더 빠르게 수행할 수 있습니다. 이 옵션은 inode가 속한 블록을 찾은 다음 로그에서 해당 블록의 모든 복사본을 찾은 다음 각 블록에서 요청된 inode만 인쇄합니다(아시다시피 각 블록에는 32개의 inode가 포함되어 있음). 중복 항목은 제거됩니다.

$ ext3grep $IMAGE --show-journal-inodes 309631 그룹 수: 75 최소/최대 로그 블록: 1115/35026 로그 설명자 로드 중... 완료된 로그 트랜잭션 4381435 랩어라운드, 일부 데이터 블록이 이 트랜잭션에서 손실되었을 수 있습니다. 로그 설명자 수: 30258, 최소/최대 시퀀스 번호: 4379495 / 4382264 로그에서 발견된 inode 309631의 복사본:

---------------Inode 309631--------------- 생성 ID: 2771183319 uid / gid : 1000 / 1000 모드: rrwxr-xr-x 크기: 0 링크 수: 0 섹터: 0 (--> 0 간접 블록).

Inode 시간: 접속: 1202350961 = 2008년 2월 7일 목요일 03:22:41 파일 수정: 1202351093 = 2008년 2월 7일 목요일 03:24:53 Inode 수정: 1202351093 = 2008년 2월 7일 목요일 03:24:53 삭제시간 : 12023510 93 = 2008년 2월 7일 목요일 03:24:53

직접 차단:

---------------Inode 309631--------------- 생성 ID: 2771183319 uid / gid : 1000 / 1000 모드: rrwxr-xr-x 크기: 40 링크 수: 1 섹터: 8 (--> 0 간접 블록).

Inode 시간: 접속: 1202350961 = 2008년 2월 7일 목요일 03:22:41 파일 수정: 1189688692 = 2007년 9월 13일 목요일 15:04:52 2007 Inode 수정: 1189688692 = 2007년 9월 13일 목요일 15:04:52 삭제 시간: 0

직접 차단: 645627

파일은 정말 작습니다. 블록이 하나뿐입니다. 이전에 표시된 대로 dd를 사용하여 이 블록을 복사합니다.

$ dd if=$IMAGE bs=4096 count=1 Skip=645627 of=block.645627 1+0 레코드 중 1+0 복사됨 4096바이트(4.1kB), 0.0166104초, 247kB/s

그런 다음 파일을 편집하여 뒤에 오는 0을 제거하거나 처음 40바이트(주어진 파일 크기)를 복사합니다.

$ dd if=block.645627 bs=1 count=40 of=start_azureus 40+0개 레코드 중 40+0개 레코드가 복사됩니다. 40바이트(40B), 0.000105397초, 380kB/s

$ cat start_azureus cd /usr/src/azureus/azureus ./azureus &

회복되었습니다! "

답변2

노력하다테스트 디스크 및 photorec, 그러나 귀하의 글을 제가 이해하는 방식은 정기적인 백업의 가치를 배우는 것이 어려운 방법일 수 있다는 것입니다. 또한 하드 드라이브에 대한 추가 변경을 방지하기 위해 CD에서 부팅할 수도 있습니다. 나는 개인적으로 좋아한다시스템 복구 디스크하지만 대부분 명령줄 기반입니다.

답변3

디지털 포렌식을 위한 특수 Linux 배포판인 Caine을 사용하세요. 파일 및 하드 드라이브 복구를 위한 다양한 도구가 있습니다.

관련 정보