유닉스 / 리눅스 삭제 된 파일 삭제 / 복구

124

삭제 된 파일을 복구 / 삭제 취소하는 명령이 rm있습니까?

$ rm -rf /path/to/myfile

어떻게 복구 할 수 myfile있습니까? 그러한 도구가 있다면 어떻게 사용할 수 있습니까?

linux data-recovery deleted-files

— pylover
소스

1

cyberciti.biz/tips/… 가 도움이 될 수 있습니다. 또한 스택 교환 에서 더 좋습니다 .

— fedorqui

1. 이것은 유닉스와 리눅스에 더 좋을 것입니다 . 2. 백업?

1

어떤 작업을 수행하기 전에 파일 시스템을 읽기 전용으로 마운트하여 데이터를 덮어 쓰지 않도록하십시오. 또한이 게시물 ( superuser.com/questions/170857/ext4-undelete-utilities)을 살펴보십시오 .

1

@EvanTeitelman 당신은 파일을 마운트 해제하는 동안 파일을 복구하려고 시도하는 것보다 읽기 전용 다시 마운트하는 것이 낫다는 것을 의미합니까? BTW, midnightcommander (MC) 방법은 제안 언 마운트 datarecoverypros.com/recover-linux-midnightcommander.html

— 물병 전원

1

최선의 해결책은 미리 생각하고 개정 관리 도구를 사용하는 것입니다.

— ctrl-alt-delor

66

댓글에 제공된 사람의 링크가 가장 가능성이 높습니다.

리눅스 debugfs 해킹 : 파일 삭제 취소

약간의 협박으로 보이지만 그 글은 실제로 매우 간단합니다. 일반적으로 단계는 다음과 같습니다.

파일 시스템 로그를 보려면 debugfs를 사용하십시오.
```
$ debugfs -w /dev/mapper/wks01-root
```
debugfs 프롬프트에서
```
debugfs: lsdel
```

샘플 출력

Inode  Owner  Mode    Size    Blocks   Time deleted
23601299      0 120777      3    1/   1 Tue Mar 13 16:17:30 2012
7536655      0 120777      3    1/   1 Tue May  1 06:21:22 2012
2 deleted inodes found.

debugfs에서 명령을 실행하십시오.
```
debugfs: logdump -i <7536655>
```

파일 inode 결정

...
...
....
output truncated
    Fast_link_dest: bin
    Blocks:  (0+1): 7235938
  FS block 7536642 logged at sequence 38402086, journal block 26711
    (inode block for inode 7536655):
    Inode: 7536655   Type: symlink        Mode:  0777   Flags: 0x0   Generation: 3532221116
    User:     0   Group:     0   Size: 3
    File ACL: 0    Directory ACL: 0
    Links: 0   Blockcount: 0
    Fragment:  Address: 0    Number: 0    Size: 0
    ctime: 0x4f9fc732 -- Tue May  1 06:21:22 2012
    atime: 0x4f9fc730 -- Tue May  1 06:21:20 2012
    mtime: 0x4f9fc72f -- Tue May  1 06:21:19 2012
    dtime: 0x4f9fc732 -- Tue May  1 06:21:22 2012
    Fast_link_dest: bin
    Blocks:  (0+1): 7235938
No magic number at block 28053: end of journal.

위의 inode 정보로 다음 명령을 실행하십시오.

# dd if=/dev/mapper/wks01-root of=recovered.file.001 bs=4096 count=1 skip=7235938
# file recovered.file.001
file: ASCII text, with very long lines

파일이에 복구되었습니다 recovered.file.001.

다른 옵션

위의 방법이 아닌 경우 photorec과거에 파일을 복구 하는 등의 도구를 사용 했지만 이미지 파일에만 적합합니다. 나는이 기사에서 내 블로그 에이 방법에 대해 광범위하게 썼다 :

어떻게 페도라 / CentOS는 / RHEL에 디지털 카메라의 SDD 카드에서 손상된 JPEG 및 MOV 파일을 복구하는 방법 .

