能恢复，前提是文件刚删且进程仍在使用；运行lsof | grep deleted定位pid和fd编号，再通过cat /proc/pid/fd/fd > /recovered/file恢复数据。
能恢复，但必须立刻停写、别在原盘操作、优先查进程是否还在用——这三点没做到，后面所有工具都是碰运气。
lsof 能不能直接找回被删的文件
能，而且是最快最稳的方式，前提是文件刚删、对应进程还开着（比如 Nginx 正在写日志、Node 进程还打开着某个配置文件）。这时候文件数据块根本没动，只是目录项没了，lsof 一搜就出来。
- 运行
lsof | grep deleted，看到类似node 1234 user 3r REG 253,1 102400 1234567 /path/to/file (deleted)就说明还在 -
cat /proc/1234/fd/3 > /recovered/file.txt直接重定向回原路径或备份路径 - 注意：fd 编号（这里是
3）和 PID（这里是1234）必须从lsof输出里抄，不能猜 - 如果进程已退出、或者你 kill 过服务，这条路就断了
extundelete 恢复 ext4 上的误删文件
extundelete 是 ext3/ext4 的专用工具，它靠扫描文件系统日志和 inode 状态来找被删文件。但它不认 SSD 的 TRIM、也不支持 XFS，别乱套用。
- 先卸载分区：
umount /data/app/upload；如果是根分区，得进 rescue 模式或单用户模式再mount -o remount,ro / - 镜像优先：
dd if=/dev/vdb1 of=/mnt/recover/vdb1.img bs=64M conv=noerror,sync，别直接跑在原盘上 - 恢复指定目录：
extundelete /mnt/recover/vdb1.img --restore-directory app/upload/2026-06-28 - 恢复后文件默认放在当前目录下的
RECOVERED_FILES里，但文件名可能变成file.1835127——因为目录项丢了，只能靠 inode 编号硬凑 - 如果数据库里存了原始路径和
sha256，一定要拿回来对账，光看文件大小和时间戳容易漏
为什么 testdisk / photorec 不是首选
testdisk 主攻分区表损坏或误删整个分区，photorec 是按文件签名（magic bytes）暴力扫块，两者都**不保留文件名和目录结构**。你拿到一堆 recup_dir.1/file_0001.jpg，业务系统根本没法认。
- 适合场景：完全不知道删了啥、连路径都不记得，只求捞回几张 PDF 或 Excel
- 不适合场景：要精确还原
/app/upload/2026-06-28/a9/7c/xxx.pdf这种带哈希路径的附件 - SSD 上成功率明显低于 HDD，尤其开了
discard或挂载时用了noatime,barrier=1等参数 - 运行前务必确认磁盘未被写入，否则扫出来的可能是碎片拼出来的“假文件”
真正难的不是命令怎么敲，而是判断“现在还能不能救”：进程是否已死、分区是否还在读写、有没有 LVM 快照、SSD 是否已 TRIM。这些信息比工具版本重要十倍。
