能恢复，但取决于文件系统类型、是否被覆盖、进程是否还在用；进程未退出时用lsof查deleted后cp /proc/PID/fd/FD恢复；ext3/ext4用extundelete；其他文件系统或失效时用photorec按特征扫描。
能恢复，但取决于三个硬条件：文件系统类型、是否被覆盖、进程是否还在用——缺一不可。
文件删了但进程还在用（lsof 直接救）
这是唯一 100% 成功率的场景，不需要工具安装，不依赖文件系统类型。
- 运行
lsof | grep deleted，看到类似node 1234 user 3r REG 253,1 102400 12345678 /app/server.js (deleted)就说明命悬一线但可救 - 关键字段是 PID（1234）和 FD（3），对应路径是
/proc/1234/fd/3 - 立即执行：
cp /proc/1234/fd/3 /tmp/server.js.bak，不要重定向到原路径（可能已不存在） - 注意：必须用 root 权限；如果进程已退出或
lsof查不到任何(deleted)行，这条路就断了
ext3/ext4 分区上删了就没了（extundelete 是首选）
它靠 inode 日志还原，能保留原文件名和目录结构，但只认 ext3/ext4。
linux-sysadmin
下载
Linux系统管理专家，覆盖12大模块：用户权限、SSH、存储、网络、systemd、防火墙、日志监控、备份恢复、TLS证书、Ansible、容器、IaC。提供配置、验证、加固、监控、备份、自动化、故障排查、回滚闭环。关键词：useradd、sudo、sshd_config、chmod、SEL...
- 先确认：
df -T /path/to/deleted输出必须是ext3或ext4；如果是xfs或btrfs，extundelete直接报错退出 - 立刻冻结分区：
sudo mount -o remount,ro /dev/sda1（根分区）或sudo umount /dev/sdb1（非根分区） - 恢复单个文件：
sudo extundelete /dev/sda1 --restore-file /home/user/config.yaml（路径必须是分区内的绝对路径） - 恢复整个目录：
sudo extundelete /dev/sda1 --restore-directory /var/log/nginx - 恢复后文件默认在当前目录的
RECOVERED_FILES/下，别直接写回原分区
其他文件系统或 extundelete 失效时（photorec 拼内容）
它不看文件系统结构，只按文件头尾特征扫描数据块，所以 xfs、btrfs、甚至 FAT 都能扫，但文件名全丢，目录结构归零。
- 安装后直接运行
sudo photorec，交互式选择磁盘 → 分区 → 文件类型（建议全选）→ 扫描目标目录（推荐选空 U 盘或另一块硬盘） - 扫描出的文件会按类型分目录（如
jpg_001.jpg,doc_002.docx），得靠file命令和内容抽查识别 - 别存回原分区：
photorec本身会持续写日志，若输出路径设在误删分区，等于边扫边覆盖 - 对代码、文本类文件，可用
strings recovered_file | head -n 20快速判断是否有效
最易被忽略的一点：所有恢复操作前，必须确认没有 cron、rsyslog、journal、backup 脚本正在往该分区写日志或临时文件——哪怕只多写入几 KB，关键 inode 就可能被覆盖，再无回头路。
