主页 / unix / 问题 / 679339
Accepted
Ntakwetet
Asked: 2021-11-28 13:12:13 +0800 CST

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

  • 772

问题

我错误地从我/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......

debian data-recovery

2 个回答

  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 和加密完全无关，因此您可能想要更改问题的标题。

    • 1
  2. Best Answer

    我设法恢复了我丢失的许多文件，也许是全部文件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可能是个好主意（这看起来很有趣）。

    • 0

相关问题