上周溯源某挖矿case，在排查过程中发现挖矿文件被人为删除。最终通过确定文件被删除的时间以缩小排查ssh登录的时间范围从而锁定了可疑ip。该case引发了我的思考，linux下如何查找最近被删除的文件？本文是数据恢复的第三篇文章，只是快速找到被删除文件，并不涉及如何恢复文件本身。

大家都知道文件有三个时间戳atime、mtime、ctime。但是在linux下文件还有crtime（创建时间）和dtime（删除时间）。通过dtime可以查找最近被删除的文件，但由于inode可能被覆盖，该方法不一定完全准确。

如何查看文件的5个时间戳？

上面的操作中删除一个文件后，虽然文件的block指针被抹除，但被删除文件的indoe还在，并且写入了文件的被删除时间。

通过使用debugfs命令（linux自带用于内核调试的虚拟文件系统），获取文件的5个时间戳。关于linux文件删除的原理和debugfs的使用可以参考我之前的文章：数据恢复(一)-linux下ext文件系统数据删除原理浅析 。

如何快速定位哪些目录中的文件被删除？

最常见的我们是通过find命令查找linux中文件的变动。因为linux下一切皆文件，目录本身也是一个文件。比如我们删除了一个目录中的文件，该目录的时间也会发送改变。

做一个简单的测试。原本tmp.873RCQOugw目录的mtime为2021-12-20，但是我们删除该目录中的一个文件之后，该目录的mtime变为了现在的时间。

所以可以使用find命令查找存在文件变动的目录，这样可以避免全盘扫描，节省更多的时间。

有哪些可实现的思路？

我一开始想到了两种方式。

1. 直接从磁盘上读取所有文件的indoe信息，通过比较文件的dtime是否为空判断该文件是否被删除。这种方式比较硬核，需要解析inode表的数据结构，实现相对麻烦，但不会有任何遗漏。
2. 通过find命令配合debugfs获取文件dtime，只需编写shell脚本即可实现，相对简单很多。不过可能会出现部分遗漏（比如文件名中包含空格导致解析失败）。

为快速验证我的想法，最终采用了第二种方式实现。

shell脚本实现

linux快速查找最近被删除的文件，我的脚本代码如下：

#!/bin/bash
tempDir=$(mktemp -d)

# 获取主分区
mainPartition=$(df -Th | awk '$NF=="/"{print $1}')
echo "正在扫描3天内发生变动的文件夹"
recentChangedDirs=$(find / -maxdepth 5 \( -path /proc -o -path /run -o -path /sys \) -prune -o -mtime -3 -type d )
for dir in $recentChangedDirs; do
 debugfs -w $mainPartition -R "ls -d $dir" 2>/dev/null | \
 xargs -n3 2>/dev/null | awk '/<[0-9]+>/{print $1,$NF}' 2>/dev/null | \
while read inum fileName
do
 realPath=$dir/$fileName
 inodeInfo=$(debugfs -w $mainPartition -R "stat $inum" 2>/dev/null )
if echo $inodeInfo | grep -q "dtime"; then
 crtime=$(echo $inodeInfo| grep -oE "crtime:.*? [0-9]{4} d")
 dtime=$(echo $inodeInfo| grep -oE "dtime:.*? [0-9]{4}")
 echo -en "检测到被删除的文件：$realPath\n该文件的创建时间为：$crtime\n该文件的删除时间为：$dtime\n\n" | tee -a $tempDir/deleteFile.log
else
 echo -en "被删除文件$realPath的inode已被其他文件覆盖！无法获取被删除时间\n" | tee -a $tempDir/deleteFile.log
 fi
 done
done
echo -e "\n\n文件删除信息已保存至：$tempDir/deleteFile.log"

效果如下：

脚本放在了我博客上，可以curl测试效果。

curl -sL https://zgao.top/download/scanDeletedFiles.sh | sh

存在的问题？

inode被其他文件覆盖后，虽然还能看到被删除的文件名，但是已经看不到被删除文件的几个时间戳。（注意：这里说的是inode覆盖，不是block覆盖，inode被覆盖不代表文件的真实内容被覆盖）

已上图中的 被删除文件/usr/local/qcloud/YunJing/log/ydservice.20220311.log的inode已被其他文件覆盖！无法获取被删除时间 为例。

此时虽然还能找到被删除的文件名，但是从indoe中获取到的已经是新文件的信息了。