rm删除的文件在未被覆盖前大概率能恢复，需立即停写并分情况处理：进程仍打开时用lsof从/proc/PID/fd/拷贝；ext4可用extundelete；xfs/btrfs或覆盖后用photorec/testdisk；切忌原盘写入、不进Live CD操作根分区、不提前做dd镜像。
rm 删掉的文件，**没被覆盖前大概率能救回来**，但必须立刻停写、别慌、分情况处理——不是所有删法都一样，也不是所有文件系统都能用同一套命令。
文件还在被进程打开？用 lsof 直接捞
这是唯一 100% 成功率的方式，前提是：文件刚删，但某个进程（比如 nginx、python、tail -f）还持有着它的文件描述符。
常见错误现象：df 显示磁盘空间没释放，ls 找不到文件，但 lsof | grep deleted 能看到带 (deleted) 标记的条目。
- 运行
lsof +L1（更精准）或lsof | grep deleted，找到目标进程 PID 和 FD 编号 - 确认路径是否正确：比如输出是
node 1234 user 3r REG 253,1 10240 1234567 /app/log.txt (deleted)，说明 PID=1234、FD=3 - 执行恢复：
cp /proc/1234/fd/3 /recovered/log.txt（不要用cat重定向，避免换行/编码问题） - 注意：
/proc/PID/fd/下的 fd 是内存映射，只要进程不死，内容就还在；一旦进程退出，这条路就断了
ext4 文件系统？优先试 extundelete
适用于 ext3/ext4，不支持 xfs 或 btrfs。它靠解析 ext 日志（journal）和 inode 信息恢复，比全盘扫描快且精准。
使用场景：文件删了，进程也退出了，但分区还没写新数据。
- 立刻卸载分区：
sudo umount /dev/sda1（根分区无法卸载时，用 Live CD 启动后操作） - 安装：
sudo apt install extundelete（Debian/Ubuntu）或sudo yum install epel-release && yum install extundelete（CentOS） - 恢复单个文件：
sudo extundelete /dev/sda1 --restore-file var/log/syslog - 恢复整个目录：
sudo extundelete /dev/sda1 --restore-directory home/user/docs - 恢复全部可找回文件：
sudo extundelete /dev/sda1 --restore-all，结果默认放在RECOVERED_FILES/目录下
用 testdisk 或 photorec 救急（xfs/btrfs/覆盖后）
当文件系统是 xfs（如 CentOS 默认）、btrfs，或 extundelete 找不到目标时，就得靠底层块扫描工具。它们不依赖文件系统结构，而是按文件头特征（magic bytes）识别内容，所以能绕过 inode 损坏或覆盖初期的数据碎片。
典型错误现象：extundelete 报错 “No journal found” 或完全没输出；lsof 查不到任何 (deleted) 条目；磁盘已写入新日志、临时文件。
-
testdisk更适合恢复丢失的分区或目录结构，photorec专攻文件内容恢复（不保留原名/路径） - 运行
sudo photorec /dev/sda1，选中分区 → 选文件类型（可全选）→ 指定输出目录（**务必不在原盘写入**） - 恢复出的文件名全是
f0000000.jpg这类，得靠file命令或人工预览判断内容 - 性能影响：全盘扫描极慢，1TB 磁盘可能耗时数小时；SSD 上因 TRIM 可能彻底不可逆
别踩这些坑
很多恢复失败，不是工具不行，是人在关键几步动了手。
- 删完还继续
apt update、journalctl --rotate、docker pull—— 这些都会往磁盘狂写，直接覆盖 inode 和数据块 - 在原分区创建恢复目录或保存文件，等于主动覆盖待恢复数据
- 对根分区操作时不进 Live CD，硬在运行系统里跑
extundelete，容易误伤或失败 - 用
debugfs手动找 inode 时输错 block 号，导致恢复出乱码或截断内容
最易被忽略的一点：没有提前做镜像。哪怕只是 dd if=/dev/sda1 of=/backup/sda1.img bs=4M 一次，后续所有操作都可以在镜像上反复试，零风险。
