linux中被覆盖的文件绝大多数无法恢复，因覆盖会物理覆写数据块；仅当文件句柄仍打开（/proc/pid/fd/）、ext4日志未清空或photorec按文件头扫描时才可能挽救，但成功率低且依赖及时操作。
Linux 中被覆盖的文件，绝大多数情况下无法恢复——这不是工具不行，而是底层机制决定的：覆盖操作会直接覆写磁盘上的数据块，原内容物理消失。只有极少数例外场景有救，关键看「是否真被覆盖」以及「覆盖后有没有残留痕迹」。
文件没真被覆盖：还在 /proc//fd/ 下挂着
常见于 Web 服务、数据库或脚本进程仍在读写该文件，你执行了 cp new.conf old.conf 覆盖，但老进程没 reload，文件句柄仍打开。
- 运行
lsof | grep deleted，找带(deleted)标记的行，确认 PID 和 FD 编号（比如/proc/1234/fd/5） - 用
cat /proc/<pid>/fd/<fd> > /recovered/file.conf</fd></pid>直接提取原始内容 - 注意：
PID必须存在且未退出；FD编号要和lsof输出一致；目标路径需有写权限 - 这个方法成功率接近 100%，但窗口极短——进程一重启或关闭，就彻底没了
ext4 分区刚覆盖，还没被新数据擦写
extundelete 只对 ext3/ext4 有效，且依赖文件系统未清空 inode 和日志记录。它不能“扫描磁盘找旧字节”，而是解析 ext 日志重建删除前状态。
- 立即停写目标分区：关掉日志轮转、停止应用写入、卸载分区（
umount /dev/sdb1） - 安装并运行：
sudo extundelete /dev/sdb1 --restore-file /etc/nginx/conf.d/site.conf - 恢复结果默认存到当前目录下的
RECOVERED_FILES/，不是原路径 - 不支持 xfs、btrfs、zfs；若分区是 LVM 逻辑卷，需指定 LV 设备路径（如
/dev/mapper/vg0-lvroot） - 如果覆盖后又写入大量新文件，inode 日志早被回收，
extundelete会报No such file or directory
文件名丢了、格式还能识别：用 PhotoRec 扫描原始扇区
photorec 不看文件系统结构，只按文件头（magic bytes）匹配内容，适合找回 jpg、pdf、txt 等有固定头部格式的文件，但无法还原原名和目录结构。
- 安装：
sudo apt install testdisk（photorec是 testdisk 的子命令） - 运行：
sudo photorec /dev/sdb1，选分区 → 选文件类型（建议勾选全部）→ 指定输出目录 - 扫描时间长（尤其大硬盘），结果里全是
f0000000.jpg这类编号名，得靠内容判断哪个是你要的 - 对纯文本文件效果差（无强 magic header），对二进制文件（如 ELF、.so）基本无效
- 别在原盘上建输出目录——必须指向另一块干净磁盘，否则边扫边写，越救越丢
备份与快照才是唯一可靠路径
所有恢复工具都只是“赌概率”，而 rsync 定时备份、zfs snapshot、lvm snapshot 或云备份，才是真能拿回来的方案。
- 检查是否有最近的
tar备份：ls -lt /backup/*.tar.gz | head -5 - LVM 用户可试：
sudo lvcreate -L1G -s -n snap_before /dev/vg0/lv_root（前提是当时做了快照） - ZFS 用户直接：
zfs rollback pool/dataset@hourly-20260706-2200 - 没有这些？下次覆盖前加个防护习惯：
cp -i config.conf config.conf.bak或 aliasrm='rm -i'
真正麻烦的从来不是“怎么救”，而是“为什么没备份”。恢复工具跑完发现空目录，比删错命令还让人沉默。