— slm
소스

11

나는 시도 debugfs -w /dev/sdb2했지만 lsdelsais :0 deleted inodes found.

— rubo77

5

extundeleteext3 / 4를 사용하는 것이 더 쉽고 아마도 같은 결과를 가져올 것입니다.

— eadmaster 2016 년

1

이것은 파일을 복구하는 데 효과적이지만 @ y U T6 Ԝ * e 0 v' T 0 <#selinuxsystem_u : object_r : rpm_var_lib_t를 받았습니다. s0 } y U T6 ..... conv = ascii, conv = ibm 및 conv = ebcdic를 시도하면 동일한 문제가 발생 함

— codyc4321

2

lsdel : 파일 시스템이 열리지 않습니다. 어떻게 해결합니까?

— Amitābha

3

내가 얻을 /dev/mapper/wks01-root: No such file or directory while opening filesystem곳이셨어요 /dev/mapper/wks01-root에서?

— Marko Avlijaš

29

약간의 기회로 때로는이 스크립트 또는 다음 솔루션으로 삭제 된 파일을 복구 할 수 있습니다.

#!/bin/bash

if [[ ! $1 ]]; then
    echo -e "Usage:\n\n\t$0 'file name'"
    exit 1
fi

f=$(ls 2>/dev/null -l /proc/*/fd/* | fgrep "$1 (deleted" | awk '{print $9}')

if [[ $f ]]; then
    echo "fd $f found..."
    cp -v "$f" "$1"
else
    echo >&2 "No fd found..."
    exit 2
fi

삭제 된 파일의 패턴을 알고있는 경우 alt+ sys+ resuo를 입력 하여 읽기 전용으로 재부팅하고 다시 마운트 한 다음 live-cd를 사용 grep하여 하드 드라이브에서 검색 하는 또 다른 유용한 트릭 이 있습니다.

grep -a -C 500 'known pattern' /dev/sda | tee /tmp/recover

그런 다음 /tmp/recover파일의 내용 만 유지하도록 편집 하십시오.

유닉스 철학으로 모든 것이 파일이라면, 이것을 활용할 시간이다.

— 질 케 노트
소스

5

귀하의 grep기반 솔루션은 매우 영리하다, 심지어 여전히 탑재 된 파일 시스템, 날 위해 일했습니다. 감사!

— wchargin

grep 솔루션이 어떻게 작동했는지 이해하지 못하며 바이너리 데이터 만 출력합니다. 그게 어떻게 유용합니까?

— w00t

2

@ w00t 물론, 이진 데이터를 "만"추출합니다. 그러나 때로는 이진 데이터에 내가 찾고있는 파일에 해당하는 ASCII 비트가 포함되어 있습니다. 질문을 이해하지 못하는 것 같습니까?

— wchargin

@ w00t 트릭은 해당 파일에 매우 특정한 검색 패턴을 사용하는 것입니다. grep 명령은 각 일치하는 줄 전후에 500 줄을 가져 오기 때문에 관련이없는 많은 데이터가 여전히 뱉어 지지만 그에 대처할 수있는 텍스트 편집기 (예 : Vim)를 사용하면 나쁜 것들. 다른 grep 명령을 통해 파이프를 인쇄하여 인쇄 할 수없는 문자로 모든 행을 필터링 할 수도 있습니다.grep -av "[^[:print:]]"

— CJStuart

grep내가 한 : 솔루션은 수정과 나를 위해 일한 sudo grep --line-buffered -ab "$PATTERN" /dev/sda1 | tee lines과 (같은 바이트 오프셋을 가지고 123123123:line\n456456456:another\n...한 다음,) n=1000; sudo dd of=before if=/dev/sda1 ibs=1 skip=$[123123123-$n] count=$n및 n=1000; sudo dd of=after if=/dev/sda1 ibs=1 skip=123123123 count=$n다른과 n값.

— Kirill Bulygin

21

나를 위해 일한 것은 아치 로 제공되었습니다 (텍스트 파일에만 적용).

grep -a -C 200 -F 'Unique string in text file' /dev/sdXN

/dev/sdXN손실 된 파일이 들어있는 파티션은 어디에 있습니까 ( mount확실하지 않은지 확인하십시오 ).

시간이 조금 걸리지 만 실수로 아직 커밋하지 않은 소스 코드를 삭제했을 때 작동했습니다!

— 윌리엄 베커
소스

4

프로그래머에게 매우 유용합니다!. 일반적으로 우리는 항상 자체 코드를 잃어 버렸습니다.

— pylover

1

실수로 실행, 그것에 대해 말해 rm data/*.json python myFile.py대신rm data/*.json && python myFile.py

— 윌리엄 베커

2

고마워 친구, 당신은 내가 밤에 쓰는 데 2 시간을 보낸 텍스트 파일을 복구하는 데 도움이되었습니다. PS /dev/sdXN는 파일 시스템 용입니다. df -T | awk '{print $1,$2,$NF}' | grep "^/dev"

— Alex

파일의 이진 만 보았습니다. 일반 형식으로 변환하는 방법이 있습니까?

— silgon

grep: conflicting matchers specified

— felwithe

10

이 질문이 해결되고 몇 년이되었지만 testdisk 유틸리티 에 대해 언급하고 싶습니다 .

testdisk로 파일을 복구하는 방법은 이 튜토리얼 에서 잘 설명되어 있습니다 . 파일을 복구하려면 testdisk /dev/sdX파티션 테이블 유형을 실행 하고 선택하십시오. 이 후, 선택 [ Advanced ] Filesystem Utils후 파티션을 선택하고 선택 [Undelete]. 이제 삭제 된 파일을 찾아서 선택하여 파일 시스템의 다른 위치로 복사 할 수 있습니다.

— 빌헬름
소스

내 / dev / nvme0n1p2

— h22가

6

지난주에 같은 문제가 있었고 debugfs, photorec, ext3grep 및 extundelete와 같은 많은 프로그램을 시도했습니다. ext3grep는 파일을 복구하는 가장 좋은 프로그램이었습니다. 구문은 매우 쉽습니다.

ext3grep image.img --restore-all

또는:

ext3grep /dev/sda3 --restore-all --after date -d '2015-01-01 00:00:00' '+%s' --before `date -d ‘2015-01-02 00:00:00’ ‘+%s’

이 비디오 는 당신을 도울 수있는 미니 튜토리얼입니다.

— 후안
소스

6

다른 방법 으로 삭제 하는 del대신 사용할 수 있습니다 rm.

http://fex.belwue.de/fstools/del.html

del 삭제 취소 기능이 있으며 모든 파일 시스템에서 작동합니다.

물론 "포로 수용하지 않음"rm :-}으로 파일을 이미 삭제 한 경우에는 해결책이 아닙니다.

— Framstag
소스

1

당신이 이미 말한 것처럼 대답은 아니지만 del 명령 을 소개해 주셔서 감사합니다 .

— pylover

5

외부 인터페이스를 통해 드라이브 연결

산
umount /dev/{sd*}
extundelete --restore-all /dev/{sd*}
결과는 부팅 드라이브의 홈 폴더로 이동
보너스 포인트 : 이것에 대한 GUI 작성

자세한 내용은이 링크를 참조하십시오 : extundelete를 사용하여 ext4에서 방금 삭제 한 파일의 삭제를 취소하십시오 .

— GRZ
소스

2

Downvoters, extundelete가 좋은 옵션이 아닌 이유를 설명해주세요.

— webminal.org

2

좋은! 게시 해 주셔서 감사합니다. extundelete는 새로운 도구입니다. 나는 이것을 오늘 사용했고 그것이 매우 도움이되었다는 것을 알았습니다. 허용 된 답변보다 훨씬 유용한 IMO입니다. 이 답변에 약간 개선하기 위해 추가 할 유일한 것은 (1) 파일이 실수로 삭제되었다는 사실을 알게 되 자마자 영향을받는 컴퓨터의 전원을 꺼야한다는 다른 답변의 지침을 반복하는 것입니다. extundelete 유틸리티를 포함하는 Kali Linux와 같은 liveCD 또는 liveUSB OS에서 부팅합니다 (Debian Jessie와 같은 다른 많은 liveCD는이 유틸리티를 설치 미디어에 포함하지 않습니다).

— Osteoboon

4

복구 도구-명령 줄 :

복구 도구-Gui :

R- 리눅스 (2) (5)
R- 스튜디오 (1) (5) (4)
UFS 익스플로러 (1) (5) (4)
복구 탐색기 (1) (5) (4)

정보 :

개인 경험에서 ufs-explorer와 photorec을 사용하여 데이터를 다시 얻습니다.

(1) = 공개 소스가 아니며 무료가 아닙니다.

(2) = 공개 소스 아님, 무료

(3) = 공개 소스 및 무료

(4) = NTFS 지원

(5) = 디렉토리 구조 기능

— 인티 카
소스

1

나는 그것이 불가능하고, 매우 매우 어렵다는 것에 동의하지 않으며, 리눅스에서도 그렇게 한 적이 없다.

파일이 삭제되면 실제로 삭제되지 않습니다. 하드 드라이브에 있던 공간은 일종의 리셋이므로 컴퓨터가 데이터를 쓰려고해도 아무런 문제가 없습니다. 일반적으로 삭제 한 하드 드라이브의 데이터는 거의 1 년 후에있을 수 있습니다. 또는 적어도 이것은 Windows 컴퓨터에서의 나의 경험입니다. Linux의 명령 줄에서 동일한 방식으로 작동하는지 여부는 확실하지 않지만 파티션을 열려면 별도의 Live CD가 필요하며 파일이 여전히 존재한다는 보장도 없습니다. Zero Assumption Recovery를 사용하여 Windows XP에서 여러 번이 작업을 수행했습니다. 당신이 충분히 열심히 보면 비슷한 도구가 있다고 확신합니다.

— 로그 반타
소스

상황에 따라 100 % 불가능할 수 있습니다. 작동하지 않을 수도 있지만 보장 할 수는 없습니다.

— klutt

0

파일을 삭제하면 해당 파일에 대한 inode 테이블의 링크 수가 하나씩 줄어 듭니다. Unix에서 링크 수가 0으로 떨어지면 해당 파일의 데이터 블록이 사용 가능한 것으로 표시되고 일반적으로 해당 데이터 블록에 대한 참조가 손실됩니다. 방금 @fedorqui의 의견에서 해당 블록에 액세스 할 수있는 방법이 있지만 ext3 파일 시스템에만 적용 할 수 있음을 발견했습니다.

파일을 보존하는 한 가지 방법 은 파일을 휴지통 으로 옮기고 (필수 $HOME/.trash) 필요한 파일을 복구 할 수있는 기능을 작성하는 것입니다. 이 함수는로 별칭을 지정할 수 있습니다 rm. 특정 일 수 동안 휴지통 영역에 있던 파일을 삭제하도록 크론 작업을 예약 할 수 있습니다.

— Unxnut
소스

0

이것은 당신의 일부를 위해 문제를 저장할 수 있습니다.
gedit를 사용하여 해당 파일을 편집 한 경우 기본적으로 해당 파일의 사본이 작성됩니다.
예를 들어 실수로 'myfile.txt'를 삭제했다고 가정 해 봅시다.
방금 삭제 한 파일을 포함하는 폴더에서 다음 명령을 사용하면 거기에서 복사본을 복구
ls | grep 'myfile.txt~'
할 수 있습니다
cp 'myfile.txt~' 'myfile.txt'
. 행운을 빕니다!

— ntt
소스