덮어 쓴 파일을 복구 할 수 있습니까?

삭제 된 파일을 복구하는 것이 아니라 덮어 쓴 파일 에 대해 이야기하고 있습니다. 즉, 다음 방법으로

# move
mv new_file old_file

# copy
cp new_file old_file

# edit
vi existing_file
> D
> i new_content
> :x

리눅스 머신에 특별한 프로그램이 설치되어 있지 않다고 가정 할 때 위의 3 가지 동작 중 하나라도 수행된다면 어떤 것도 검색 할 수 있습니까?

대답은 "그렇습니다. 그러나 파일 시스템 유형 및 타이밍에 따라 다릅니다."

이 세 가지 예제 중 어느 것도 우연히 제외하고 old_file 또는 existing_file의 물리적 데이터 블록을 덮어 쓰지 않습니다.

• mv new_file old_file. 그러면 old_file이 연결 해제됩니다. old_file에 대한 추가 하드 링크가 있으면 나머지 링크에서 블록이 변경되지 않습니다. 그렇지 않으면 블록은 일반적으로 사용 가능한 목록에 배치됩니다 (파일 시스템 유형에 따라 다름). 그런 다음 mv복사 가 필요한 경우 (디렉토리 항목 이동과 반대) 새 블록이 mv쓰기 로 할당됩니다 .

  새로 할당 된 이러한 블록 은 방금 해제 된 블록 과 동일하거나 아닐 수 있습니다 . UFS 와 같은 파일 시스템에서는 가능한 경우 파일이 작성된 디렉토리와 동일한 실린더 그룹에서 블록이 할당됩니다. 따라서 디렉토리에서 파일을 링크 해제하고 동일한 디렉토리에 파일을 작성할 가능성이 있습니다 ( 덮어 쓰기) 방금 해제 된 동일한 블록 중 일부. 따라서 실수로 파일을 제거하는 사람들에게 표준 조언은 누군가 파일 복구를 시도 할 때까지 디렉토리 트리의 파일에 새 데이터를 쓰지 않는 것이 좋습니다 (전체 파일 시스템이 아닌 것이 좋습니다).

• cp new_file old_file다음을 수행합니다 ( strace시스템 호출을 보는 데 사용할 수 있음 ).

  open ( "old_file", O_WRONLY | O_TRUNC) = 4

  O_TRUNC 플래그는 mv위에서 와 같이 모든 데이터 블록이 해제되도록합니다 . 위와 같이, 이들은 일반적으로 사용 가능 목록에 추가되며 cp명령에 의해 수행 된 후속 쓰기에 의해 재사용되거나 재사용되지 않을 수 있습니다 .

• vi existing_file. 경우 vi실제로 vim는 :x명령은 다음을 수행합니다

  unlink ( "existing_file ~") = -1 ENOENT (파일 또는 디렉토리가 없음)

  rename ( "existing_file", "existing_file ~") = 0

  open ( "existing_file", O_WRONLY | O_CREAT | O_TRUNC, 0664) = 3

  따라서 이전 데이터를 제거하지도 않습니다. 데이터는 백업 파일에 보존됩니다.

  FreeBSD에서는 vidoes open("existing_file",O_WRONLY|O_CREAT|O_TRUNC, 0664)와 같은 의미를 갖습니다 cp.

특별한 프로그램없이 일부 또는 모든 데이터를 복구 할 수 있습니다. 필요한 것은 grep및 dd이며 원시 장치에 대한 액세스입니다.

작은 텍스트 파일의 경우 링크 된 질문 에서 @Steven Dgrep 의 답변에 단일 명령 이 가장 쉬운 방법입니다.

grep -i -a -B100 -A100 'text in the deleted file' /dev/sda1

그러나 연속되지 않은 여러 블록에있을 수있는 더 큰 파일의 경우 다음과 같이하십시오.

grep -a -b "text in the deleted file" /dev/sda1
13813610612:this is some text in the deleted file

일치하는 줄의 오프셋을 바이트 단위로 제공합니다. 다음으로 dd시작 하는 일련의 명령으로이를 수행하십시오.

dd if=/dev/sda1 count=1 skip=$(expr 13813610612 / 512)

또한 해당 블록 전후에 일부 블록을 읽으려고합니다. UFS에서 파일 블록은 일반적으로 8KB이며 일반적으로 상당히 연속적으로 할당됩니다. 단일 파일 블록은 다른 파일 또는 여유 공간의 8KB 블록과 교대로 인터리브됩니다. UFS에서 파일의 꼬리는 최대 7 개의 1KB 조각으로, 인접하거나 인접하지 않을 수 있습니다.

물론, 데이터를 압축하거나 암호화하는 파일 시스템에서 복구는 간단하지 않을 수 있습니다.

Unix에는 실제로 기존 파일의 데이터 블록을 덮어 쓰는 유틸리티가 거의 없습니다. 생각 나는 것은 dd conv=notrunc입니다. 다른 하나는 shred입니다.

나는 (거대한 별표로) 아니오라고 말할 것입니다.

