恢复使用 rm 删除的文件（甚至是从 LUKS 加密的磁盘）

Question 1

另外，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 和加密根本无关，因此您可能需要更改问题的标题。

Answer

另外，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 和加密根本无关，因此您可能需要更改问题的标题。

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给我提供了数百个子目录（recup_dir.<nnn>，其中<nnn>是增量数字），其中充满了具有随机名称和正确扩展名的文件（例如，f582010347.txt是一个我知道我用正确名称保存的文本文件）。我检查了一些随机文件，看起来我找回了磁盘上的所有文本文件，甚至是未删除的文件（例如/etc/ssh/sshd_config，包括），用看起来随机的名称重命名，并且显然在子目录中随机排序，它们总结总共超过80GB。但至少我把它们找回来了。

在接下来的几天里，我将尝试自动过滤它们以找到我需要的。我做了一些快速尝试并取得了很好的结果

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

在哪里：

string是我知道要恢复的文件中存在的字符串
restore_pathphotorec是我指示写入恢复文件的路径

添加到--text选项后grep，我还可以识别一些需要恢复的 PDF。但是，我知道由于 PDF 是二进制文件，这可能不允许我取回所有这些文件。

毕竟，事情比我想象的要好得多。我学到的教训是：我的定期备份并不能保护我免受自己的侵害。另外，使用别名rm来代替危险性较低的东西可能是一个好主意（这看起来很有趣）。

Answer