问题出现得很突然，日志倒是留得挺全。CentOS 7 上一台图片站，运维手滑 rm -rf 了 /data/upload 下两天的目录，用户立刻反馈 404，磁盘还在持续写入，lsof 里也没有进程持有句柄。
刚开始盯着「extundelete 依赖 journal 里的旧记录，日志已经被后续事务轮转掉」，折腾了半个多小时，排掉了。
把日志和配置对完，能解释这个现象的基本就这几处。ext4 的日志提交会把被删 inode 的块映射覆盖，写入越多可恢复的块越少。另一种情况是删除发生在挂载状态下，系统继续分配新数据块，原内容被直接覆写。
另外，目录项被删后父目录的 htree 结构重排，路径信息无法还原。
立刻把分区改成只读，止住后续写入
mount -o remount,ro /data接着对整个分区做镜像，所有恢复在镜像上做
dd if=/dev/vdb1 of=/mnt/backup/vdb1.img bs=4M status=progress然后在镜像上按删除时间恢复文件
extundelete /mnt/backup/vdb1.img --restore-all --after 1757000000剩下的就是把恢复出来的目录挂给应用核对
ls -l RECOVERED_FILES/upload | head怎么算真的好了，看的是同一批现象。RECOVERED_FILES 目录里能找回的文件数与删除前 find 统计的数量基本对上，随机抽十张图能正常打开且 md5 与原备份一致。
补一句。能救回来的比例取决于删除后写了多少数据，先只读再做镜像是唯一可控的一步；有备份就别在线上反复试恢复工具。拖得越久，排查成本越高，因为现场状态会被后续操作覆盖。