디스크에 데이터가 배치되는 방식에 대해 생각하십시오. 데이터를 포함하고 다음 블록을 가리키는 블록이 있습니다 (있는 경우).

데이터를 덮어 쓰면 블록 내용이 변경됩니다 (그리고 파일을 모든 끝 마커로 확장하는 경우). 아무것도 그래서 해야 복구 할 수 없습니다 (아래 참조).

파일을 줄이면 이전 블록을 잃어 버리고 곧 재활용됩니다. 프로그래머라면 자유 / 삭제를하지 않고 목록의 절반을 "잃어버린"링크 된 목록을 생각해보십시오. 그 데이터는 여전히 존재하지만 행운을 빕니다.

생각하기에 흥미로운 것은 단편화입니다.

디스크에 인접하지 않은 데이터의 "구멍"이있는 경우 조각화가 발생합니다. 이는 파일을 확장하거나 축소하여 더 이상 디스크의 원래 위치에 맞지 않도록 파일을 수정하여 발생할 수 있습니다.

파일이 원래 크기보다 커질 경우 (이 시점에서 이동해야 함) 파일 시스템에 따라 전체 파일을 기존 데이터가 여전히 존재하는 새로운 위치에 복사 할 수 있습니다 (그러나 무료로 표시됨) 또는 이전 끝 포인터를 변경하고 새 위치를 가리 키도록합니다 (이로 인해 스 래싱이 발생 함).

간단히 말해, 데이터가 손실 될 수 있습니다 (현미경으로 보는 극단적 인 법의학 과정을 거치지 않고). 그러나 여전히있을 가능성이 있습니다.

/ var / tmp 또는 다른 곳에 충분한 디스크 공간이 있는지 확인하십시오.

시험

 grep -i -a -B100 -A100 'a string unique to your file' /dev/sda1 |
 strings > /var/tmp/my-recovered-file

여기서 / dev / sda1은 시스템의 디스크입니다.

그런 다음 내 복구 파일을 검색하여 문자열을 찾으십시오.

그것은 수도 당신이 누락 linespaces, 브라켓, sysmbols 등을 확인 찾을 경우 대부분이있을 수

파일에서 데이터의 양을 줄이려면 상당히 치명적이지 않거나 문자열 인 파일에서 검색 단어를 사용하십시오. "echo"와 같은 단어를 검색하면 시스템에 단어 echo가 포함 된 파일이 많으므로 많은 문자열을 다시 얻을 수 있습니다.

나는 12 시간 분량의 테스트 데이터로 텍스트 파일 (VQ1.txt)을 덮어 썼습니다. 목록에 VQ1.txt ~ 내 '손실'데이터가있는 것을 보여줍니다!

$ cat VQ1.txt~  
Start time at: Thu Apr  2 18:07:23 PDT 2015
User, KW: 12hrFA_OEM_HelloVoiceQ
Test Case: 
Detection:  1, 1, 04-03 01:07:00.673 D/MultiKeywordBdctReceiver( 1743): vs status 258 : 2 : 1
Detection:  2, 1, 04-03 01:09:04.813 D/MultiKeywordBdctReceiver( 1743): vs status 258 : 2 : 1
Detection:  3, 1, 04-03 04:09:26.023 D/MultiKeywordBdctReceiver( 1743): vs status 258 : 2 : 1
Detection:  4, 1, 04-03 04:11:29.893 D/MultiKeywordBdctReceiver( 1743): vs status 258 : 2 : 1
Detection:  5, 1, 04-03 07:12:27.013 D/MultiKeywordBdctReceiver( 1743): vs status 258 : 2 : 1
Detection:  6, 1, 04-03 07:14:30.803 D/MultiKeywordBdctReceiver( 1743): vs status 258 : 2 : 1
Detection:  7, 1, 04-03 08:37:13.113 D/MultiKeywordBdctReceiver( 1743): vs status 258 : 2 : 1
Detection:  8, 1, 04-03 10:21:23.533 D/MultiKeywordBdctReceiver( 1743): vs status 258 : 2 : 1
Detection:  9, 1, 04-03 10:23:27.733 D/MultiKeywordBdctReceiver( 1743): vs status 258 : 2 : 1
Detection:  10, 1, 04-03 13:23:47.893 D/MultiKeywordBdctReceiver( 1743): vs status 258 : 2 : 1
Detection:  11, 1, 04-03 13:25:52.203 D/MultiKeywordBdctReceiver( 1743): vs status 258 : 2 : 1

12hrFA_OEM_HelloVoiceQ,  
KW detect count: 11

TL; DR-덮어 쓴 파일이 실행중인 프로세스에 의해 계속 열려 있으면이 블로그 게시물이 베이컨을 저장할 수 있습니다.

https://www.linux.com/news/bring-back-deleted-files-lsof/

그것에서 삭제 된 파일 에 대해 이야기 하지만 rsync로 덮어 쓴 파일조차도 행운을 빕니다. 그리고 4MB로 덮어 쓴 60GB 파일에 대해 이야기하고 있으며 운 좋게도 열린 상태로 실행중인 프로세스를 중단하지 않았기 때문에 원본을 복구 할 수있었습니다.