Debian

恢復使用 rm 刪除的文件(甚至從 LUKS 加密的磁碟)

  • November 28, 2021

問題

我錯誤地從我/home/username的 with中刪除了幾個文件rm。我一按輸入就意識到了錯誤,但是損壞已經造成。我立即創建了一個完整的磁碟映像sudo dd if=/dev/sda of=/media/username/external_drive/image.iso並將其複製到另一台 PC,並準備走一條很長的數據恢復之路。然後意識到我不知道從哪裡開始。

我做了什麼

我在網上閱讀了一些指南,最終extundelete /dev/partition_to_recover_from --restore-directory /path/to/restore提出了最有希望的解決方案,所以我嘗試了一下。

我遇到的第一個問題是我用 LUKS 加密了我的驅動器(在作業系統安裝期間)並且必須解密它。經過一番研究,我使用以下命令準備了分區(這裡我將實際卷組名稱從實際值<my_pc_name>-vg更改為pc-vg)。

$ 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 extundelete /dev/mapper/pc--vg-root --restore-directory /home/username/path/to/restore
NOTICE: Extended attributes are not restored.
WARNING: EXT3_FEATURE_INCOMPAT_RECOVER is set.
The partition should be unmounted to undelete any files without further data loss.
If the partition is not currently mounted, this message indicates 
it was improperly unmounted, and you should run fsck before continuing.
If you decide to continue, extundelete may overwrite some of the deleted
files and make recovering those files impossible.  You should unmount the
file system and check it with fsck before using extundelete.
Would you like to continue? (y/n)

但是,該分區未安裝並df確認。另外,sudo fsck -N只想對/dev/sdaX. 有疑問,我重新啟動系統並重複上述步驟。我收到了完全相同的輸出,考慮到我正在處理原始磁碟映像的副本(所以我有一個備份以防數據失去),這次我回答了y。結果是:

$ sudo extundelete /dev/mapper/pc--vg-root --restore-directory /home/username/path/to/restore
NOTICE: Extended attributes are not restored.
WARNING: EXT3_FEATURE_INCOMPAT_RECOVER is set.
The partition should be unmounted to undelete any files without further data loss.
If the partition is not currently mounted, this message indicates 
it was improperly unmounted, and you should run fsck before continuing.
If you decide to continue, extundelete may overwrite some of the deleted
files and make recovering those files impossible.  You should unmount the
file system and check it with fsck before using extundelete.
Would you like to continue? (y/n) 
y
Loading filesystem metadata ... extundelete: Extended attribute has an invalid value length when trying to examine filesystem

我確實做了其他研究,但我不明白這意味著什麼。

問題

我會盡量避免XY 問題

我用來嘗試恢復數據的方法是否正確?如果是這樣,extundelete抱怨什麼,我該如何解決?如果沒有,我如何(嘗試)從 Debian 中的 LUKS 加密磁碟恢復我的數據?

如果需要任何其他資訊,請詢問。

PS: «從您顯然擁有的最近備份中恢復»是正確的答案,我知道 =)。

我確實在數據失去前幾天對我的家進行了完整備份(不是這樣的 n00b),但是我失去了超過 20 小時工作的產品,我想把它找回來。


更新

我嘗試fsck使用我的數據在分區上執行,結果是

$ sudo fsck -r /dev/mapper/pc--vg-root
fsck from util-linux 2.36.1
e2fsck 1.46.2 (28-Feb-2021)
/dev/mapper/pc--vg-root: recovering journal
Clearing orphaned inode 7077927 (uid=1000, gid=1000, mode=0100600, size=0)
Clearing orphaned inode 7077925 (uid=1000, gid=1000, mode=0100600, size=65536)
Clearing orphaned inode 19794062 (uid=1000, gid=1000, mode=040775, size=4096)
Clearing orphaned inode 18366502 (uid=1000, gid=1000, mode=040755, size=4096)
Clearing orphaned inode 18366515 (uid=1000, gid=1000, mode=040755, size=4096)
Clearing orphaned inode 18366503 (uid=1000, gid=1000, mode=040755, size=4096)
Clearing orphaned inode 18366504 (uid=1000, gid=1000, mode=040755, size=4096)
Clearing orphaned inode 18366511 (uid=1000, gid=1000, mode=040755, size=4096)
Clearing orphaned inode 18366512 (uid=1000, gid=1000, mode=040755, size=4096)
Clearing orphaned inode 18351755 (uid=1000, gid=1000, mode=0100444, size=15383322)
Clearing orphaned inode 18351757 (uid=1000, gid=1000, mode=0100444, size=12832)
Clearing orphaned inode 18366521 (uid=1000, gid=1000, mode=040755, size=4096)
Clearing orphaned inode 7078039 (uid=1000, gid=1000, mode=0100600, size=0)
Clearing orphaned inode 7077945 (uid=1000, gid=1000, mode=0100600, size=65536)
Clearing orphaned inode 11927591 (uid=0, gid=0, mode=0100644, size=147932)
Clearing orphaned inode 18096551 (uid=0, gid=0, mode=0100644, size=2456)
Clearing orphaned inode 11535970 (uid=0, gid=0, mode=0100644, size=335240)
Setting free inodes count to 29879660 (was 29737485)
Setting free blocks count to 41417686 (was 20072881)
/dev/mapper/pc--vg-root: clean, 553620/30433280 files, 80298026/121715712 blocks
/dev/mapper/pc--vg-root: status 0, rss 6876, real 38.344677, user 0.482391, sys 0.290328

我不知道文件系統是如何工作的,但根據我對過去幾個小時閱讀內容的理解,fsck 似乎剛剛刪除了我試圖恢復的數據?現在extundelete執行沒有抱怨,但

$ sudo extundelete /dev/mapper/pc--vg-root --restore-directory /home/username/path/to/restore
NOTICE: Extended attributes are not restored.
Loading filesystem metadata ... 3715 groups loaded.
Loading journal descriptors ... 0 descriptors loaded.
Searching for recoverable inodes in directory /home/username/path/to/restore...
0 recoverable inodes found.
Looking through the directory structure for deleted files ... 
0 recoverable inodes still lost.
No files were undeleted.

我知道我無法恢復被覆蓋的數據,但我錯誤地刪除了超過 100GB,我認為在我創建磁碟映像之前它們不可能被全部覆蓋dd……

我設法恢復了我失去的許多文件,也許是全部文件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給我提供了數百個子目錄(recup_dir.<nnn>,其中<nnn>是一個遞增的數字),其中充滿了具有隨機名稱和正確副檔名的文件(例如,f582010347.txt是一個我知道我用正確名稱保存的文本文件) . 我檢查了一些隨機文件,看起來我找回了磁碟上的所有文本文件,甚至包括未刪除的文本文件(/etc/ssh/sshd_config例如,包括 .總共超過 80GB。但至少我讓他們回來了。

在接下來的幾天裡,我將嘗試自動過濾掉它們以找到我需要的那些。我做了一些快速的嘗試,並取得了很好的成績

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

在哪裡:

  • string是一個我知道的字元串存在於我要恢復的文件中
  • restore_path``photorec是我指示寫入恢復文件的路徑

添加到--text選項中grep,我還可以辨識出一些我需要恢復的 PDF。但是,我知道由於 PDF 是二進製文件,這可能不允許我取回所有文件。

畢竟,它比我想像的要好得多。我學到的教訓:我的定期備份不會保護我免受自己的傷害。此外,使用不那麼危險的別名rm可能是個好主意(看起來很有趣)。

另外,sudofsck -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 和加密完全無關,因此您可能想要更改問題的標題。

引用自:https://unix.stackexchange.com/questions/679339