rm恢复/取消删除已删除文件的命令？如果有这样的工具，该如何使用？#1 楼
评论中提供的链接可能是您最好的机会。Linux debugfs Hack：取消删除文件跟随。通常，步骤如下：
使用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之类的工具来恢复文件，但是它仅适用于图像文件。我已经在我的博客上广泛地讨论了这种方法，标题为：如何从Fedora / CentOS / RHEL上的数码相机的SDD卡中恢复损坏的jpeg和mov文件。
评论
我尝试使用debugfs -w / dev / sdb2，但是lsdel sais：找到0个删除的inode。
–rubo77
2013年9月11日7:54
对于ext3 / 4，使用extundelete更容易，并且可能会得到相同的结果。
–管理员
2015年6月16日19:54
这可以恢复文件，但是我收到了��@y��U���T6�Ԝ��*e�0����v'���T�0。 s0��}y��U��T6.....尝试conv = ascii，conv = ibm和conv = ebcdic会产生相同的问题
– codyc4321
15年8月4日在18:20
lsdel：文件系统未打开，如何解决？
–阿弥陀佛
15年10月22日在9:38
我得到/ dev / mapper / wks01-root：打开文件系统时没有这样的文件或目录，您从哪里得到的/ dev / mapper / wks01-root？
– MarkoAvlijaš
17年5月2日，12：04
#2 楼
有时，我可以使用此脚本或答案中的下一个解决方案来恢复已删除的文件：知道已删除文件中的模式，请键入alt + sys + resuo以只读方式重新引导+重新安装，然后使用live-cd，使用
grep在硬盘驱动器中进行搜索：#!/bin/bash
if [[ ! ]]; then
echo -e "Usage:\n\n\tgrep -a -C 500 'known pattern' /dev/sda | tee /tmp/recover
'file name'"
exit 1
fi
f=$(ls 2>/dev/null -l /proc/*/fd/* | fgrep " (deleted" | awk '{print }')
if [[ $f ]]; then
echo "fd $f found..."
cp -v "$f" ""
else
echo >&2 "No fd found..."
exit 2
fi
然后编辑
/tmp/recover以仅保留您以前的文件。 评论
您的基于grep的解决方案非常聪明，即使在文件系统仍挂载的情况下，也可以为我工作。谢谢！
– wchargin
2014年11月27日20:16
我不明白grep解决方案如何为您工作，它仅输出二进制数据。这有什么用？
– w00t
16年8月15日，0：33
@ w00t当然，它“仅”吐出二进制数据。但是有时候，二进制数据恰好包含与我要查找的文件相对应的ASCII位。我想我不明白这个问题？
– wchargin
16-9-5'2:17
@ w00t的诀窍是使用特定于该文件的搜索模式。 grep命令将在每条匹配的行之前和之后占用500行，因此它仍然会吐出许多不相关的数据，但是使用可以处理这些数据的文本编辑器（例如Vim），可以很容易地从坏东西。您还可以通过另一个grep命令将其用管道输送出去，从而过滤掉所有带有不可打印字符的行：grep -av“ [^ [：print：]]”
– JimmyMcHoover
17-3-28在19:12
grep解决方案通过修改对我有用：我做了sudo grep --line-buffered -ab“ $ PATTERN” / dev / sda1 |发球行并得到字节偏移量（例如123123123：line \ n456456456：另一个\ n ...），则n = 1000； sudo dd of = before if = / dev / sda1 ibs = 1 skip = $ [123123123- $ n] count = $ n and n = 1000; sudo dd of = if = / dev / sda1 ibs = 1之后skip = 123123123 count = $ n具有不同的n值
– Kirill Bulygin
17-10-5在11:38
#3 楼
arch给出了对我有用的文件（仅适用于文本文件）：grep -a -C 200 -F 'Unique string in text file' /dev/sdXN
其中
/dev/sdXN是包含丢失文件的分区（如果不确定，请与mount一起检查）。 需要一些时间，但是当我不小心删除了一些我尚未提交的源代码时起作用了。
评论
对程序员非常有用！通常，我们总是会丢失自己的代码。
– pylover
17年6月28日在11:30
告诉我，我不小心运行了rm data / *。json python myFile.py而不是rm data / *。json && python myFile.py
–威廉·贝克尔
17年6月30日在9:03
谢谢队友，您只是帮助我恢复了一个我晚上花2个小时编写的文本文件。附言/ dev / sdXN用于文件系统，对吗？我用df -T找到了我| awk'{print $ 1，$ 2，$ NF}'| grep“ ^ / dev”
– Alex
18年4月15日在16:31
我只看到文件的二进制文件。有没有办法将其转换为普通格式？
–硅胶
18/09/21在7:25
grep：指定了相冲突的匹配器
–追随
19-09-25在12:49
#4 楼
尽管此问题已经解决并且已经使用了几年时间，但我还是想提一下testdisk实用程序。如何在本教程中很好地说明如何使用testdisk恢复文件。
要恢复文件，请运行
testdisk /dev/sdX并选择分区表类型。之后，选择[ Advanced ] Filesystem Utils，然后选择您的分区并选择[Undelete]。现在，您可以浏览并选择已删除的文件，然后将其复制到文件系统中的另一个位置。#5 楼
恢复工具-命令行：testdisk（3）（5）
photorec（3）
extundelete（3）
恢复工具-GUI：
R-Linux（2）（5）
R-Studio（1）（5） （4）
UFS Explorer（1）（5）（4）
Recovery Explorer（1）（5）（4）
信息：
以我个人的经验，我使用ufs-explorer和photorec取回数据
（1）=不开源，不免费
（2）=不开源，免费
（3）=开源且免费
（4）=具有NTFS支持
（5）=具有目录结构功能
来源：Linuxhacks.org
披露：我是Linuxhacks.org的所有者。
#6 楼
另一种选择是使用del而不是rm进行删除：任何文件系统都可以。评论
正如您已经说过的那样，这不是一个答案，但是感谢您引入了del命令。
– pylover
16年2月12日在8:26
#7 楼
通过外部接口连接驱动器安装
umount /dev/{sd*} extundelete --restore-all /dev/{sd*} 结果进入引导驱动器上的主文件夹
要点：编写GUI为此
有关更多信息，请参见此链接：使用extundelete取消删除ext4上刚刚删除的文件。
评论
真好！感谢您的发布。 extundelete对我来说是一个新工具。我今天使用了它，发现它非常有用。国际海事组织比公认的答案更有帮助。我将添加到此答案中以对其稍做改进的唯一事情是（1）重申其他答案中的指示，即一旦人们意识到文件被错误删除，就应该关闭受影响的计算机，以及（2）从包括extundelete实用程序的liveCD或liveUSB OS（例如Kali Linux）启动（我发现许多其他liveCD，例如Debian Jessie都没有在其安装媒体上包含此实用程序）。
– Osteoboon
17年3月13日在16:22
#8 楼
上周我遇到了同样的问题，我尝试了很多程序，例如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'`
该视频是一个微型教程，可以帮助您。
评论
不能在我的ext4驱动器上工作，并且我认为没有ext4grep。
– Sridhar Sarnobat
20年8月8日，下午3:33
#9 楼
我不同意这是不可能的，只是非常非常困难，我也从未在Linux上做到过：删除文件时，实际上并没有删除它们。发生的情况是它们在硬盘驱动器上的空间已重置，因此，如果计算机尝试在其中写入数据，则不会有任何抱怨。通常，您认为已删除的硬盘驱动器上的数据可能会在一年后出现。至少，这是我在Windows计算机上的经验。我不确定它是否可以从Linux上的命令行以相同的方式工作，但我不确定，但是您可能需要单独的Live CD来打开该分区，而且也无法保证文件仍然存在。我已经使用零假设恢复在Windows XP上完成了几次。如果您足够努力，我相信周围也有类似的工具。
评论
根据情况，这可能是100％不可能的。它可能会或可能不会起作用，但是您永远无法保证。
–klutt
18年1月3日在10:16
#10 楼
删除文件时，该文件的inode表中的链接数减少一。在Unix中，当链接数下降到0时，该文件的数据块被标记为空闲，并且通常会丢失对这些数据块的引用。我只是从@fedorqui的评论中发现，可能有一些方法可以访问这些块，但这仅适用于ext3文件系统。保存文件的一种方法是编写一个函数，该函数将允许您将文件移到回收区（让我们说
$HOME/.trash）并从那里恢复所需的文件。该功能可以别名为rm。您可以安排cron作业以删除垃圾箱区域中已存在一定天数的文件。#11 楼
这可能会为您节省一些麻烦。如果您曾经使用gedit编辑该文件，则默认情况下会创建该文件的副本。
例如，假设我们意外删除了'myfile。 txt'。
在以前包含刚刚删除的文件的文件夹中，请使用以下命令，然后从那里恢复副本：
ls | grep 'myfile.txt~' 很幸运，您会找到它，然后：
cp 'myfile.txt~' 'myfile.txt' 我刚刚使用此方法恢复了文件。
祝你好运！
评论
在执行任何操作之前，以只读方式挂载文件系统以确保数据不会被覆盖。另外，请看一下这篇文章：superuser.com/questions/170857/ext4-undelete-utilities。@EvanTeitelman您的意思是重新挂载只读比尝试在挂载文件时恢复文件更好？顺便说一句，midnightcommander（mc）方式，建议卸载datarecoverypros.com/recover-linux-midnightcommander.html