rm을 사용하여 삭제된 파일 복구(LUKS 암호화 디스크에서도 가능)

Question 1

또한 sudo는 fsck -N/dev/sdaX에서만 작동하기를 원합니다.

이것은 말이 되지 않습니다. e2fsck모든 블록 장치, 심지어 이미지 파일에서도 작동합니다.

이미지에 되돌릴 수 없는 쓰기를 수행하지 않아야 합니다. 스왑 볼륨을 삭제하고 VG의 여유 공간을 활용하여 pc--vg-root스냅샷()을 생성하는 것을 권장합니다 lvcreate --snapshot .... 그런 다음 e2fsck실제 데이터가 아닌 스냅샷에 대해 실행할 수 있습니다 . 문제가 발생하면 스냅샷을 버리고 다시 시작할 수 있습니다.

나는 익숙하지 않다 extundelete. 빠른 검색에서는 지원되어야 한다고 표시되지만 ext4메시지는 WARNING: EXT3_FEATURE_INCOMPAT_RECOVER is set.지원되지 않거나 마음에 들지 않는 것처럼 들립니다 ext4. 이거 엄청 오래된 버전인가요 extundelete?

따라서 먼저 실행 e2fsck하고 Extended attribute has an invalid value length메시지가 여전히 존재하면 최신 버전을 얻으십시오 extundelete.

이 전체 질문은 LUKS 및 암호화와 전혀 관련이 없으므로 질문 제목을 변경하는 것이 좋습니다.

Answer

또한 sudo는 fsck -N/dev/sdaX에서만 작동하기를 원합니다.

이것은 말이 되지 않습니다. e2fsck모든 블록 장치, 심지어 이미지 파일에서도 작동합니다.

이미지에 되돌릴 수 없는 쓰기를 수행하지 않아야 합니다. 스왑 볼륨을 삭제하고 VG의 여유 공간을 활용하여 pc--vg-root스냅샷()을 생성하는 것을 권장합니다 lvcreate --snapshot .... 그런 다음 e2fsck실제 데이터가 아닌 스냅샷에 대해 실행할 수 있습니다 . 문제가 발생하면 스냅샷을 버리고 다시 시작할 수 있습니다.

나는 익숙하지 않다 extundelete. 빠른 검색에서는 지원되어야 한다고 표시되지만 ext4메시지는 WARNING: EXT3_FEATURE_INCOMPAT_RECOVER is set.지원되지 않거나 마음에 들지 않는 것처럼 들립니다 ext4. 이거 엄청 오래된 버전인가요 extundelete?

따라서 먼저 실행 e2fsck하고 Extended attribute has an invalid value length메시지가 여전히 존재하면 최신 버전을 얻으십시오 extundelete.

이 전체 질문은 LUKS 및 암호화와 전혀 관련이 없으므로 질문 제목을 변경하는 것이 좋습니다.

Question 2

나는 잃어버린 파일 중 많은(어쩌면 전부)을 복구했습니다 photorec. 찾을 수 없는 포럼 페이지에서 이에 대해 읽었고 "이 다른 도구도 사용해 보자"고 생각했습니다.

나는 달렸다

$ sudo kpartx -a -v image.iso # map the disk image partitions
add map loop0p1 (254:0): 0 997376 linear 7:0 2048
add map loop0p2 (254:1): 0 2 linear 7:0 1001470
add map loop0p5 (254:2): 0 975769600 linear 7:0 1001472

$ sudo cryptsetup luksOpen /dev/mapper/loop0p5 img # unlock the partition with my data
Enter passhprase for /dev/mapper/loop0p5:

$ lsblk
NAME                  MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
loop0                   7:0    0 465,8G  0 loop
├─loop0p1             254:0    0   487M  0 part
├─loop0p2             254:1    0     1K  0 part
└─loop0p5             254:2    0 465,3G  0 part
  └─img               254:3    0 465,3G  0 crypt
    ├─pc--vg-root   254:4    0 464,3G  0 lvm
    └─pc--vg-swap_1 254:5    0   980M  0 lvm

[...omitting other lsblk output...]

$ sudo vgchange -a y pc-vg
  2 logical volume(s) in volume group "pc-vg" now active

파티션을 준비한 다음

$ sudo photorec

EXT3와 관련하여 처음 오류가 발생했을 때 기억이 잘 나지 않습니다. 나는 달리기를 시도했고 sudo fsck -r /dev/mapper/pc--vg-root질문 업데이트에 쓴 것과 동일한 결과를 얻었습니다. 그러나 그것은 photorec효과가 있었습니다. 내가 정확히 무엇을 했는지는 모르지만 효과가 있었으므로 따르지 않겠습니다.

두 번째 실행에서는 photorec마법사를 따랐습니다. 최선의 결과를 얻을 수 있다고 생각되는 옵션을 선택했을 뿐이고, 전체 이력이 없으므로 제가 확신하는 옵션만 적어보겠습니다.

올바른 장치 선택( /dev/mapper/pc--vg-root)
올바른 파티션을 선택하십시오( ext4).
올바른 파티션 파일 시스템을 선택하십시오( [ ext/ext3 ] ext2/ext3/ext4 filesystem).
[ Free ] Scan for file from ext2/ext3 unallocated space only삭제되지 않은 파일을 복구할 필요가 없으므로 할당되지 않은 공간( )만 검사하도록 선택합니다.
복구된 파일을 쓸 위치 선택

어떤 시점에서는 복구하고 싶은 파일 형식(텍스트 및 PDF)도 선택했습니다.

몇 시간의 분석 및 복구를 통해 임의의 이름과 올바른 확장자를 가진 파일(예: 올바른 이름의 텍스트 파일로 저장한 것으로 알고 있는 파일)로 채워진 수백 개의 하위 디렉터리( , 증분 번호는 어디에 있습니까?) photorec를 얻었 습니다. 임의의 파일 몇 개를 검사했는데 삭제되지 않은 텍스트 파일(예: 포함), 겉보기에 임의의 이름으로 이름이 바뀌고 하위 디렉터리에서 무작위로 정렬된 파일 까지 포함하여 디스크의 모든 텍스트 파일을 다시 가져온 것 같습니다. 총 80GB. 하지만 적어도 나는 그것들을 돌려받았어요.recup_dir.<nnn><nnn>f582010347.txt/etc/ssh/sshd_config

앞으로 며칠 동안 자동으로 필터링하여 필요한 것을 찾으려고 노력할 것입니다. 나는 몇 가지 빠른 시도를 했고 좋은 결과를 얻었습니다

$ grep --ignore-case --recursive -B5 -A5 'string' restore_path

어디:

string복원하려는 파일에 존재하는 것으로 알고 있는 문자열입니다.
restore_pathphotorec복구 파일을 작성하기 위해 지정한 경로입니다

--text옵션을 추가한 후 grep복구해야 할 일부 PDF도 식별할 수 있었습니다. 그러나 PDF는 바이너리 파일이기 때문에 PDF를 모두 가져오지 못할 수도 있다는 것을 알고 있습니다.

결과적으로는 제가 상상했던 것보다 훨씬 더 나은 결과가 나왔습니다. 내가 배운 교훈은 정기적인 백업이 나 자신으로부터 나를 보호하지 못한다는 것입니다. 또한 rm덜 위험한 항목 대신 별칭을 사용하는 것이 좋습니다(이것흥미로워 보이네요).

Answer