rm 误删后怎么救
Linux 下 rm 只解除目录项对数据块的引用，数据块在被新写入覆盖前仍留在盘上，这就是文件恢复能成立的原理，也决定了抢救铁律：先停止对该分区的写入。恢复优先级是备份或快照优先，其次是进程仍持有文件句柄，最后才用扫描工具从裸设备里找。
基本信息
| 适用平台 | Linux 各发行版；ext4 恢复工具较成熟，XFS 与 Btrfs 的删除恢复手段有限 |
|---|---|
| 关键前提 | 恢复动作前该分区不得再有任何写入，输出必须落到另一块盘 |
| 优先级 | 备份/快照 > 进程句柄（/proc/<pid>/fd）> 扫描工具 |
| 权限要求 | 直接读块设备与 mount 操作需要 root |
典型使用场景
- 误删业务数据目录：立刻只读挂载或卸载分区，再从备份还原
- 进程仍在写日志文件时被删：文件句柄未释放，可从 /proc 下拷回内容
- 数据库文件被误删：先停库避免继续写入，再从物理备份与日志恢复到时间点
- 误删发生在容器内：优先查宿主机挂载点与卷快照，而不是在容器里做扫描
- 无备份的极端场景：只能用 ext 系文件系统扫描工具碰运气
应急处理步骤
应急处理步骤
# 1) 立即停止写入：能只读就只读，能卸载就卸载
mount -o remount,ro /data
umount /data
# 2) 首选：从备份或快照恢复
rsync -a /backup/data/ /data/
# 3) 进程仍持有句柄时可直接拷回（数字为进程号）
cp /proc/1234/fd/7 /recovery/app.log
# 4) 无备份时扫描（ext 系，输出务必写到另一块盘）
extundelete /dev/sdb1 --restore-all --output-dir /recovery
photorec /dev/sdb1 # 按文件签名恢复，适合已知文件类型的镜像与文档四种手段对比
| 手段 | 适用条件 | 成功率 |
|---|---|---|
| 备份或快照还原 | 有可用副本 | 最高，且是唯一能保完整目录结构的方式 |
| 进程句柄拷贝 | 删除时仍有进程打开该文件 | 高，但只能救下当前打开的那些文件 |
| extundelete | ext3/ext4 且删除后写入很少 | 中，依赖 inode 未被复用 |
| photorec 等签名扫描 | 任意文件系统，只要块未被覆盖 | 低，文件名与目录结构基本丢失 |
XFS 与 Btrfs 缺少成熟的开源删除恢复工具，这类环境误删基本只能依赖备份；把『有备份且验证过』作为唯一可依赖的底线。
防止手滑比事后抢救划算：给 rm 加别名确认、对关键目录改用带软删除的存储或版本化对象存储，并让高危删除操作走双人复核。